Что такое OCSP и чем отличается от CRL

OCSP представляет собой протокол проверки актуального статуса X.509-сертификатов в режиме реального времени. Его основная задача — ответить на вопрос, был ли сертификат отозван удостоверяющим центром, без необходимости загружать большие списки отзыва.

В основе OCSP лежит модель запрос–ответ. Клиент формирует запрос к OCSP-респонденту, указывая серийный номер сертификата. Респондент возвращает одно из состояний: good, revoked или unknown. Такая модель позволяет получать актуальную информацию о конкретном сертификате с минимальной задержкой.

Процесс проверки включает несколько этапов:

  • Клиент извлекает из сертификата серийный номер и идентификатор издателя
  • Формируется OCSP-запрос, содержащий эти данные
  • Запрос отправляется на OCSP-сервер (респондер удостоверяющего центра)
  • Сервер проверяет статус сертификата в своей базе отзыва
  • Возвращается подписанный ответ с состоянием сертификата

Ключевой особенностью является то, что ответ подписывается удостоверяющим центром или доверенным OCSP-респондентом, что позволяет проверять его подлинность.

OCSP Stapling

Расширение OCSP stapling переносит ответственность за запрос статуса на сервер:

  • сервер периодически запрашивает OCSP-ответ
  • прикрепляет («степлит») его к TLS-рукопожатию
  • клиент получает статус сертификата без отдельного запроса к OCSP-серверу

Это снижает задержки и устраняет проблему утечки приватности, связанной с обращением клиента к стороннему сервису.


CRL представляет собой альтернативный механизм проверки отозванных сертификатов, основанный на централизованных списках. Удостоверяющий центр публикует файл, содержащий перечень серийных номеров сертификатов, которые больше не являются доверенными.

Принцип работы CRL

Модель работы CRL отличается от OCSP:

  • удостоверяющий центр формирует список отозванных сертификатов
  • список подписывается и публикуется на сервере распространения
  • клиент периодически загружает весь CRL
  • проверка осуществляется локально путем поиска серийного номера в списке

CRL может содержать тысячи или миллионы записей, что напрямую влияет на размер файла и время загрузки.

Структура CRL

CRL включает:

  • серийные номера отозванных сертификатов
  • дату следующего обновления
  • дату выпуска текущей версии
  • цифровую подпись удостоверяющего центра

Основная проблема подхода заключается в необходимости регулярного скачивания полного списка, даже если интересует только один сертификат.


Сравнение OCSP и CRL

Актуальность данных

OCSP предоставляет статус в реальном времени, так как запрос выполняется непосредственно к серверу удостоверяющего центра. CRL же зависит от частоты обновления списка, что может приводить к задержке между отзывом и его отражением в списке.

Производительность и нагрузка

OCSP создает нагрузку на серверы удостоверяющего центра из-за большого количества запросов. CRL, напротив, переносит нагрузку на клиента, который загружает и хранит весь список.

Размер данных

CRL может достигать значительных размеров, особенно в крупных PKI-инфраструктурах. OCSP передает минимальный объем данных — только статус одного сертификата.

Приватность

OCSP позволяет удостоверяющему центру видеть, какие сайты посещает клиент, поскольку каждый запрос содержит информацию о проверяемом сертификате. CRL лишен этого недостатка, так как загрузка списка происходит без указания конкретного сертификата.


Поведение в TLS-экосистеме

В современных TLS-реализациях оба механизма могут использоваться совместно:

  • CRL служит базовым офлайн-механизмом
  • OCSP используется для актуальной онлайн-проверки
  • OCSP stapling снижает зависимость клиента от внешних запросов

Выбор механизма зависит от конфигурации сервера и политики удостоверяющего центра.


Использование в JavaScript и jsrsasign

В библиотеке Jsrsasign поддержка проверки статуса сертификатов реализуется на уровне X.509-инфраструктуры. Она позволяет:

  • разбирать CRL-структуры
  • проверять подписи списков отзыва
  • извлекать OCSP URL из расширений сертификата
  • формировать OCSP-запросы (в связке с внешними компонентами)

Типичный сценарий работы включает:

  • загрузку сертификата
  • извлечение поля AIA (Authority Information Access)
  • получение OCSP endpoint
  • формирование и отправку запроса
  • обработку ответа и проверку подписи

При работе с CRL используется иной поток:

  • загрузка CRL файла
  • проверка цифровой подписи CRL
  • поиск серийного номера сертификата
  • интерпретация результата проверки

Архитектурные различия моделей отзыва

OCSP и CRL отражают два разных подхода к управлению доверием:

  • OCSP ориентирован на интерактивную проверку состояния
  • CRL ориентирован на периодическое распространение данных

OCSP ближе к модели «запрос по требованию», тогда как CRL — к модели «локальной репликации состояния».

Эти различия напрямую влияют на поведение TLS-клиентов, балансировку нагрузки в инфраструктуре PKI и скорость принятия решений о доверии к сертификату.