TL; сводка DR:
Срок действия сертификата сервера устанавливается:
- Проверка имени хоста
- Проверка подписей всей цепочки сертификатов
- Выполнение дополнительных проверок метаданных для каждого сертификата
- Проверка статуса отзыва каждого из задействованных сертификатов
- Проверка того, входит ли самоподписанный корневой сертификат цепочки в число сертификатов, которым доверяют по умолчанию
Объяснение
Предположим, вы хотите подключиться к https://mail.google.com (вы можете попробовать это в своем браузере!).
(реальный) сервер ответит сертификатом, выданным на mail.google.com, т. Е. В поле «Тема» сертификата вы найдете Common Name (CN) «mail.google.com» - ср. RFC 5280 для подробностей о полях сертификатов. Тот факт, что тема связана с URL-адресом сайта, очень важен для безопасности всей модели, и он активно проверяется вашей реализацией TLS («проверка имени хоста»), поскольку в противном случае было бы место для человека-человека. Средние атаки. То есть кто-то может приобрести действительный сертификат и выдать себя за mail.google.com без вашего уведомления.
В дополнение к проверке имени хоста ваша реализация TLS также проверит «действительность» сертификата. Вся процедура довольно сложна и включает проверку достоверности сертификата, но дополнительно будет проверено много других вещей, подробнее об этом через минуту.
Если вы посмотрите сертификат Google Mail в своем браузере, вы заметите, что на самом деле отображается три сертификата:
- mail.google.com
- Thawte SGC CA
- Государственный первичный центр сертификации класса 3 (VeriSign)
Модель заключается в том, что существует несколько (ну, к сожалению, уже не так много) доверенных корневых центров сертификации («корневых ЦС»), которые вы можете выбрать самостоятельно или (что более вероятно) предварительно настроены с помощью вашего программного обеспечения ( например, браузер), которым доверяют вслепую. Эти доверенные органы образуют якоря всей модели доверия «PKI» (Инфраструктура открытых ключей). Основная идея заключается в том, что доверенные объекты могут выдавать сертификаты другим органам и предоставлять им разрешение на повторную выдачу сертификатов (эти органы называются промежуточными центрами сертификации). Промежуточные СА могут снова рекурсивно применять эту процедуру до определенной точки, количество промежуточных СА между действительным сертификатом конечного объекта и сертификатом корневого СА, как правило, ограничено.
В какой-то момент промежуточный ЦС выдаст сертификаты «конечному объекту» (в нашем примере «mail.google.com»). Теперь процесс выдачи сертификата фактически означает, что сторона, запрашивающая сертификат, сначала создаст пару открытый / закрытый ключ и использует их для аутентификации запроса сертификата, который отправляется в центр сертификации. Орган, выдавший лицензию, создает сертификат для подчиненного объекта (промежуточного ЦС или конечного объекта) путем «подписания» этого сертификата с использованием своего собственного закрытого ключа с использованием асимметричного алгоритма, такого как RSA, и путем дополнительного включения открытого ключа запрашивающей стороны во вновь сгенерированный сертификат. Корневой ЦС обладает так называемым самоподписанным сертификатом, т. Е. Корневой ЦС является единственным органом, который может подписать свой собственный сертификат и включить собственный открытый ключ. Конечно, закрытый ключ всегда остается скрытым.
Рекурсивный характер процесса выдачи сертификатов подразумевает, что для каждого сертификата конечного объекта существует уникальный способ создания «цепочки» сертификатов, которая ведет к корневому центру сертификации.Теперь, когда вы получаете сертификат конечного объекта при попытке подключения к сайту, защищенному TLS, следующая процедура будет применяться рекурсивно, пока вы не получите сертификат корневого центра сертификации:
- Найти сертификаторгана, выдавшего сертификат для проверки (подробности см. в RFC 5280).Если ничего не найдено: завершите работу с ошибкой.
- Возьмите открытый ключ сертификата-эмитента и проверьте подпись сертификата, который должен быть подтвержден, с помощью этого открытого ключа.
- Проверьте многодополнительные вещи, такие как то, истек ли срок действия сертификата и не является ли он еще недействительным, «ограничения политики», «использование ключа», «использование расширенного ключа» ... (опять же, подробности в RFC).
- Статус отзыва сертификата (подробнее об этом позже)
Если все проверки были положительными, в конечном итоге вы получите самоподписанный сертификат, т. Е. Если субъект также является эмитентом (например,как сертификат VeriSign в нашем примере).Теперь последнее, что вам нужно проверить, это ли этот сертификат среди тех, которым вы слепо доверяете: если это так, все хорошо, и соединение будет успешным, если это не так, попытка соединения будет отклонена.
Как будто это уже не было достаточно сложно, описанные выше проверки не обрабатывают случаи, когда действительные сертификаты внезапно становятся мошенническими, например, случаи, когда сертификат украден или скомпрометированы закрытые ключи (например, Comodo и DigiNotar).В этих случаях обычная процедура состоит в том, чтобы «отозвать» те сертификаты, которые испортились, то есть вы хотите пометить их как недействительные, начиная с определенного момента времени (они все равно истекают в какой-то момент, но на оставшуюся часть этого периодаони уже должны быть помечены как недействительные).В этих случаях центры сертификации могут выдавать списки отзыва сертификатов (каталог сертификатов, объявленных как недействительные) или ответы OCSP (информация для одного или в редких случаях набор сертификатов), которые предоставляют клиентам информацию о том, помечен ли данный сертификат как недействительный.или нет.Статус отзыва должен быть проверен для всех сертификатов в цепочке, если один из них будет помечен как недействительный, тогда сертификат конечного объекта не может быть доверенным, и соединение также должно быть отклонено.