Вы отозвали сертификат. Почему браузер всё равно открыл сайт
Перед аудитом мы обновили сертификат на тестовом стенде, а прежний отправили в отзыв. Процедура стандартная: старый ключ больше не используется, поэтому сертификат признаётся недействительным досрочно.
Чтобы убедиться, что отзыв действительно работает, я запустил сервис на отдельном порту и настроил его со старым сертификатом. Затем открыл страницу в браузере - и увидел привычный интерфейс с замком. Никаких предупреждений, сообщений об угрозе или блокировки соединения не появилось.
Сначала возникло подозрение, что отзыв не обработался: возможно, запрос попал не в тот центр сертификации, был указан неправильный серийный номер или удостоверяющий центр ещё не успел обновить данные. Однако ручная проверка показала обратное. В списке отозванных сертификатов, доступном по адресу из самого сертификата, действительно присутствовал нужный серийный номер и дата отзыва.
Сертификат подтверждает, что определённый открытый ключ принадлежит конкретному домену. Это утверждение действует в установленный период и передаётся клиенту вместе с цепочкой доверия. Отзыв - отдельное сообщение удостоверяющего центра: прежнее подтверждение больше нельзя считать действительным.
Чтобы узнать об отзыве, клиенту нужно получить актуальную информацию от третьей стороны непосредственно в момент подключения. На практике именно здесь начинаются проблемы, связанные не с криптографией, а с архитектурой и эксплуатацией.
Почему браузеры не проверяют отзыв напрямую
Самый очевидный способ - отправлять запрос в удостоверяющий центр при каждом TLS-соединении. Но такая схема добавляет задержку. При нестабильном или медленном интернете дополнительное обращение становится заметным, причём повторяется для множества соединений и страниц.
Есть и проблема конфиденциальности. Запрос к центру сертификации может показать, какой сайт открывает пользователь и в какое время. Организация, выпустившая сертификат, потенциально получает сведения о посещениях ресурсов, использующих её сертификаты.
Главный вопрос - как поступать, если удостоверяющий центр не отвечает. При строгой политике отсутствие ответа нужно считать ошибкой и блокировать соединение. Тогда временный сбой инфраструктуры центра способен вывести из строя огромное количество сайтов.
Если же соединение разрешать при отсутствии ответа, проверка теряет смысл. Атакующему, который контролирует сетевой канал, достаточно заблокировать запрос к центру - и браузер продолжит работу со старым или отозванным сертификатом. Именно поэтому в массовых браузерах закрепился режим soft-fail: отсутствие ответа не приводит к разрыву соединения.
В результате проверка отзыва часто выглядит убедительно только на бумаге. Технически возможность проверить статус существует, но браузер не обязан делать это строго и синхронно для каждого подключения.
Как работают Chrome и Firefox
Chrome и браузеры на его основе обычно не выполняют онлайн-проверку статуса обычных сертификатов при каждом соединении. Вместо этого используется локальный набор отозванных сертификатов CRLSet. Google собирает данные из списков удостоверяющих центров, обрабатывает их и доставляет браузеру отдельными обновлениями.
Однако CRLSet не является полной копией всех отзывов. В него попадает только часть сертификатов, выбранная по внутренним правилам. Поэтому отсутствие сертификата в таком наборе ещё не доказывает, что он действителен.
Firefox с версии 137 по умолчанию применяет CRLite - компактный агрегат данных об отозванных сертификатах. Если конкретный сертификат покрывается этим набором, решение принимается локально и практически мгновенно. В этом случае браузеру не нужно обращаться к удостоверяющему центру, а известный отзыв обрабатывается жёстче.
Для сертификатов, которые не покрыты CRLite, может сохраняться традиционная OCSP-проверка с политикой soft-fail. Общий принцип у обоих подходов одинаков: браузер не ждёт полноценный ответ от центра в момент каждого подключения, а использует данные, собранные заранее.
Почему OCSP постепенно уходит
Раньше основным механизмом проверки считался OCSP - Online Certificate Status Protocol. Браузер отправлял удостоверяющему центру запрос с серийным номером сертификата и получал ответ: сертификат действителен, отозван или статус неизвестен.
У этого метода есть несколько системных недостатков:
- дополнительный сетевой запрос при установлении соединения;
- зависимость от доступности инфраструктуры центра;
- раскрытие информации о посещаемых доменах;
- высокая нагрузка на OCSP-сервисы;
- невозможность надёжно блокировать соединение при режиме soft-fail.
Let's Encrypt отказался от OCSP и убрал соответствующие адреса из новых сертификатов. Вместо этого используются списки отзыва. Такой список разделён на отдельные фрагменты, а сертификат указывает на нужную часть. Размер конкретного фрагмента может быть небольшим - например, несколько десятков килобайт, включающих более тысячи записей. Но даже такой объём не означает, что браузер станет скачивать его перед каждым подключением.
Что такое OCSP stapling
Для устранения задержек и снижения риска утечки придумали OCSP stapling. В этой схеме сервер сам обращается к удостоверяющему центру и получает подписанный ответ о состоянии сертификата. Затем сервер прикладывает этот ответ к TLS-рукопожатию.
Клиенту не нужно напрямую связываться с центром. Подделать ответ нельзя: он заверен цифровой подписью удостоверяющего центра.
Однако и здесь остаются слабые места. Если сервер не приложил OCSP-ответ, многие клиенты всё равно продолжают соединение. Злоумышленнику, располагающему украденным закрытым ключом, достаточно не передавать stapled-ответ.
Вторая проблема связана со сроком действия самого ответа. Он может быть рассчитан на несколько дней и не привязан к конкретному TLS-сеансу. Поэтому положительный ответ, полученный до отзыва, иногда остаётся пригодным ещё некоторое время после него. Такой устаревший ответ можно повторно прикладывать к рукопожатию.
Зачем нужен Must-Staple
Для усиления OCSP stapling был предложен механизм Must-Staple. В сертификат добавляется специальное расширение, указывающее клиенту: сервер обязан предоставить актуальный OCSP-ответ.
Если такой ответ отсутствует или не проходит проверку, соединение должно быть отклонено. Это закрывает сценарий, когда сервер намеренно не прикладывает подтверждение статуса.
Но Must-Staple требует безошибочной настройки. Если сервер потеряет актуальный ответ, неправильно настроит автоматическое обновление или столкнётся с недоступностью OCSP-инфраструктуры, сайт станет недоступен даже при полностью исправном сертификате. Поэтому механизм не получил повсеместного распространения.
Почему отзыв не является мгновенным выключателем
Важно понимать: отзыв сертификата - не аналог немедленного отключения доступа. Он работает только в тех клиентах и сценариях, где статус действительно проверяется.
Если сертификат уже украден, отзыв не прекращает работу сервера автоматически. Злоумышленник может продолжать использовать ключ до тех пор, пока клиентская сторона не узнает об отзыве и не применит это знание.
Поэтому при компрометации ключа нельзя ограничиваться одной операцией отзыва. Нужно заменить сертификат, сгенерировать новую пару ключей, проверить настройки серверов, балансировщиков, прокси и резервных узлов, а также удалить старые ключи из хранилищ и систем автоматизации.
Как проверить отзыв самостоятельно
Для ручной диагностики следует:
1. определить серийный номер сертификата;
2. проверить срок его действия и цепочку доверия;
3. найти адреса CRL или OCSP в расширениях сертификата;
4. получить соответствующий список или ответ центра;
5. убедиться, что серийный номер присутствует среди отозванных;
6. проверить, учитывает ли этот статус конкретный браузер или TLS-клиент.
Важно не путать наличие записи в CRL с фактической блокировкой в браузере. Список может быть обновлён, но клиент ещё не загрузил новую версию. Либо браузер вообще использует другой механизм - локальный агрегат, собственную политику или ограниченный набор отзывов.
Что проверить администраторам
В инфраструктуре стоит заранее определить, как именно контролируется отзыв сертификатов. Полезно проверять не только браузер, но и серверные клиенты, мобильные приложения, API-шлюзы, почтовые системы и внутренние сервисы.
Следует отдельно протестировать поведение при следующих условиях:
- сертификат действителен;
- сертификат просрочен;
- сертификат отозван;
- OCSP недоступен;
- CRL не загружается;
- stapling отсутствует;
- stapled-ответ просрочен или некорректен.
Для критичных систем желательно не полагаться только на поведение публичных браузеров. Внутренние клиенты могут использовать более строгую политику и блокировать соединение при любой неопределённости статуса.
Итог прост: отзыв сертификата существует, но браузер не обязан немедленно узнавать о нём. Реальная защита зависит от выбранного механизма, частоты обновления данных, политики клиента и корректности настройки серверов. Поэтому проверять отзыв вручную полезно, а при компрометации ключа необходимо считать замену сертификата основной мерой, а отзыв - только частью процедуры реагирования.