SSL: Понимание самоподписанных сертификатов

Мне интересно, как самозаверяющие сертификаты обычно проверяются в установлении соединения SSL.SSL: Понимание самоподписанных сертификатов

Давайте посмотрим на self-signed certificates:

клиент и сервер, обеспечивающий self-signed certificate с его закрытым ключом (созданный с помощью OpenSSL например)
когда server получения "ClientHello" сообщение от client , он передает свой сертификат клиенту.
Сообщение отправлено клиенту, после чего клиенту необходимо проверить сертификат.

Когда клиент получает сертификат сервера, каковы его шаги для подтверждения этого сертификата? Я знаю, что самозаверяющие сертификаты вообще не должны использоваться на самом деле, если нет стороннего экземпляра (CA) для проверки.

Достаточно ли клиент принимает сертификат сервера без каких-либо дальнейших шагов или клиент уже предоставляет серверный «корневой» сертификат до установления соединения?

источник

2015-01-13 Leviathan

Ваш последний подзапрос на самом деле не имеет смысла в контексте самозаверяющего сертификата (не уверен, что «root» вы бы говорили). Кроме того, сообщение «CertificateVerify» используется только для проверки подлинности клиентского сертификата, не связано с проверкой сертификата сервера. – Bruno

Это идея подтверждения подлинности самоподписанных сертификатов. Когда я говорю о «корневом» сертификате сервера, я рассматриваю его как замену корневого сертификата для сертификата ЦС (в среде, не относящейся к самозанятому сертификату). Извините за ошибку в сообщении 'CertificateVerify' ;-) и спасибо за ваш совет. – Leviathan

Этот вопрос не соответствует теме, потому что речь идет не о программировании или разработке. Возможно, вам следует попросить [Суперпользователя] (http://superuser.com/) или [Информационная безопасность стека Exchange] (http://security.stackexchange.com/) – jww

Когда клиент получает сертификат сервера, каковы его шаги для подтверждения этого сертификата?

Клиент выполняет проверку цепочки сертификатов сертификата сертификата. Важные проверки: 1) подпись сертификата 2) предмет сертификата. Атрибут CN в поле Subject (или соответствующее имя в альтернативном имени объекта) должен соответствовать введенному URL. Например, вы подключаетесь к www.example.com, тогда это имя должно быть указано либо в теме и/или в расширении SAN. 3) достоверность сертификата 4) аннулирование сертификата 5) цепи сертификатов до доверенного корня (представлены в самоподписанной форме) 6) другие проверки, определенные в RFC5280 (включая, помимо прочего, расширенное использование ключа, ограничения политики , ограничения имен и т. д.).

В случае самоподписанного сертификата цепочка сертификатов состоит из одного элемента - сертификата сервера. В этом случае клиент пропускает только шаг 4, поскольку самозаверяющие сертификаты не могут быть отменены. И этот самозаверяющий сертификат должен быть явно доверен клиенту как доверенный корневой сертификат, потому что все самозаверяющие сертификаты являются корневыми сертификатами.

источник

2015-01-14 14:29:57 Crypt32

Итак, клиент всегда предоставляет самозаверяющий сертификат сервера в замене сертификата ca? – Leviathan

Обычно конечный объект (скажем, сервер) и корневой сертификат являются отдельными сертификатами. Однако RFC5280 не ограничивает использование единого сертификата как конечного и корневого сертификатов одновременно, потому что это (проверка сервера и проверка цепочки сертификатов) являются отдельными процедурами. Это нормальная ситуация с самозаверяющими сертификатами. – Crypt32

Вот и все! Благодарим за обращение к RFC5280. – Leviathan

SSL: Понимание самоподписанных сертификатов

ответ

Смежные вопросы