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

Для прохождения проверки должны выполняться следующие условия.

  • Подпись каждого сертификата действительна.

  • Текущие значения даты и времени находятся в пределах периода действия каждого сертификата.

  • Отсутствуют поврежденные и неверно сформированные сертификаты.

Кроме того, каждый сертификат в цепочке проверяет свое состояние отзыва. Проверка отзыва может быть выполнена с помощью списка отзыва сертификатов (CRL) или ответа OCSP (Online Certificate Status Protocol).

Что такое OCSP?

Сетевой ответчик корпорации (Майкрософт) использует протокол OCSP, позволяющий получателю сертификата отправить запрос состояния сертификата ответчику OCSP, используя протокол HTTP. Ответчик OCSP возвращает определенный ответ с цифровой подписью, показывающий состояние сертификата. Каждый запрос возвращает постоянный объем данных независимо от числа отозванных сертификатов в ЦС.

Дополнительные сведения см. в документе RFC 2560, «X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP» (https://go.microsoft.com/fwlink/?LinkID=71068).

Сетевой ответчик

Реализация протокола OCSP (Майкрософт), сетевой ответчик, разделена на клиентский и серверный компоненты. Клиентский компонент встроен в библиотеку CryptoAPI 2.0, а серверный компонент представлен в качестве новой службы роли в составе роли сервера «Службы сертификации Active Directory» (AD CS). Следующий процесс описывает взаимодействие клиентского и серверного компонентов.

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

  2. Если допустимые кэшированные ответы не найдены, выполняется отправка запроса сетевому ответчику с использованием протокола HTTP.

  3. Веб-прокси сетевого ответчика расшифровывает и проверяет запрос. Если запрос действителен, в кэше веб-прокси выполняется поиск сведений отзыва, необходимых для удовлетворения данного запроса. Если текущие сведения в кэше недоступны, запрос передается службе «Сетевой ответчик».

  4. Служба «Сетевой ответчик» принимает запрос и проверяет локальный список отзыва сертификатов (CRL), если он доступен, а также кэшированную копию последнего CRL, выданного центром сертификации.

  5. Если нужный сертификат не указан ни в локальном, ни в кэшированном списках отзыва, то для проверки состояния сертификата поставщик отзыва получает обновленный CRL центра сертификации (если он доступен) из расположений, указанных в конфигурации отзыва. Затем поставщик возвращает состояние сертификата службе «Сетевой ответчик».

  6. Веб-прокси зашифровывает ответ и отправляет клиенту, чтобы уведомить его о действительности сертификата. Кроме того, копия ответа некоторое время хранится в кэше веб-прокси на случай дополнительных запросов о состоянии данного сертификата.


Содержание