Comments 146
Вот где Ваша статья была 3 дня назад? Как раз не мог выбрать сертификат.
За статью спасибо =)
За статью спасибо =)
Как раз была в процессе написания. Если нужны будут советы по выбору или установке сертификата в будущем — пишите в личку.
Самый простой и бесплатный способ на самом деле сертификат StartCom.
Есть ли возможность подключить сертификат к Active Directory CA?
Чтобы корневой CA домена выпускал сертификаты для своего домена, которым бы сразу доверяли все?
Чтобы корневой CA домена выпускал сертификаты для своего домена, которым бы сразу доверяли все?
Не совсем понял ваш вопрос.
Если я правильно понял вы хотите самостоятельно выпустить корневой сертификат и использовать его?
Если так, то использовать его вы сможете разве что у себя внутри организации, у тех пользователей, кто самостоятельно подгрузит его в браузер.
А вообще корневые сертификаты выпускают только существующие центры сертификации. И эти сертификаты, как правило уже есть в большинстве самых популярных браузеров.
Список центров сертификации можно посмотреть, например здесь: www.dmoz.org/Computers/Security/Public_Key_Infrastructure/PKIX/Tools_and_Services/Third_Party_Certificate_Authorities/
Если я правильно понял вы хотите самостоятельно выпустить корневой сертификат и использовать его?
Если так, то использовать его вы сможете разве что у себя внутри организации, у тех пользователей, кто самостоятельно подгрузит его в браузер.
А вообще корневые сертификаты выпускают только существующие центры сертификации. И эти сертификаты, как правило уже есть в большинстве самых популярных браузеров.
Список центров сертификации можно посмотреть, например здесь: www.dmoz.org/Computers/Security/Public_Key_Infrastructure/PKIX/Tools_and_Services/Third_Party_Certificate_Authorities/
я так понимаю, человек, для себя хочет свой центр сертификации…
При наличии денежки и отлаженной структуры это вполне реально, я знаю компанию из Польши, которая с нуля также получила права выдавать сертификаты.
Было бы хорошо узнать поподробнее, что где и когда
Если стоит задача продавать сертификаты, то есть несколько вариантов:
— самый простой стать реселлеров одного из уже существующих центров сертификации или их реселлеров. Благо у большинства есть и отличный API и White Label. При чем зачастую работать с партнерами центров сертификации дешевле, чем напрямую.
— стать самому центров сертификации. Тут нужна инфрастуктура, большие финансовые вложения. Нужно договориться, чтобы ваши корневые сертификаты были на разных браузерах, ОС и устройствах, на это уйдет не один год и только после этого вы сможете продавать свои сертификаты. К примеру та же Microsoft не допустит ваши сертификаты на свои платформы пока вы не пройдете WebTrust audit, что тоже стоит немалых денег.
Про аудит можете почитать тут: www.webtrust.org/item64428.aspx
В общем думаю без средств в несколько миллинов $ можно даже не пытаться.
— самый простой стать реселлеров одного из уже существующих центров сертификации или их реселлеров. Благо у большинства есть и отличный API и White Label. При чем зачастую работать с партнерами центров сертификации дешевле, чем напрямую.
— стать самому центров сертификации. Тут нужна инфрастуктура, большие финансовые вложения. Нужно договориться, чтобы ваши корневые сертификаты были на разных браузерах, ОС и устройствах, на это уйдет не один год и только после этого вы сможете продавать свои сертификаты. К примеру та же Microsoft не допустит ваши сертификаты на свои платформы пока вы не пройдете WebTrust audit, что тоже стоит немалых денег.
Про аудит можете почитать тут: www.webtrust.org/item64428.aspx
В общем думаю без средств в несколько миллинов $ можно даже не пытаться.
Можно, но не всегда такое необходимо. Надо четко понимать границу между публичными и корпоративными сертификатами. Обычно домен подразумевает корпоративное использование. В правилах Microsoft Public Root достаточно четко прописано, что публичные корневые ЦС не должны использоваться для подписания корпоративных издающих ЦС. Например в среде Windows значение параметра KeyUsage корневого сертификата распространяется на все пользовательские сертификаты всех промежуточных центров, подписанных эти корневым CA.
Получается, что пользовательский сертификат, подписанный публичным центром сертификации, не получится использовать, например, для авторизации по смарт-карте. Так же не будет возможности архивировать закрытые ключи.
На моей практике была установка издающего ЦС, подписанного публичным ЦС (Baltimore Root CA). Потом мы очень намучались с архивацией ключей и смарт-картами.
Вывод: корпоративный ЦС должен иметь собственный корневой сертификат.
Если же речь идет о доверии к сертификату домена со стороны клиентов домена, то это происходит автоматически, так как сертификат помещается в контейнер Default Configuration Context->Services->Public Key Services->Certification Authorities и потом оттуда копируется (при очередном gpupdate) в локальное хранилище сертификатов всем клиентам домена.
Получается, что пользовательский сертификат, подписанный публичным центром сертификации, не получится использовать, например, для авторизации по смарт-карте. Так же не будет возможности архивировать закрытые ключи.
На моей практике была установка издающего ЦС, подписанного публичным ЦС (Baltimore Root CA). Потом мы очень намучались с архивацией ключей и смарт-картами.
Вывод: корпоративный ЦС должен иметь собственный корневой сертификат.
Если же речь идет о доверии к сертификату домена со стороны клиентов домена, то это происходит автоматически, так как сертификат помещается в контейнер Default Configuration Context->Services->Public Key Services->Certification Authorities и потом оттуда копируется (при очередном gpupdate) в локальное хранилище сертификатов всем клиентам домена.
Корневой СА домена это как раз и центр авторизованнй в домене Центр выдачи сертификатов.
почитайте технет на эту тему.
Внутри домена Вам больше ничего не надо, т.к корневые сертификаты и почтовые сертификаты пользователя можно публиковать в СА, после чего любой пользоатель домена может подписывать и шифровать переписку между собой.
Причем есть вариант даже работы с шифрованием и подписью сообщений через owa с недоменных ПК при авторизации на OWA
почитайте технет на эту тему.
Внутри домена Вам больше ничего не надо, т.к корневые сертификаты и почтовые сертификаты пользователя можно публиковать в СА, после чего любой пользоатель домена может подписывать и шифровать переписку между собой.
Причем есть вариант даже работы с шифрованием и подписью сообщений через owa с недоменных ПК при авторизации на OWA
мне как раз и нужно, чтобы клиенты вне домена доверяли сертификатам, выпущенным для OWA (и Exchange ActiveSync)
В теории — можно свой CA заверить внешним доверенным CA. Только на практике это будет 1) ОЧЕНЬ дорого 2) ОЧЕНЬ сложно, так как все сертификаты, выпущенные Вашим CA будут косвенно заверены вышестоящим, следовательно Вам будет необходимо соблюдать все правила корневого CA, и доказывать ему их соблюдение.
На практике проще и правильнее получить сертификат на сервер OWA/ActiveSync у внешнего CA, или прописать собственный сертификат всем клиентам.
На практике проще и правильнее получить сертификат на сервер OWA/ActiveSync у внешнего CA, или прописать собственный сертификат всем клиентам.
Если бы вы прочитали статью, то увидели бы в ней следующее предложение:
«Также можете для тестов использовать бесплатные сертификаты: StartSSL™ Free»
«Также можете для тестов использовать бесплатные сертификаты: StartSSL™ Free»
Есть и такая возможность, я про нее упомянул в статье. Но в случае использования таких сертификатов речь о 99,99% распознаваемости браузерами уже не идет, поэтому такие сертификаты имеет смысл использовать скорее для тестов или для внутреннего использования.
Кстати на том же сайте можно посмотреть отличие такого бесплатного сертификата от остальных: www.startssl.com/?app=40
Кстати на том же сайте можно посмотреть отличие такого бесплатного сертификата от остальных: www.startssl.com/?app=40
да, но вроде бы startssl распазнается браузерами нормально, да же free.
Ну и цена вроде бы то же не кусается.
Ну и цена вроде бы то же не кусается.
А можно уточнить, какие браузеры из современных «не распознают»?
Абсолютно нормальные сертификаты. Засада там в другом совсем — для коммерческого использования сертификаты уже платные, но для своих доменов — бесплатно и вполне себе работает (все современные браузеры на всех платформах давно их знают)
Никаких «для тестов», если генерить их на коммерческий домен (не принадлежащий частному лицу и / или используемый для бизнеса) — его или вообще не сгенерят или просто запретят потом.
Абсолютно нормальные сертификаты. Засада там в другом совсем — для коммерческого использования сертификаты уже платные, но для своих доменов — бесплатно и вполне себе работает (все современные браузеры на всех платформах давно их знают)
Никаких «для тестов», если генерить их на коммерческий домен (не принадлежащий частному лицу и / или используемый для бизнеса) — его или вообще не сгенерят или просто запретят потом.
rapidsslonline.com
promo code — SUPER10OFF
простой сертификат на 1 год — $16.16
Если мне не изменяет память, то он даже single root
promo code — SUPER10OFF
простой сертификат на 1 год — $16.16
Если мне не изменяет память, то он даже single root
Сертификат rapidssl действительно сейчас самый выгодный, если не нужна валидация организации и распознаваемость браузерами у него хорошая.
Если нужен такой сертификат — напишите в личку — сделаем для вас индивидуальную скидку на этот сертификат.
Если нужен такой сертификат — напишите в личку — сделаем для вас индивидуальную скидку на этот сертификат.
Простите, обманул, есть дешевле =)
Промо коды
CHEAP@Rapid1yr95 — $9.5
CHEAP@Rapid2yr9 — $18
CHEAP@Rapid3yr85 — $25.5
CHEAP@Rapid4yr8 — $32
Промо коды
CHEAP@Rapid1yr95 — $9.5
CHEAP@Rapid2yr9 — $18
CHEAP@Rapid3yr85 — $25.5
CHEAP@Rapid4yr8 — $32
Эти цены, очень близки к себестоимости, поэтому могут быть разве, что временно, как акция.
Реселлер с полностью автоматизированным процессом заказа вполне может жить на маржу в 5%, если за счет этого у него большие обороты. Да и скидочные купоны надо поискать, не все ищут скидку на сертификат, если его и так отдают за 20 баксов
Который год покупаю у namecheap по $9 без всяких акций
Действительно, дают аж за $8. А сертификат single root (то есть подписан напрямую тем CA, что есть в браузерах, или требуется устанавливать цепочку сертификатов)?
В этом месяце добавим у себя сертификаты Comodo. Сертификат PositiveSSL готовы продавать для посетителей хабра по 7 уе за год. Заказ и выпуск полностью автоматические, кому нужно — обращайтесь в личку, или по контактам в профиле.
Я если честно не знаю, что такое single root, но работает вроде нормально, браузеры не ругаются.
Вся схема основана на цепочках доверия: root->intermediate->intermediate->final
Сертификат root всегда есть в браузере. Промежуточных может не быть.
Если они есть, то это single root — вашему браузеру для проверки конечного сертификата нужен только сам конечный сертификат, остальное у него уже есть.
Если их нет — браузеру придётся их где-то подгрузить, руководтствуясь записями в final и т. д. по цепочке вверх — там обычно пишут, «где найти ЦС». Но в состоянии «оффлайн, инета нет, нужно просто проверить подпись файла» это невозможно.
Сертификат root всегда есть в браузере. Промежуточных может не быть.
Если они есть, то это single root — вашему браузеру для проверки конечного сертификата нужен только сам конечный сертификат, остальное у него уже есть.
Если их нет — браузеру придётся их где-то подгрузить, руководтствуясь записями в final и т. д. по цепочке вверх — там обычно пишут, «где найти ЦС». Но в состоянии «оффлайн, инета нет, нужно просто проверить подпись файла» это невозможно.
А можно раскрыть состав себестоимости?
Все просто у нас на эти сертификаты максимальный уровень скидки. Как и у кого берем раскрывать не могу.
Конечно с такой ценой мы почти ничего не зарабатываем, но сейчас больше интересна лояльность клиентов. С сертификатами работаем давно, в основном работаем с банками и компаниями сферы телекома, теперь вот хотим и для физ. лиц сделать интересное предложение.
Если интересна партнерка по этим сертификатам — тожем можем предложить вкусные условия
Конечно с такой ценой мы почти ничего не зарабатываем, но сейчас больше интересна лояльность клиентов. С сертификатами работаем давно, в основном работаем с банками и компаниями сферы телекома, теперь вот хотим и для физ. лиц сделать интересное предложение.
Если интересна партнерка по этим сертификатам — тожем можем предложить вкусные условия
Интересна не партнёрка, а корень зла, из за которого сертификаты стоят денег, причём приличных. Думал, что вы сможете описать схему себестоимости сертификата с нуля, а не только свою накрутку.
Чем-то это похоже на RIPE, например, из чего выходит стоимость за LIR, за то, за сё… тоже не понятно. А RIPE так вообще монополист в регионе, так что, думаю, с сертификатами ещё не всё так плохо.
К сожалению данных из чего состоит себестоимость у меня нету. Но можно предположить, что для сертификатов с валидацией организации — закладывается стоимость выполнения такой проверки, некоторые центры сертификации выполняют такую проверку через субподрядчиков — специальные компании, которые берут на себя ответственность проверять компанию.
И отчислений в фонд выплаты «гарнтий». Никто их не выплачитвает, но зато чем больше «гарантия» тем большую сумму на отчисления можно заложить в стоимость. А потом в описании выделять «гарантию» большими красными мирающими буквами. И, что интересно, это работает. Сам сталкивался при выборе сертификата с ситуацией когда выбирали при прочих равных сертификат от более дорогого издателя, объясняя это размерами «гарантии». Хотя большинству конечных клиентов глубоко пофигу на тип, издателя и, уж тем более, на размер гарантий.
А можно сгенерировать под Windows? есть ли в природе софт для этого?
Запрос на сертификаты генерируется не операционное системой, а самим веб-сервером или его модулем. В случае с хостингом на windows запрос CSR генерируется прямо в IIS.
makecert.exe
Цитата с оф. сайта про утилитку: «Инструмент для создания сертификатов генерирует сертификаты X.509, предназначенные исключительно для тестирования.»
Разве эти «тестовые» сертификаты как-то по внутреннему устройству отличаются от «настоящих»?
Другими словами, есть ли способ отличить сертификат, сгенерированный makecert, от сертификата, сделанного тем же openssl?
Другими словами, есть ли способ отличить сертификат, сгенерированный makecert, от сертификата, сделанного тем же openssl?
Открытый ключ, который CSR подпись скорей всего никак не отличается, а вот закрытый ключ (сертификат) отличается тем, что браузер будет «ругаться» на такой сертификат.
О… оказыватся, вы не в курсе.
Закрытый ключ != сертификат.
Более того, сертификат — штука полностью публичная, он никаким образом не содержит закрытый ключ, даже зашифрованный. Но он содержит электронную подпись, выполненную с помощью закрытого ключа ЦС, выдавшего сертификат.
Закрытый ключ != сертификат.
Более того, сертификат — штука полностью публичная, он никаким образом не содержит закрытый ключ, даже зашифрованный. Но он содержит электронную подпись, выполненную с помощью закрытого ключа ЦС, выдавшего сертификат.
Действительно данное упрощение не совсем корректно. Закрытый ключ хранится на сервере и его категорически запрещается предоставлять кому либо.
Всё-таки, «совсем некорректно».
Кстати говоря, CSR тоже не эквивалентно открытому ключу. И называется он поэтому не так — не «открытый ключ», не «public key», а «запрос подписи сертификата», «certificate signing request». Там, помимо ключа, ещё и дополнительные данные, которые хотелось бы к нему «приделать» и чтобы подпись сертификата (собственно центра сертификации) удостоверяла и их тоже.
Это очень важный вопрос. Именно эти «дополнительные данные» и содержат, например, dns-имя сервера, которое требуется подтвердить сертификатом.
Кстати говоря, CSR тоже не эквивалентно открытому ключу. И называется он поэтому не так — не «открытый ключ», не «public key», а «запрос подписи сертификата», «certificate signing request». Там, помимо ключа, ещё и дополнительные данные, которые хотелось бы к нему «приделать» и чтобы подпись сертификата (собственно центра сертификации) удостоверяла и их тоже.
Это очень важный вопрос. Именно эти «дополнительные данные» и содержат, например, dns-имя сервера, которое требуется подтвердить сертификатом.
Наверное действительно стоило раскрыть, что же содержится в самом сертификате.
Это:
— полное (уникальное) имя владельца сертификата
— открытый ключ владельца
— дата выдачи ssl сертификата
— дата окончания сертификата
— полное (уникальное) имя центра сертификации
— цифровая подпись издателя
Добавлю эту информацию в статью.
Это:
— полное (уникальное) имя владельца сертификата
— открытый ключ владельца
— дата выдачи ssl сертификата
— дата окончания сертификата
— полное (уникальное) имя центра сертификации
— цифровая подпись издателя
Добавлю эту информацию в статью.
На самом деле центр сертификации не обязан использовать «дополнительные данные». Для него важен именно открытый ключ клиента, остальное он может использовать, а может и перезаписать/проигнорировать. То, что содержится в клиентском сертификате определяет профиль этого сертификата в центре сертификации. Best-practices таковы: в некорневом сертификате должны быть расширения CDP, AIA caIssuer, AKI, желательны AIA OCSP и Certification Policy со ссылкой на CPS и т.п.
Для клиентских сертификатов предпочтительно использовать только CDP, для серверных желательно добавить AIA OCSP.
Разработка профиля сертификата под конкретную задачу является высокоспециализированной задачей и обычно проходит отдельным пунктом в договоре :-)
Похоже я немного в сторону ушел, все-таки статья про серверные SSL сертификаты. Однако best-practices на них тоже распространяются.
Для клиентских сертификатов предпочтительно использовать только CDP, для серверных желательно добавить AIA OCSP.
Разработка профиля сертификата под конкретную задачу является высокоспециализированной задачей и обычно проходит отдельным пунктом в договоре :-)
Похоже я немного в сторону ушел, все-таки статья про серверные SSL сертификаты. Однако best-practices на них тоже распространяются.
Вообще да, в статье тема вопросов отзыва сертификатов не затронута, а зря. Для проверки подлинности CRL ровно настолько же важны, насколько и сами сертификаты ;)
Статья была рассчитана на широкую публику, пока что в своей практике с отзывом сертификатов не сталкивались, если удастся что-то узнать по этой теме, то напишу в следующей части.
Странно такое слышать от автора статьи. Покупатель, заказывая сертификат, в большей мере платит за инфраструктуру PKI, а не за файлик с подписанным публичным ключом и несколькими дополнительными данными. Покупателю важно, что ЦС не скомпрометирован, что отлажена система отзыва сертификатов, что определена политика ЦС, и много-много всего… А вы пишете, что "в своей практике с отзывом сертификатов не сталкивались".
После таких слов я бы подумал хорошенько, прежде чем заказывать сертификаты у вас.
После таких слов я бы подумал хорошенько, прежде чем заказывать сертификаты у вас.
Похоже мы друг друга не поняли, давайте уточним какой отзыв вы имеете в виду? Вы имели в виду отмену/отзыв (revoke) сертификата клиентом? Или?
Случаи, когда клиент отменял сертификат были, но почти во всех случаях это было из-за неправильно заполненных данных и необходимости оформить заказа заново, либо из-за неверно выбранного типа сертификата.
Случаи, когда клиент отменял сертификат были, но почти во всех случаях это было из-за неправильно заполненных данных и необходимости оформить заказа заново, либо из-за неверно выбранного типа сертификата.
Речь изначально шла о содержании сертификата, вы не упомянули CDP в своем списке, который ссылается на лист отзыва издающего ЦС. merlin_rterm удивился, что эта тема не раскрыта, а вы написали, что типа не в теме. Потом удивился я. Вот такая последовательность событий, что ж тут непонятного? :-)
Надо было просто написать, что да, все наши сертификаты имеют CDP, что CRL всегда актуальный и что есть услуга отзыва сертификата по инициативе клиента или по решению офицера по безопасности. И что все отлажено и все под контролем. :-)
Надо было просто написать, что да, все наши сертификаты имеют CDP, что CRL всегда актуальный и что есть услуга отзыва сертификата по инициативе клиента или по решению офицера по безопасности. И что все отлажено и все под контролем. :-)
А по теме: если я с помощью MakeCert подпишу какой-нибудь объект с секретным ключом доверенного ЦС (предположим, такой ключ у меня есть), то браузер ругаться не будет.
> makecert.exe
openssl.exe
openssl.exe
а можно и openssl пот windows использовать. Работает точно так же. Есть ещё набор скриптов, упрощающих его использование — easy-rsa (кстати, идёт в комплекте с openvpn).
1. Вот корневые ЦС продают сертификаты, рассчитывая на то, что в браузерах сертификаты их самих уже есть. А что с этого имеют производители браузеров? По идее, я, выпуская свой браузер, вполне имею право выкинуть оттуда какой-нибудь VeriSign. Мой браузер, что хочу, то и делаю. А, все сайты отображаются как недоверенные? Ну так они и есть недоверенные, я, как производитель браузера не доверяю этому ЦС. Если ЦС хочет, чтобы я ему доверял, пусть он мне платит, скажем, проценты с продаж сертификатов.
Так рассуждая, приходим к тому, что, скажем условный Verisign должен много денег разработчикам lynx.
1а. А теперь я не производитель браузера, но разрабатываю дистрибутив Linux. В моём репозитарии в пакете с этим браузером сертификат Verisign отсутствует. Ну и далее — по тексту выше.
2. Вот браузер, в нём встроены сертификаты ЦС. Что мешает держателю очередного сайта с софтом, типа all-new-soft.ru, перепаковать дистрибутив, добавив туда в список доверенных какой-нибудь свой ЦС? Или же при запросе на скачивание использовать уязвимость HTTP к подделке и подсунуть другой файл с дистрибутивом. Ведь все браузеры, как правило, скачиваются по HTTP, без проверки подлинности источника.
Всё, теперь я — ЦС, и могу продавать сертификаты. Более того, я могу продать сертификат, например, для сайта microsoft.com, и браузер будет рассматривать его как доверенный, а поддельный сайт microsoft.com — как подлинный.
Из всего этого я могу сделать ровно один неутешительный вывод: вся эта продажа сертификатов — чистой воды торговля воздухом. Действительно доверять можно только тем ЦС, которые ты установил в бразуер сам.
Так рассуждая, приходим к тому, что, скажем условный Verisign должен много денег разработчикам lynx.
1а. А теперь я не производитель браузера, но разрабатываю дистрибутив Linux. В моём репозитарии в пакете с этим браузером сертификат Verisign отсутствует. Ну и далее — по тексту выше.
2. Вот браузер, в нём встроены сертификаты ЦС. Что мешает держателю очередного сайта с софтом, типа all-new-soft.ru, перепаковать дистрибутив, добавив туда в список доверенных какой-нибудь свой ЦС? Или же при запросе на скачивание использовать уязвимость HTTP к подделке и подсунуть другой файл с дистрибутивом. Ведь все браузеры, как правило, скачиваются по HTTP, без проверки подлинности источника.
Всё, теперь я — ЦС, и могу продавать сертификаты. Более того, я могу продать сертификат, например, для сайта microsoft.com, и браузер будет рассматривать его как доверенный, а поддельный сайт microsoft.com — как подлинный.
Из всего этого я могу сделать ровно один неутешительный вывод: вся эта продажа сертификатов — чистой воды торговля воздухом. Действительно доверять можно только тем ЦС, которые ты установил в бразуер сам.
Не совсем так. Во первых центры сертификации регулярно проходят проверку, на их соответствие существующем правилам. Во вторых кто угодно не может получить права выдавать сертификаты, для этого нужно соответствовать достаточно длинному списку требований. Ну и в третьих у некоторых сертификатов есть так называемая гарантия. То есть центр сертификации гарантирует посетителю сайта с таким сертификатом, что на таком сайте он не пострадает от фрауда. Об этом я также упомянул в статье.
Вы меня так и не поняли
1. С какой стати я, производитель браузера, обязан включать все эти ЦС в свой дистрибутив?
2. Почему это я, производитель бразуера, не могу включить любой другой ЦС в свой дистрибутив?
1. С какой стати я, производитель браузера, обязан включать все эти ЦС в свой дистрибутив?
2. Почему это я, производитель бразуера, не могу включить любой другой ЦС в свой дистрибутив?
Спасибо за пояснение.
1. Очевидно существует некоторая договоренность между центрами сертификации и производителями браузеров и есть вероятность, что производители браузеров получают с этого некоторые отчисления.
С другой стороны если в браузере не будет не одного корневного сертификата пользователь такого браузера увидит ошибку на множестве сайтов, которые до этого ошибки не выдавали и скорей всего перестанет использовать такой браузер.
Так что есть свой интерес и у производителей браузеров.
2. Можете.
1. Очевидно существует некоторая договоренность между центрами сертификации и производителями браузеров и есть вероятность, что производители браузеров получают с этого некоторые отчисления.
С другой стороны если в браузере не будет не одного корневного сертификата пользователь такого браузера увидит ошибку на множестве сайтов, которые до этого ошибки не выдавали и скорей всего перестанет использовать такой браузер.
Так что есть свой интерес и у производителей браузеров.
2. Можете.
Отлично! И теперь снова ко второму вопросу: я, производитель браузера, подписал с помощью своего собственного ЦС сертификат для paypal.com. А потом кто-нибудь сделал сайт, отравил DNS и направил ничего не подозревающего пользователя на поддельный ресурс. Браузер, однако, будет считать этот поддельный paypal настоящим — ведь сертификат-то прошёл проверку подлинности!
Как в этой всей схеме PKI учитывается такой вариант?
Как в этой всей схеме PKI учитывается такой вариант?
Это уже вопрос ответственности производителя браузера перед своими клиентами.
К тому же у крупных организаций почти у всех стоит если не EV сертификат, то как минимум сертификат с валидацией организации. А если центр сертификации выдаст такой сертификат фейковой организации, то он с большой вероятностью лишиться своей аккредитации и права выдавать сертификаты.
К тому же у крупных организаций почти у всех стоит если не EV сертификат, то как минимум сертификат с валидацией организации. А если центр сертификации выдаст такой сертификат фейковой организации, то он с большой вероятностью лишиться своей аккредитации и права выдавать сертификаты.
Да нет у меня никакой аккредитации! Я всего лишь производитель браузера, а то и просто злоумышленник, который сделал свой дистрибутив со своим ЦС и подсовываю его пользователям через уязвимости в протоколах.
Не проще ли сразу бэкдор поставить в браузер?
Этот способ не использует никаких недокументированных или секретных особенностей. Никаких уязвимостей в коде. То есть, анализ кода не выявит никаких проблем.
Для выявления нужно анализировать конкретный дистрибутив, причём очень внимательно. Дело в том, что я могу даже сделать свой ЦС и заполнить поля в нём такими же значениями, как у Verisign. Отличить от настоящего можно только позвонил в Verisign и сверив отпечатки ключа, больше никак.
А сертификатов предустановлено порядка сотни. Представляете себе проверку каждого дистрибутива для каждого релиза?
Так сложно затем, что потом это сложно заметить.
Для выявления нужно анализировать конкретный дистрибутив, причём очень внимательно. Дело в том, что я могу даже сделать свой ЦС и заполнить поля в нём такими же значениями, как у Verisign. Отличить от настоящего можно только позвонил в Verisign и сверив отпечатки ключа, больше никак.
А сертификатов предустановлено порядка сотни. Представляете себе проверку каждого дистрибутива для каждого релиза?
Так сложно затем, что потом это сложно заметить.
1. Не обязаны. Но получите по голове от своих же пользователей за такое
2. Можете. Получите по голове от аналитиков и тех, кто проверяет безопасность.
Кроме того, вы можете сделать в своём бразуере backdoor или сливать всю информацию о пользователях. Это гораздо более эффективный путь.
2. Можете. Получите по голове от аналитиков и тех, кто проверяет безопасность.
Кроме того, вы можете сделать в своём бразуере backdoor или сливать всю информацию о пользователях. Это гораздо более эффективный путь.
Встроить ещё один сертификат может не только производитель браузера, а и дистрибьютор. Скажем, Яндекс возьмёт и добавит ещё и свой ЦС в свой дистрибутив Файерфокса, вместе с Я.баром. Мозилла в этом никак не будет замешана.
И злоумышленник тоже может так сделать — он тоже подсунет пользователю свой файерфокс, со своим встроенным ЦС.
Повторюсь, пока браузеры у нас скачивают по HTTP и подписи никакие никто не проверяет — дистрибутив можно подделать, и вся, вся схема с «предустановленными в браузере сертификатами» ненадёжна и порочна.
И злоумышленник тоже может так сделать — он тоже подсунет пользователю свой файерфокс, со своим встроенным ЦС.
Повторюсь, пока браузеры у нас скачивают по HTTP и подписи никакие никто не проверяет — дистрибутив можно подделать, и вся, вся схема с «предустановленными в браузере сертификатами» ненадёжна и порочна.
Злоумышленнику недостаточно подсунуть пользователю свою сборку (а это уже не просто), надо еще заставить пользователя зайти на нужный ресурс. Причем не просто абы какому пользователю, а целевому. Та еще задачка, правда? Да и скажите мне, как много пользователей скачивают и пользуется «левыми» браузерами и сборками? Думаю, что не ошибусь, если их процент пренебрежительно мал.
По поводу яндекса: он не будет добавлять свой УЦ в свою же сборку firefox`a по очень простой причине: это бессмысленно, потому как сертификаты яндекса будут работать только под его сборками, а соответственно все остальные посетители, использующие другие браузеры, будут получать предупреждение о не валидном сертификате. Яндексу это не надо.
На мой взгляд, вы сгущаете краски. Сертификаты работают вот уже много лет и это говорит о том, что их надежность вполне достаточна для абсолютного большинства пользователей.
По поводу яндекса: он не будет добавлять свой УЦ в свою же сборку firefox`a по очень простой причине: это бессмысленно, потому как сертификаты яндекса будут работать только под его сборками, а соответственно все остальные посетители, использующие другие браузеры, будут получать предупреждение о не валидном сертификате. Яндексу это не надо.
На мой взгляд, вы сгущаете краски. Сертификаты работают вот уже много лет и это говорит о том, что их надежность вполне достаточна для абсолютного большинства пользователей.
Задачи направленной атаки — несколько иные, не такие широкие, как вы тут представили: есть некий пользователь и некий ресурс, взаимодействие которых нужно скомпроментировать. Никого не нужно заставлять куда-то заходить. Достаточно поймать момент, когда выпустят очередную версию файерфокса, и подсунуть обновление с сертификатом.
Месяца два-три назад тут обсуждалась конкретная атака, реализованная таким способом (подделкой инсталлятора, переданного жертве с использованием ARP spoofing). Там поставили трояна на комп жертвы, а могли засандалить сертификат — его и обнаружить гораздо сложнее, чем троян. И потом можно тем же способом перехватить взаимодействие жертвы с искомым ресурсом.
Месяца два-три назад тут обсуждалась конкретная атака, реализованная таким способом (подделкой инсталлятора, переданного жертве с использованием ARP spoofing). Там поставили трояна на комп жертвы, а могли засандалить сертификат — его и обнаружить гораздо сложнее, чем троян. И потом можно тем же способом перехватить взаимодействие жертвы с искомым ресурсом.
Ну вряд ли успех такой атаки — это проблема сертификатов. Напротив, использование https при скачивании обновлений существенно бы снизило риск заражения, здесь вы верно заметили — проблема в том, что до сих пор при обновлении может использоваться http без всяких проверок. Кстати, как в настоящий момент с этим обстоят дела у современных хрома и firefox`a?
Да и к тому же особенность направленной атаки — это ее заточка под жертву, здесь и меры предосторожности должны быть совершенно другого уровня. Серебряной пули не существует, комплексная защита рулит ;-)
Да и к тому же особенность направленной атаки — это ее заточка под жертву, здесь и меры предосторожности должны быть совершенно другого уровня. Серебряной пули не существует, комплексная защита рулит ;-)
Собственно, именно для этого все «очередные» версии Файрфокса тоже подписываются сертификатами, но уже для Code signing. И, скачав «левый» браузер, Вы увидите, что он выпущен не Mozilla Corporation, а Zloy Cracker Ltd. Отсюда и всеобщая тенденция к подписыванию пакетов/исполняемых файлов. И чтобы подделать подпись пакета, уже придется устанавливать на компьютер «патченую» ОС, доверяющую «злому» ЦС.
Про Code Signing планирую рассказать в следующей статье.
То, что я предлагаю, не влияет на код. Сертификаты, интегрированные в бразуер, не хранятся в коде.
Вопрос в подписывании не кода, а самого пакета. В линуксах эта проблема давно решена — всё ставится из репозитариев, где опять же всё подписано; в винде решения пока что нет — для установки браузера качаем инсталлятор по http, а потом при установке, даже если система спросит «доверять ли этому издателю», нажмём «всё равно установить».
Вопрос в подписывании не кода, а самого пакета. В линуксах эта проблема давно решена — всё ставится из репозитариев, где опять же всё подписано; в винде решения пока что нет — для установки браузера качаем инсталлятор по http, а потом при установке, даже если система спросит «доверять ли этому издателю», нажмём «всё равно установить».
Ну я по большей части и имел в виду подписывание пакета. Но Вы же сами говорите, что «нажмем „всё равно установить“» — значит проблема не в «винде», а в пользователе. Любая безопасность сводится к самому слабому звену — человеку. Который, кстати, и нажать «всё равно открыть страницу с поддельным сертификатом» запросто может, даже если идет в клиент-банк. Ведь очень нужно за интернет заплатить, например. Безопасен только неработающий компьютер.
Так вот, а последнее предложение вообще нонсенс. Вот, опять же, недавно исправили 25-летний баг во FreeBSD. Да, баги могут жить так долго, и быть незамеченными.
Нормальная ситуация, на мой взгляд. От багов избавлены только те продукты, которые никогда не создавались. Уверен, если поколупать сорцы повнимательнее, то можно найти еще парочку таких «старичков». Это не повод, отказываться от сертификатов или от любой другой технологии. Вступайте в сообщества, думайте, предлагайте и совершенствуйте. Все в ваших руках.
Если быть американским юристом, то после прочтения этих гарантий станет ясно, что гарантия распространятеся на тот случай, когда сам удостоверяющий центр будет скомпрометирован, и кто-то выпустит левый сертификат, откроет на нем поддельный сайт ситибанка и украдет 100500 миллиардов долларов. Да, ситибанку вернут 100 тыщ долларов.
Иными словами — это просто маркетинговая лапша
При выдаче простого (не-EV) сертификата проверяется только то, что почту в домене может прочитать запросивший сертификат клиент, какие там требования — пустая формальность.
Сертификаты пытаются выдать за доверие, а это давно уже простое шифрование транспортного уровня. Попыткой это изменить стали EV-сертификаты. Да, зелененькой полоске доверия больше, чем серенькому замочку.
Иными словами — это просто маркетинговая лапша
При выдаче простого (не-EV) сертификата проверяется только то, что почту в домене может прочитать запросивший сертификат клиент, какие там требования — пустая формальность.
Сертификаты пытаются выдать за доверие, а это давно уже простое шифрование транспортного уровня. Попыткой это изменить стали EV-сертификаты. Да, зелененькой полоске доверия больше, чем серенькому замочку.
Если вы сравните цены на сертификаты, это будет намного очевидней.
Например rapidssl и у его же реселлеров: $50 и $10, или вот те же $10 и $150 у Thawte.
Если одно и то же кто-то продает в 15 раз дешевле, то он явно продает воздух.
Например rapidssl и у его же реселлеров: $50 и $10, или вот те же $10 и $150 у Thawte.
Если одно и то же кто-то продает в 15 раз дешевле, то он явно продает воздух.
Если кто-то продаёт воздух, а кто-то другой продаёт то же самое в 15 раз дороже, то этот кто-то другой просто продаёт воздух в 15 раз дороже, верно?
Наверное все таки будет корректнее сказать, что продается уровень доверия, ведь чисто технически https можно поднять и на самоподписном сертификате.
Почему же сертификат за 10 баксов в моём браузере стоит рядом с сертификатом за 150 баксов, и работает совершенно так же? Где здесь «уровень доверия»?
Специально посмотрел спецификации: никаких стандартных полей типа «уровня доверия» и «тщательности проверки» в сертификатах нет, т.е. схема PKI не рассматривает такие вопросы.
Эти сертификаты не различаются ничем, кроме поля «issuer». Браузеру же это поле неинтересно, он его никак не анализирует, т.е. с точки зрения браузера — вообще ничем не отличаются. И работают одинаково.
Неискушённого пользователя элементарно просто обмануть и вызвать в нём ложное чувство безопасности — ведь SSL же и сертификат доверенный, какая там разница, кем он выдан?
Специально посмотрел спецификации: никаких стандартных полей типа «уровня доверия» и «тщательности проверки» в сертификатах нет, т.е. схема PKI не рассматривает такие вопросы.
Эти сертификаты не различаются ничем, кроме поля «issuer». Браузеру же это поле неинтересно, он его никак не анализирует, т.е. с точки зрения браузера — вообще ничем не отличаются. И работают одинаково.
Неискушённого пользователя элементарно просто обмануть и вызвать в нём ложное чувство безопасности — ведь SSL же и сертификат доверенный, какая там разница, кем он выдан?
Действительно во многих случаях сертификаты от разных центров сертификации технически никак между собой не отличаются, тут уже роль может играть привычный пользователю бренд.
У нас были клиенты, которые готовы были переплачивать за сертификаты от Verisign, хотя мы им разъяснили, что принципальных отличий от более дешевых сертификатов у них нет.
У нас были клиенты, которые готовы были переплачивать за сертификаты от Verisign, хотя мы им разъяснили, что принципальных отличий от более дешевых сертификатов у них нет.
Выяснилось, что я ошибся. Есть расширение, которое имеет ASN1 номер 2.16.840.1.113733.1.7.48.1 (в символьной нотации {joint-iso-itu-t(2) country(16) us(840) organization(1) symantec(113733) pki(1) policies(7) 48 1}) и носит смысл смысл «Thawte Extended Validation (EV) Certification Practice Statement (CPS) v. 3.3».
Браузеры (по крайней мере, Fx) его обрабатывают. Т.е. браузер отличает сертификат Thawte EV от других валидных сертификатов.
Разумеется, ни один уважающий себя ЦС мне сертификат с таким полем не захочет выдавать (если только это не Thawte и он не произвёл EV, разумеется). Но опять же, любой не уважающий себя ЦС вполне (технически) способен это сделать, т.е. я могу сам себе сделать ЦС и выдать как бы Thawte EV-сертификат.
Браузеры (по крайней мере, Fx) его обрабатывают. Т.е. браузер отличает сертификат Thawte EV от других валидных сертификатов.
Разумеется, ни один уважающий себя ЦС мне сертификат с таким полем не захочет выдавать (если только это не Thawte и он не произвёл EV, разумеется). Но опять же, любой не уважающий себя ЦС вполне (технически) способен это сделать, т.е. я могу сам себе сделать ЦС и выдать как бы Thawte EV-сертификат.
1) некоторые компании для всех вопросов работают с одним поставщиков, они готовы переплачивать в 10 раз, но не распыляться за каждую копейку, ища где подешевле
2) покупается не столько продукт (сертефикат), сколько поддержка (у траста она будет одна, у ресселера совсем другая, или просто будет отсутствовать)
2) покупается не столько продукт (сертефикат), сколько поддержка (у траста она будет одна, у ресселера совсем другая, или просто будет отсутствовать)
Для своих сайтов использую www.startssl.com/ — бесплатный отличный сертификат для персонального использования.
Для корпоративных в основном www.rapidssl.com/
Для корпоративных в основном www.rapidssl.com/
Спасибо за инфу!
>> Для того, чтобы активировать возможность работы протокола HTTPS… потребуется выделенный IP для конкретного сайта.
А разве SNI (Server Name Indication) не снимает это ограничение?
А разве SNI (Server Name Indication) не снимает это ограничение?
Снимает. Это ошибка в статье.
SNI — относительно новая возможность, доступна в PHP c версии 5.3.2 и требует PHP собранного с библиотекой OpenSSL версии 0.9.8j или выше.
Поддерживается всеми новыми браузерами, начиная с версий:
Opera 8.0;
MSIE 7.0 (но только на Windows Vista и выше);
Firefox 2.0 и другие браузеры, использующие Mozilla Platform rv:1.8.1;
Safari 3.2.1 (Windows-версия поддерживает SNI только на Vista и выше);
и Chrome (Windows-версия также поддерживает SNI только на Vista и выше).
Но далеко не все знают про эту опцию и используют ее, в большинстве случаев клиенты используют SSL вместе с выделенным IP.
Поддерживается всеми новыми браузерами, начиная с версий:
Opera 8.0;
MSIE 7.0 (но только на Windows Vista и выше);
Firefox 2.0 и другие браузеры, использующие Mozilla Platform rv:1.8.1;
Safari 3.2.1 (Windows-версия поддерживает SNI только на Vista и выше);
и Chrome (Windows-версия также поддерживает SNI только на Vista и выше).
Но далеко не все знают про эту опцию и используют ее, в большинстве случаев клиенты используют SSL вместе с выделенным IP.
Уважаемый, сдерживался я, сдерживался, но не могу больше.
Вы некомпетентны.
Во-первых, поддержка SNI никакого отношения к PHP не имеет. Веб-сервер может и вообще не знать про PHP, а SNI он будет уметь.
Это в Apache принято встраивать PHP при помощи SAPI-модуля — тут да, сервер как бы «сам умеет» выполнять php-скрипты с помощью плагина. А вот nginx с PHP не знаком — интерпретатор не встроен в сервер, он связывается с интепретатором по стандартному протоколу, которым может быть CGI, FastCGI, UWSGI.
А SNI умеет как Apache, так и nginx (и оба — потому, что его умеет бибиотека OpenSSL).
Во-вторых, то, что про SNI кто-то там не знает, не значит, что он не будет работать и что его невозможно настроить.
Вы некомпетентны.
Во-первых, поддержка SNI никакого отношения к PHP не имеет. Веб-сервер может и вообще не знать про PHP, а SNI он будет уметь.
Это в Apache принято встраивать PHP при помощи SAPI-модуля — тут да, сервер как бы «сам умеет» выполнять php-скрипты с помощью плагина. А вот nginx с PHP не знаком — интерпретатор не встроен в сервер, он связывается с интепретатором по стандартному протоколу, которым может быть CGI, FastCGI, UWSGI.
А SNI умеет как Apache, так и nginx (и оба — потому, что его умеет бибиотека OpenSSL).
Во-вторых, то, что про SNI кто-то там не знает, не значит, что он не будет работать и что его невозможно настроить.
Спасибо за пояснения, действительно про SNI лично ранее не знал, выше процитировал статью про настройку SNI для nginx.
Правда точно также и большинство клиентов не знает про SNI, я уточню про эту опцию на наших серверах и возможно мы отдельно добавим информацию про такую возможность в базу знаний.
Спасибо за полезную подсказку…
Правда точно также и большинство клиентов не знает про SNI, я уточню про эту опцию на наших серверах и возможно мы отдельно добавим информацию про такую возможность в базу знаний.
Спасибо за полезную подсказку…
На всякий случай, RFC 4366, пункт 3.1 — место, где SNI описано. Кстати, из названия RFC (именно, TLS extensions) следует, что SNI — это (стандартизированное) расширение протокола TLS v1, и может вполе применяться не только для HTTPS, но и любых других протоколов, которые способны работать поверх с TLS. А это, например, SMTP, IMAP, POP3, XMPP (в котором ещё есть свой собственный механизм, реализующий то же самое).
Кстати говоря, что касается покупки и использования сертификатов — абсолютно всё, что применимо к HTTP, применимо и к ним тоже. Т. е. для IMAP over TLS на своём сервере потребуется купить сертификат. И можно настроить проверку клиентских сертификатов, и даже аутентифицировать пользователей по ним — по Subject DN в клиентском сертификате, а не по логину-паролю, как это делается традиционно.
Кстати говоря, что касается покупки и использования сертификатов — абсолютно всё, что применимо к HTTP, применимо и к ним тоже. Т. е. для IMAP over TLS на своём сервере потребуется купить сертификат. И можно настроить проверку клиентских сертификатов, и даже аутентифицировать пользователей по ним — по Subject DN в клиентском сертификате, а не по логину-паролю, как это делается традиционно.
На всякий случай: RFC 4366 уже 4 года как устарел. Актуальный RFC 6066.
Какую статью? В статье на nginx.org про php ни слова, и никогда не было.
Ошибся, из этой статьи информация про браузеры. Про PHP — отсюда: php.net/manual/ru/openssl.constsni.php
Для nginx есть нюансы
— системный OpenSSL может оказаться старой версии (ниже 1.0.1)
— сам nginx версии ниже 1.1.13 и 1.0.12
— TLSv1.1/1.2 могут быть не включены в директиве ssl_protocols
А так да, вполне себе работает
— системный OpenSSL может оказаться старой версии (ниже 1.0.1)
— сам nginx версии ниже 1.1.13 и 1.0.12
— TLSv1.1/1.2 могут быть не включены в директиве ssl_protocols
А так да, вполне себе работает
Это одна из тех статей, где в комментариях узнаешь чуть больше, чем из основной статьи.
Как минимум ключ должен хранится в директории недоступной извне и для пользователей.
Запарольте ключ, и сервер (Апач точно) при старте будет спрашивать пароль. Минус простой — сам не запустится
Теоретически, для этого придуман TPM. OpenSSL может использовать TPM в качестве криптодвижка, т.е. основные функции, вроде собственно шифрования, делегирования и т. п., делать с его помощью.
Однако, попробовать это самому ни разу не довелось, в нашей стране TPM нелегален.
Однако, попробовать это самому ни разу не довелось, в нашей стране TPM нелегален.
> после успешной проверки выпустит SSL сертификат с вашими данными и разрешит вам использовать SSL
Выпустить сертификат — это как раз да, то, что я от них и жду. Но «разрешать мне использовать SSL» — это не совсем в их власти и функциях. Я SSL могу использовать, когда захочу (если настрою, конечно), разница только в том, кто создаст сертификат.
Выпустить сертификат — это как раз да, то, что я от них и жду. Но «разрешать мне использовать SSL» — это не совсем в их власти и функциях. Я SSL могу использовать, когда захочу (если настрою, конечно), разница только в том, кто создаст сертификат.
Спасибо за статью! К сожалению, совсем нет информации по сертификатам для разработчиков (Code Signing сертификаты), например, какой тип сертификата, а так же какой центр сертификации вы можете посоветовать для подписи расширений для Firefox, что бы при установке браузер не выдавал предупреждения и не писал «Author not verified»?
Спасибо!
Спасибо!
Добавлю про wildcard — они действуют только на домены, которые на один уровень выше, чем тот, на который был выдан сертификат, т.е. если вы покупаете wildcard на *.site.ru, то www.site.ru, admin.site.ru в браузере будут выглядеть нормально, но на www.admin.site.ru браузер уже выведет предупреждение.
Полезное уточнение, спасибо.
Еще один момент забыл упомянуть в статье. Если обычный сертификат заказать для www.domainname.com то такой сертификат будет работать и на domainname.com, а вот наоборот работать не будет.
Поддержка этой опции: защита домена с www и без www есть не у всех сертификатов, работает эта опция у следующих сертификатов:
• RapidSSL
• QuickSSL Premium
• True BusinessID
• True BusinessID with EV
Еще один момент забыл упомянуть в статье. Если обычный сертификат заказать для www.domainname.com то такой сертификат будет работать и на domainname.com, а вот наоборот работать не будет.
Поддержка этой опции: защита домена с www и без www есть не у всех сертификатов, работает эта опция у следующих сертификатов:
• RapidSSL
• QuickSSL Premium
• True BusinessID
• True BusinessID with EV
> Если обычный сертификат заказать для www.domainname.com то такой сертификат будет работать и на domainname.com, а вот наоборот работать не будет.
Это вовсе не всегда так, а только если в сертификате прописаны subject alt name (ну то есть, сертификат выдан «для нескольких доменов сразу»). Некоторые делают так «по умолчанию», если основное subject cname начинается с www, но это необязательно.
А вообще так можно сделать и для любых других имён. Прописываем пять разных subject alt name, и для всех шести (основной + пять альтов) наш сертификат работает. Правда, как и SNI, это поддерживается не всеми. Например, вот сообщение, что это не поддерживалось в Андроиде (не знаю, починили ли).
Это вовсе не всегда так, а только если в сертификате прописаны subject alt name (ну то есть, сертификат выдан «для нескольких доменов сразу»). Некоторые делают так «по умолчанию», если основное subject cname начинается с www, но это необязательно.
А вообще так можно сделать и для любых других имён. Прописываем пять разных subject alt name, и для всех шести (основной + пять альтов) наш сертификат работает. Правда, как и SNI, это поддерживается не всеми. Например, вот сообщение, что это не поддерживалось в Андроиде (не знаю, починили ли).
Сертификаты в которых можно прописать пять разных subject alt name — это SAN сертификаты, я писал о них в статье, в остальных сертификатах такой возможности нет.
wiki.cacert.org/VhostTaskForce#Interoperability_Test вот анализ софтовой поддержки различных способов запихнуть несколько имён в один сертификат
SAN — один из способов. Другой — wildcard.
Других способов нет ;) если ваш сертификат поддерживает несколько имён (случай «с www и без www в том числе), значит, он сделан одним из этих способов.
SAN — один из способов. Другой — wildcard.
Других способов нет ;) если ваш сертификат поддерживает несколько имён (случай «с www и без www в том числе), значит, он сделан одним из этих способов.
Где происходит физически генерация csr? На вашем сервере? Если так, то одновременно с csr генерируется закрытый ключ. По каким каналам вы осуществляете доставку закрытого ключа?
В любом случае, даже если этот канал очень надежный, я считаю такой закрытый ключ скомпрометированным, поскольку он был доступен вышим сотрудникам
В любом случае, даже если этот канал очень надежный, я считаю такой закрытый ключ скомпрометированным, поскольку он был доступен вышим сотрудникам
CSR клиент генерирует сам при заказе сертификата, где сохранять закрытый ключ также решает клиент, для выпуска сертификата нам не нужен закрытый ключ и клиент нам его никак не передает.
Естественно если это происходит на обычном виртуальном, то у администраторов с root доступом к серверу есть доступ и к ключам, которые там хранятся.
Естественно если это происходит на обычном виртуальном, то у администраторов с root доступом к серверу есть доступ и к ключам, которые там хранятся.
Генерирует сам клиент, но программа генерации запускается на вашем сервере? Тогда вам ничто не мешает параллельно с выдачей закрытого ключа клиенту сохранить его у себя
Если сертификат будет использоваться клиентом у себя на сервере, то и генерирует он ключ у себя на сервере, если сертификат будет использовать у нас на виртуальном хостинге — то и генерация происходит на том сервере, где размещен клиент.
Вы ведь, когда свои сайты храните на хостинге, тоже доверяете какому-то хостеру все свои файлы и данные и осознаете при этом, что часть сотрудников хостера имеет полный доступ к данным на сервере.
Вы ведь, когда свои сайты храните на хостинге, тоже доверяете какому-то хостеру все свои файлы и данные и осознаете при этом, что часть сотрудников хостера имеет полный доступ к данным на сервере.
Вы создаёте приватный ключ и вместе с ним csr. csr — публичная штука (открытый ключ + допинформация), покидает комп. Приватный ключ — создаётся вами на вашей системе и никогда никуда с неё не перемещается.
Например, у startssl free это сделано в браузере, посредством javascript, т.е. приватный ключ генерируется прямо в браузере на стороне клиента, и никуда из него не пересылается.
Например, у startssl free это сделано в браузере, посредством javascript, т.е. приватный ключ генерируется прямо в браузере на стороне клиента, и никуда из него не пересылается.
Повторюсь еще раз CSR и приватный ключ генерируется на сервере, где будет использоваться сертификат, какими средствами зависит от сервера и операционной системы.
Хотя при желании вы можете сгенерировать сертификат и у себя на компьютере.
Приватный ключ — не создается на нашей системе, за исключением случаев, когда клиент покупает у нас виртуальный хостинг и генерирует сертификат через панель управления хостингом.
Хотя при желании вы можете сгенерировать сертификат и у себя на компьютере.
Приватный ключ — не создается на нашей системе, за исключением случаев, когда клиент покупает у нас виртуальный хостинг и генерирует сертификат через панель управления хостингом.
Теперь понятно, спасибо
Я просто спрашивал это потому, что сам в свое время реализовывал со студентами учебный проект, в котором пользователям подписывались сертификаты. Была дилемма: либо пользователи должны знать openssl (утилиту) и сами генерировать ключ, либо сервис генерирует пользователю ключ и выдает при регистрации, но тогда ключ сразу скомпрометирован. Классическая пролемы удобство vs безопасность. Тогда пришли к выводу, что компромиссный вариант — создать java applet — и пользователю удобно, и генерация на его десктопе без передачи по каналам. Альтернативные варианты — activex, flash или javascript (последние 2 — для маньяков-программистов). Однако этот вариант с java или альтернативами так и остался не реализованным…
>у startssl free это сделано в браузере, посредством javascript
интересно, есть какие-нибудь библиотеки, или они самостоятельно реализовывали md5, sha1, rsa и т. п. Кстати, и генератор ПСЧ еще нужен, интересно его проверить на уязвимости.
интересно, есть какие-нибудь библиотеки, или они самостоятельно реализовывали md5, sha1, rsa и т. п. Кстати, и генератор ПСЧ еще нужен, интересно его проверить на уязвимости.
s0laris, Вы привели в пример скриншоты сайтов с самоподписанным сертификатом и сертификатом «расширенной проверки» EV. А покажите, как будут выглядеть сертификаты DV и OV. В виде скриншотов или ссылки на сайты с этими видами сертификатов дайте, пожалуйста.
Вторая часть статьи по Code Signing сертификаты опубликована: habrahabr.ru/company/tuthost/blog/152867/
Спасибо Вам большое за статью! По этой статье я как раз для себя развеял вопросы по SSL сертификатам.
Вопрос, с точки зрения безопасности, чем отличается TLS и SSL сертификат?
Почему SSL считается менее безопасным?
Почему SSL считается менее безопасным?
Сертификат это файл, который подписан кем-либо, и он нет знает где его будут использовать. TLS и SSL это протоколы, которые используют сертификат.
SSL не безопасен в связи с тем что он уязвим к атакам BEAST и POODLE, эти уязвимости невозможно починить только с серверной стороны.
p.s. для вопросов есть toster
SSL не безопасен в связи с тем что он уязвим к атакам BEAST и POODLE, эти уязвимости невозможно починить только с серверной стороны.
p.s. для вопросов есть toster
Просьба к автору, если есть возможность — добавить в статью диаграмму последовательности работы сертификата и проверки сертификата.
Спасибо, помогли выбрать и установить, тот сертификат, который нам был нужен.
С момента выхода статьи прошло уже много время. Может имеет смысл подновить информацию в свете новых реалий и возможностей возникших в течении этого периода? Например, о новых возможностях в плане бесплатной регистрации и её автоматического продления, новых версий протоколов TLS итп
Ваш сервер автоматически сопоставит выпущенный сертификат, со сгенерированным приватным ключем.
Что за приватный ключ, откуда его брать? На reg.ru для полученного сертификата предоставляются следующие файлы (приватного ключа среди них не вижу):
Sign up to leave a comment.
Цифровые SSL сертификаты. Разновидности, как выбрать?