OCSP против CRL: как на самом деле работает каждая проверка отзыва

Одна из этих двух проверок отзыва возвращает подписанный ответ об одном сертификате, а другая — подписанный список, который вы загружаете целиком. Обе должны сообщить проверяющему, можно ли по-прежнему доверять учётным данным, и обе отказывают так, что это совсем не похоже одна на другую. Порядок ниже повторяет то, с чем оператор действительно сталкивается в производстве: от байтов в сети до шлюза, отказывающего в соединении. Пропуск шага — это и есть путь, которым внедрение остаётся с политикой отзыва, существующей только на бумаге.

Шаг 1: Что возвращает каждая проверка и как долго она остаётся пригодной

CRL публикуется как один подписанный объект, охватывающий каждый сертификат, отозванный издателем, поэтому проверяющий получает её один раз и использует повторно, пока не пройдёт nextUpdate списка. Ответ OCSP уже: он отвечает ровно про один сертификат и несёт thisUpdate, producedAt и обычно nextUpdate. Это различие определяет всё остальное. Кэшированная CRL тихо устаревает, потому что файл всё ещё разбирается, а его подпись всё ещё проверяется, тогда как просроченный ответ OCSP очевидно бесполезен в тот момент, когда вы читаете его отметки времени.

Поэтому кэширование — первое, что нужно зафиксировать: какой компонент держит копию и какому потолку эта копия подчиняется. На шлюзе потолком должен быть nextUpdate минус запас безопасности, а не то, что случайно предложит заголовок кэша HTTP. openssl crl -in issuer.crl -noout -lastupdate -nextupdate печатает обе даты, и список, у которого nextUpdate уже в прошлом, нужно считать отсутствующим, а не просто старым.

Шаг 2: Куда сертификат направляет клиента

Конечный сертификат обычно несёт две подсказки: расширение точки распространения CRL и запись доступа к информации удостоверяющего центра для OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints печатает первую, а вторая находится в разделе AIA вывода openssl x509 -in client.pem -noout -text. Любое из расширений — указатель, а не обязательство. Клиент, который никогда не реализует проверку отзыва, прекрасно подключится к сертификату, расширения которого называют ответчик, мёртвый уже год.

Точки распространения часто называют внутренний хост, который разрешается только внутри одного сегмента сети, а некоторые старые клиенты попросту отказываются от URL ldap. Проверяйте доступность с хоста, который завершает туннель, а не со своего ноутбука, потому что это единственная точка зрения, чей сбой действительно важен.

Шаг 3: Выберите fail-closed или fail-open до сбоя

Недоступный ответчик или просроченный список вынуждают решение: отказать в соединении или принять его и зафиксировать пробел. Подкоманда verify в OpenSSL делает строгий выбор явным, потому что добавление -crl_check превращает недоступную CRL в unable to get certificate CRL и неудачную проверку. Мягкий отказ в большинстве стеков вовсе не флаг, а отсутствие проверки, и именно поэтому он попадает в поставку случайно.

Чтобы увидеть, какое поведение у клиента на самом деле, уберите ответчик и подключитесь снова. Если туннель всё равно поднимается, найдите строку журнала, в которой зафиксирована пропущенная проверка, и спросите, станет ли кто-нибудь читать эту строку во время инцидента. Один и тот же поставщик может различаться по протоколу: клиент IKEv2 и клиент OpenVPN на одной машине читают несвязанные параметры конфигурации.

Шаг 4: Докажите, что проверка выполняется там, где принимается трафик

Найдите процесс, который завершает или авторизует соединение, и спросите у него строку конфигурации, включающую проверку отзыва. Шлюз, который проверяет цепочку, но никогда не спрашивает об отзыве, применяет политику, отличную от той, что в вашей документации, и ни один скриншот цепочки сертификатов не доказывает обратное. OpenVPN записывает эту опцию как crl-verify; strongSwan держит поиск CRL и OCSP в конфигурации CA, где задаются crl_uris или ocsp_uris. Если вы не можете указать ни на что из этого, считайте, что проверки нет.

Ответ OCSP действителен только тогда, когда его подписал издавший CA, или когда его подписал ответчик, обладающий расширенным использованием ключа OCSPSigning, делегированным этим CA, поэтому ответ посторонней службы ничего не доказывает. Если вы сами эксплуатируете ответчик, следите за ним как за жёсткой зависимостью, потому что одна мёртвая служба сразу становится сбоем для каждого fail-closed клиента.

Шаг 5: Отзовите один сертификат намеренно

Возьмите тестовый сертификат, отзовите его тем же каналом, который использует производство, и спросите ответчик напрямую. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text должен сообщить Cert Status: revoked вместе со временем отзыва, а ответ good означает, что ваш отзыв не дошёл до ответчика, к которому обращаются ваши клиенты. Затем запустите openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem, чтобы увидеть то же решение через путь списка. Читайте строку причины, а не код выхода, потому что отказ из-за отзыва и ошибка цепочки одинаково заканчиваются неудачей.

Шаг, который действительно важен, — последний: подключитесь заново со старым профилем к реальной точке применения и убедитесь, что отказ исходит от отзыва. Затем подключитесь заново со свежим, действительным сертификатом, чтобы доказать, что вы не просто сломали слушателя. Удаление профиля на клиенте ничего не доказывает о решении сервера, и успешный запуск openssl verify на машине, которая никогда не завершает туннель, тоже. RFC 6960 определяет, что содержит соответствующий ответ OCSP, включая значения статуса, которые читает этот тест.