Кратко

  • При OCSP stapling сервер передаёт подписанные данные о статусе сертификата прямо в TLS-рукопожатии, поэтому клиенту не нужно отдельно обращаться к OCSP-респондеру.
  • Состояние good намеренно имеет узкий смысл, а thisUpdate, nextUpdate и producedAt задают временные границы утверждения.
  • Верная подпись и приемлемое окно не показывают, когда каждый пограничный узел получил ответ и установлены ли более поздние сведения об отзыве по всей инфраструктуре.
  • Нужна проверяемая запись об актуальности отзыва: она связывает сертификат и OCSP-респондер со временем статуса, загрузкой, группой развёртывания и моментом решения.

Представим гипотетическую ситуацию, не относя её к конкретному провайдеру или реальному инциденту. Удостоверяющий центр создаёт подписанный ответ OCSP со статусом good, и один узел сохраняет его в кеше. Позже сертификат отзывают. Второй узел получает новый ответ, а первый продолжает предъявлять прежний в пределах его временного окна. Клиент может корректно проверить старый объект, но не получает тем самым доказательства эксплуатационного утверждения: «отзыв действует везде».

Граница заложена в протоколе. RFC 6960 определяет OCSP как способ узнать статус сертификата без загрузки полного списка отозванных сертификатов. Окончательный ответ подписан, идентифицирует OCSP-респондер и содержит статус конкретного сертификата. Это сильное свидетельство, но всё же утверждение об определённом объекте, контексте выдачи и периоде.

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

Три отметки времени показывают границу доказательства. thisUpdate — последний момент, когда OCSP-респондер считал указанный статус правильным. nextUpdate — срок появления более новых сведений. producedAt — время подписания ответа. Эти значения не равнозначны. Недавно подписанный ответ может описывать более раннее знание, а будущий nextUpdate не доказывает, что последующее событие уже дошло до каждого кеша и узла.

Перед принятием ответа доверяющая сторона должна сопоставить его с запрошенным сертификатом, проверить подпись и полномочия OCSP-респондера, признать thisUpdate достаточно свежим и при наличии nextUpdate убедиться, что он позже текущего времени. Проверки устанавливают подлинность и приемлемость по локальной политике. Они не фиксируют путь доставки объекта до предъявляющего сервера.

RFC 6066 описывает расширение TLS status_request. Сервер может отправить ответ OCSP вместе с сертификатом; клиенту не требуется отдельное соединение с OCSP-респондером. Полученный ответ необходимо проверить и прервать рукопожатие, если он неудовлетворителен. Передача ответа сервером упрощает доставку свидетельства, но не расширяет его смысл.

В распределённом сервисе один сертификат может использоваться во множестве регионов и групп TLS-завершения. Каждая группа способна получать, кешировать и заменять ответы в рамках собственного процесса эксплуатации. Объект OCSP содержит сведения и временные метки OCSP-респондера, но не полный список узлов, версию конфигурации, результат последней загрузки или подтверждение замены. «Ответ проходит проверку» и «новейшие данные об отзыве применяются повсюду» — разные утверждения.

RFC 7633 добавляет контроль: сертификат может требовать функцию TLS, например status_request. Совместимый клиент вправе отвергнуть конфигурацию без ожидаемого статуса. Однако в предусмотренных спецификацией случаях проверка может опираться на другой источник. Must-Staple делает отсутствие свидетельства значимым, но не обновляет старый ответ, не предотвращает любую ошибочную выдачу и не доказывает, кто сейчас управляет приложением за сертификатом.

Ошибка в эксплуатации — свести четыре состояния к одному зелёному индикатору. Цепочка сертификатов, подпись OCSP и временная проверка могут пройти, хотя узел отстаёт от новейшего статуса или не входит в якобы обновлённую группу. Запись «ответ OCSP приложен» не различает эти случаи.

Проверяемая запись об актуальности отзыва должна сохранять всю цепочку: серийный номер и полную цепочку сертификатов, идентификатор OCSP-респондера, статус, thisUpdate, nextUpdate, producedAt, время загрузки, группу узлов, установившую ответ, политику проверки и момент решения. Следует фиксировать и сбои замены, отделяя транспортную аутентификацию от текущей авторизации приложения.

Это не делает stapling слабым. Он уменьшает утечку приватности, задержку и зависимость от внешнего запроса во время рукопожатия. Must-Staple позволяет считать отсутствие свидетельства ошибкой. Подпись и время удостоверяют ограниченное утверждение. Проблема начинается, когда преимущества превращают в гарантию, которой объект не содержит.

Решение состоит не в абстрактном доверии или недоверии OCSP, а в выборе допустимого утверждения. Для рукопожатия подлинный и достаточно свежий ответ может быть решающим. Чтобы доказать доставку данных об отзыве на все активные узлы, нужны данные развёртывания. Для действия приложения требуется собственное актуальное решение об идентичности и политике.

Источники

RFC 6960 — Online Certificate Status Protocol; RFC 6066 — расширения TLS; RFC 7633 — TLS Feature Extension.