Проверка сертификатов в TLS

Без проверки сертификата соединение TLS может быть установлено со злоумышленником, выдающим себя за сервер (атака посредника). Проверка сертификата гарантирует, что соединение установлено с легитимным сервером, контролирующим закрытый ключ.

Основные поля: субъект (кто владеет сертификатом), SubjectAltName (имена DNS и IP-адреса), издатель (подписывающий CA), срок действия (notBefore/notAfter), открытый ключ, подпись. Браузер проверяет все эти поля.

Сертификат сервера → сертификат промежуточного CA → корневой сертификат CA. Корневой CA самоподписан и предварительно установлен в хранилище доверия OS или браузера. Сервер отправляет свой сертификат и промежуточные сертификаты в сообщении о сертификатах во время рукопожатия TLS.

Каждый сертификат подписан вышестоящим издателем. Клиент проверяет: signature(cert_n) с использованием public_key(cert_{n+1}). Если какая-либо подпись недействительна, цепочка отклоняется. Корневому сертификату доверяют благодаря предварительной установке, а не подписи.

Клиент проверяет, что имя сервера совпадает с полем Subject или SubjectAltName сертификата (записями DNS). Подстановочные знаки (*.example.com) соответствуют одной метке. С 2000 года SAN имеет приоритет над CN при сопоставлении имени сервера.

Клиент проверяет условие notBefore ≤ текущее время ≤ notAfter для каждого сертификата в цепочке. Сертификаты с истёкшим сроком действия отклоняются, даже если их подписи действительны. Срок действия сертификатов сокращается: теперь браузеры ограничивают его примерно 398 днями.

CA публикует список отозванных сертификатов (CRL) — подписанный список серийных номеров отозванных сертификатов. Клиент загружает URL списка CRL (из расширения точек распространения CRL сертификата) и проверяет наличие серийного номера.

Протокол проверки статуса сертификатов через Интернет (OCSP) позволяет клиентам запрашивать у ответчика OCSP центра сертификации статус одного сертификата. Это быстрее, чем CRL, но увеличивает задержку. При прикреплении OCSP сервер включает подписанный ответ OCSP в рукопожатие TLS.

CT (RFC 6962) требует от CA регистрировать все выпущенные сертификаты в общедоступных журналах, допускающих только добавление записей. Браузеры проверяют наличие подписанных временных меток сертификата (SCT) в сертификате или расширении TLS. Это не позволяет оставаться незамеченной выдаче сертификатов с нарушениями.

Закрепление открытого ключа HTTP (HPKP, устарело) и закрепление сертификата в мобильных приложениях фиксируют определённый открытый ключ или хэш сертификата. Если сервер предъявляет другой сертификат, соединение отклоняется даже при его действительности — это предотвращает атаки в случае компрометации CA.

ERR_CERT_AUTHORITY_INVALID: корневому сертификату не доверяют. ERR_CERT_DATE_INVALID: срок действия истёк. ERR_CERT_COMMON_NAME_INVALID: имя сервера не совпадает. NET::ERR_CERT_REVOKED: OCSP или CRL сообщает об отзыве. Каждая ошибка соответствует сбою определённого этапа проверки.

Проверка сертификатов в TLS включает проверку цепочки, проверку подписей, сопоставление имён, проверку сроков действия и отзыв сертификатов. Далее: исторические атаки на TLS и способы их предотвращения в TLS 1.3.