CRL и OCSP — два способа, которыми доверяющая сторона (relying party) узнаёт, что сертификат отозвали раньше, чем истёк срок его действия. Список отзыва сертификатов (certificate revocation list, CRL; RFC 5280, § 5) — подписанный перечень отозванных серийных номеров, который клиенты скачивают; протокол OCSP (Online Certificate Status Protocol, RFC 6960) отвечает на запрос об одном сертификате. В публичной веб-PKI картина с 2024 года решительно изменилась: CRL стали обязательными, OCSP — необязательным, а крупнейший центр сертификации (certificate authority, CA) отключил OCSP.
Коротко о главном
| CRL | OCSP | |
|---|---|---|
| Спецификация | RFC 5280, § 5 | RFC 6960 (nonce: RFC 8954) |
| Что получает клиент | Подписанный список всех отозванных серийных номеров в своей области действия | Подписанный статус одного серийного номера (не отозван, отозван, неизвестен) |
| Размер (замер 20 окт. 2026 г.) | Фрагмент CRL Let's Encrypt: 62 116 байт, 1 591 запись | Ответ OCSP от DigiCert: 471 байт |
| Актуальность | От thisUpdate до nextUpdate (у этого фрагмента: 9 дней) | Срок действия ответа (у этого ответа: 7 дней) |
| Конфиденциальность | Сервер узнаёт лишь то, что CRL был скачан | OCSP-ответчик узнаёт, какой сайт посещает клиент |
| Зависимость от доступности | Можно кешировать, зеркалировать и загружать заранее | Работа зависит от OCSP-ответчика в реальном времени, если ответ не прикреплён (stapling) |
| Правило веб-PKI (Базовые требования) | Обязательны с 15 марта 2024 года; новый CRL не реже чем раз в 4 дня (раз в 7 дней, если в каждом сертификате есть URL OCSP) и не позднее чем через 24 часа после отзыва | Необязателен с 15 марта 2024 года |
| Использование в браузерах | В агрегированном виде: CRLite в Firefox, CRLSets в Chrome | Firefox перестал отправлять запросы для DV-сертификатов (версия 142); Chrome не отправляет запросы для большинства сертификатов |
| Доставка через сервер | Неприменимо | OCSP stapling (status_request, RFC 6066) |
Как работает каждый из них
CRL указывает своего издателя, содержит thisUpdate и nextUpdate, монотонно возрастающий номер CRL и по одной записи на каждый отозванный сертификат (серийный номер, дата отзыва, необязательная причина), а подписывает его CA. Сертификаты ссылаются на свой CRL в расширении CRL Distribution Points (точки распространения CRL); крупные CA разбивают CRL на фрагменты, чтобы каждый файл оставался приемлемого размера, а публичные CA раскрывают полный набор URL своих CRL в CCADB, чтобы агрегаторы могли собрать все отзывы. Клиенты, которые проверяют CRL, скачивают и кешируют их, а дельта-CRL (RFC 5280, § 5.2.4) позволяют сократить трафик для больших списков.
Клиент OCSP отправляет хеш имени издателя, хеш ключа издателя и серийный номер на URL из расширения сертификата Authority Information Access; OCSP-ответчик возвращает подписанный статус с собственным периодом действия. Ответы можно кешировать до nextUpdate, а серверы могут прикреплять свежий ответ к TLS-рукопожатию (stapling), чтобы клиентам не нужно было обращаться к CA.
Приведённые выше измерения сделаны на реальных данных: сертификат Let's Encrypt, выпущенный в сентябре 2026 года, ссылается только на http://ye2.c.lencr.org/96.crl (URL OCSP в нём нет), и этот фрагмент занимал 62 КБ; сертификат DigiCert по-прежнему содержит http://ocsp.digicert.com, и ответ по этому адресу занял 471 байт.
Почему OCSP сошёл на нет в вебе
В браузерах проверку OCSP в реальном времени погубили три свойства. Конфиденциальность: каждый запрос сообщает CA, какой сайт и с какого IP-адреса посещает пользователь. Доступность: медленный или недоступный ответчик либо блокирует загрузку страниц, либо, поскольку браузеры выбрали мягкий отказ (soft-fail), молча игнорируется, а значит, атакующий, способный заблокировать ответчик, сводит проверку на нет. Стоимость: ответчики должны обслуживать каждую загрузку страницы в интернете. OCSP stapling устранил проблемы с конфиденциальностью и стоимостью, но требовал, чтобы каждый сервер надёжно обновлял ответы, а Must-Staple (RFC 7633), с которым stapling стал бы обязательным, поддерживался только в Firefox.
CA/Browser Forum ответил бюллетенем SC-063 (действует с 15 марта 2024 года): CRL обязательны, OCSP необязателен. 7 мая 2025 года Let's Encrypt перестал включать URL OCSP в новые сертификаты и принимать заказы с Must-Staple, а 6 августа 2025 года отключил свои OCSP-ответчики. В Firefox 137 механизм CRLite включён для всех пользователей десктопной версии: это компактное локальное кодирование всех отзывов среди сертификатов из журналов CT, которое обновляется каждые 12 часов и требует в среднем около 300 КБ загрузки в день. Затем Firefox 142 перестал отправлять запросы OCSP для сертификатов с проверкой домена (DV). Chrome вместо запросов по каждому сайту полагается на CRLSets — тщательно отобранный набор, в который входят прежде всего отзывы с серьёзными последствиями.
Третий вариант: краткосрочные сертификаты
Сертификату, который действует несколько дней, проверка отзыва не нужна: к тому моменту, когда сведения об отзыве успели бы распространиться, срок его действия уже истечёт. Базовые требования (Baseline Requirements) разрешают CA не включать сведения об отзыве в краткосрочные сертификаты (для выпущенных с 15 марта 2026 года это сертификаты сроком не более 7 дней), а Let's Encrypt с января 2026 года выпускает сертификаты на 160 часов по ACME-профилю shortlived. Вместе с общим сокращением сроков действия до 47 дней к 2029 году (бюллетень SC-081v3) это превращает отзыв в страховку, а не в основное средство контроля. Калькулятор сроков действия сертификатов показывает ограничения в зависимости от даты выпуска.
Что когда выбирать
- Публичные TLS-серверы: ничего особенного делать не нужно; убедитесь, что сертификаты выпускает CA, который публикует CRL, и не включайте Must-Staple. Уберите настройки stapling, которые приводят к сбою, когда URL OCSP нет.
- Клиентские программы, проверяющие публичные сертификаты: используйте системный механизм проверки (platform verifier); где это возможно, он применяет наборы данных об отзыве от разработчиков браузеров.
- Частная PKI со множеством клиентов, часть из которых работает офлайн: CRL с коротким интервалом до
nextUpdate, которые раздаёт отказоустойчивый HTTP-сервер. - Частная PKI с особо ценными сертификатами и клиентами, работающими онлайн: OCSP со stapling там, где протокол его поддерживает, и с политиками жёсткого отказа (hard-fail), если OCSP-ответчик находится под вашим контролем.
- Удостоверения рабочих нагрузок и сервисов: краткосрочные сертификаты (от нескольких часов до нескольких дней), которые выпускаются автоматически, вообще без инфраструктуры отзыва.
- Подпись кода и документов: для долгоживущих подписей отзыв по-прежнему важен; сочетайте CRL или OCSP с метками времени, чтобы проверяющие стороны могли узнать статус на момент подписания.
Заметки о миграции
- Найдите все зависимости от OCSP: настройки stapling на серверах, клиенты, у которых без OCSP проверка завершается отказом (hard-fail), мониторинг, который проверяет OCSP-ответчики.
- Сделайте stapling необязательным: nginx и Apache не должны отказываться запускаться, если в сертификате нет URL OCSP.
- В частных CA в первую очередь публикуйте CRL: добавьте точки распространения CRL в новые сертификаты, разбейте большие списки на фрагменты, задайте
nextUpdateв соответствии с вашим SLA по отзыву и раздавайте CRL по HTTP (не по HTTPS, чтобы избежать циклических зависимостей). - Сокращайте сроки действия, насколько позволяет автоматизация: каждый шаг уменьшает нагрузку, которая ложится на отзыв.
- Протестируйте отзыв от начала до конца: отзовите тестовый сертификат и убедитесь, что клиенты отклоняют его в ожидаемый срок. Декодер CRL и декодер OCSP покажут, что увидят клиенты.