Вы отозвали сертификат. Почему браузер может этого не заметить
Перед аудитом инфраструктуры мы заменили сертификат на тестовом стенде, а прежний отправили в отзыв. Это стандартная процедура: старые ключи и сертификаты не должны оставаться действующими без необходимости. Но возник практический вопрос - действительно ли отзыв работает так, как ожидается?
Для проверки на отдельном порту был запущен сервис со старым сертификатом. Страница открылась без предупреждений, а в адресной строке остался привычный значок замка. Сначала это выглядело как ошибка: возможно, удостоверяющий центр ещё не обновил данные, запрос направился не к тому серверу или был указан неправильный серийный номер.
Однако ручная проверка показала обратное. Из сертификата был взят адрес списка отзыва, после чего CRL скачали и нашли в нём нужный серийный номер вместе с датой отзыва. Сертификат действительно был отозван - просто браузер не стал это проверять в момент подключения.
Почему браузер не обязан проверять отзыв
Сертификат подтверждает, что определённый открытый ключ принадлежит конкретному домену. Это утверждение удостоверяющий центр выдаёт на ограниченный срок, а сам документ размещается на сервере. Отзыв - отдельное сообщение центра о том, что ранее выданное подтверждение больше нельзя считать действительным. Оно хранится уже не на сайте, а у удостоверяющего центра.
Следовательно, для проверки отзыва клиенту необходимо обратиться к третьей стороне прямо во время TLS-подключения. Теоретически всё просто, но на практике появляются задержки, проблемы с доступностью и вопросы конфиденциальности.
Каждое новое соединение может потребовать дополнительный сетевой запрос. При нестабильном интернете это увеличивает время загрузки страниц. Кроме того, удостоверяющий центр узнаёт, когда и какой сайт открывает пользователь. Если один центр выпустил сертификаты для множества ресурсов, он потенциально получает значительную часть истории посещений.
Самая сложная проблема - отсутствие ответа. Если считать молчание удостоверяющего центра ошибкой и разрывать соединение, сбой его инфраструктуры способен сделать недоступными огромные сегменты интернета. Если же продолжать работу, проверка становится необязательной: атакующему, контролирующему канал связи, достаточно заблокировать запрос к центру.
В массовых браузерах победила стратегия soft-fail: при отсутствии ответа соединение обычно не прерывается. Поэтому проверка отзыва сертификата часто превращается не в строгую защиту, а в дополнительную формальность.
CRLSet, CRLite и локальные агрегаты
Важно различать онлайн-проверки и заранее подготовленные списки.
Chrome и браузеры на его основе, как правило, не обращаются к удостоверяющему центру за актуальным статусом каждого сертификата. Google формирует собственный набор CRLSet на основе списков центров сертификации и доставляет его браузерам отдельными обновлениями. При этом в такой набор попадает не вся информация об отозванных сертификатах, а только отобранная часть.
Firefox начиная с версии 137 по умолчанию использует CRLite - компактный агрегат, рассчитанный на полное покрытие отзывов. Если нужный сертификат присутствует в базе, решение принимается локально и практически мгновенно. В этом сценарии нет классического soft-fail: браузер либо знает, что сертификат отозван, либо не располагает соответствующей записью.
Для сертификатов, которые не покрываются CRLite, может сохраняться OCSP-проверка с мягким отказом. Общий принцип у обоих подходов один: браузер не ждёт ответа удостоверяющего центра в момент каждого подключения, а использует данные, заранее собранные и доставленные специальным механизмом.
Поэтому ручная диагностика всё ещё важна. Если нужно понять, как проверить отзыв TLS сертификата, недостаточно просто открыть сайт в Chrome или Firefox. Следует отдельно проверить OCSP, CRL и фактический статус сертификата через инструменты командной строки или специализированные сервисы.
Почему Let's Encrypt отказался от OCSP
У сертификатов Let's Encrypt адрес OCSP в последнее время может отсутствовать: вместо него остаётся ссылка на список отзыва. Центр сертификации отключил OCSP по нескольким причинам. Сервис создавал большую нагрузку, требовал заметных расходов, раскрывал удостоверяющему центру сведения о посещаемых ресурсах и при этом плохо защищал пользователей из-за модели soft-fail.
Списки отзыва устроены иначе. Сертификат указывает не на единую гигантскую базу, а на конкретный фрагмент CRL. На момент проверки один такой файл занимал около 58 КБ и содержал 1485 отозванных сертификатов, но это динамические значения. Список обновляется, поэтому в разные моменты его размер и содержимое будут отличаться.
Загрузить такой файл несложно, однако делать это перед каждым TLS-соединением бессмысленно. В результате клиентам всё равно приходится полагаться на кэшированные данные, обновления браузера или дополнительные механизмы контроля.
OCSP stapling: проверка без раскрытия посещений
Решение проблемы придумали давно: сервер сам обращается к удостоверяющему центру, получает подписанный ответ о статусе сертификата и прикладывает его к TLS-рукопожатию. Клиенту не требуется самостоятельно соединяться с центром, а подделать ответ невозможно благодаря цифровой подписи. Механизм называется OCSP stapling.
Но и у него есть ограничения. Если сервер не приложил OCSP-ответ, браузер обычно продолжает соединение. Для злоумышленника, завладевшего закрытым ключом, это означает возможность просто не передавать статус сертификата.
Вторая проблема связана со сроком действия ответа. OCSP-утверждение действительно несколько дней и не привязано к конкретному TLS-сеансу. Если положительный ответ был получен до отзыва, его можно использовать ещё некоторое время после того, как сертификат уже признан недействительным.
Для усиления контроля существует расширение Must-Staple. В сертификат добавляется требование: сервер обязан предоставить корректный OCSP-ответ, иначе клиент должен прекратить соединение. Это делает отзыв более эффективным, но повышает зависимость сайта от доступности и правильной настройки OCSP-инфраструктуры.
На практике важно учитывать и кэширование. Даже при корректно настроенном stapling браузер может использовать ранее полученные данные в пределах допустимого срока. Поэтому отзыв не всегда означает мгновенное прекращение доверия на всех устройствах.
Что проверить владельцу сервиса
Администратору стоит тестировать не только срок действия сертификата, но и весь жизненный цикл: выпуск, замену, продление, отзыв и обновление статуса. Для этого полезны несколько независимых сценариев:
- проверить наличие сертификата в CRL;
- запросить OCSP-статус;
- убедиться, что сервер передаёт актуальный stapled response;
- проверить поведение клиентов при отсутствии ответа;
- протестировать цепочку сертификации и промежуточные центры;
- оценить, как быстро обновляются внутренние и внешние агрегаты.
Онлайн-инструменты удобны для первичной диагностики: проверка SSL сертификата онлайн помогает быстро увидеть срок действия, цепочку и отдельные признаки проблем. Однако результаты таких сервисов не всегда отражают поведение конкретного браузера или корпоративного прокси.
Внутри организации лучше автоматизировать мониторинг и аудит SSL сертификатов. Система должна заранее предупреждать об окончании срока действия, изменении цепочки, появлении неожиданных сертификатов и проблемах с OCSP stapling. Для критичных сервисов полезно сохранять историю проверок: это позволяет отличить единичный сетевой сбой от систематической ошибки конфигурации.
Наконец, проверять статус следует с разных сетевых площадок. Доступ к OCSP и CRL может отличаться для пользователей из разных регионов, за прокси или через корпоративные фильтры. Только комплексная проверка показывает, насколько отзыв действительно работает в реальной эксплуатации, а не только в лабораторном сценарии.
