Инфраструктура открытых ключей в Windows Server 2016. Часть 4. Сетевой ответчик

В предыдущих статьях цикла [1-3] мы разобрались с установкой нашей двухуровневой иерархии центров сертификации. Теперь рассмотрим «сетевой ответчик» или online responder Online Certificate Status Protocol (OCSP) [5]. Эта функциональность есть в составе центра сертификации Microsoft [6]

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

Вполне очевиден один «тонкий» момент, а именно сам CRL может стать узким местом. Ведь информация об этом списке должна быть у всех клиентов.

Со временем список отзыва сертификатов будет расти, особенно если мы станем внедрять различные типы сертификатов и количество пользователей системы будет увеличиваться. Сертификаты надо будет отзывать, например, если пользователь покидает компанию и его сертификат надо аннулировать или же сертификат скомпрометирован и нуждается в отзыве. Такой сертификат, вернее, его серийный номер, помещается в список отзыва сертификатов (CRL), который должен быть опубликован и доступен клиентам на Distribution Point – центре распространения. Обычно это веб-сервер и LDAP-каталог.

Кроме основного или базового списка отзыва, может быть также использован и разностный или Delta CRL. Он содержит аннулированные сертификаты, которые были отозваны после публикации предыдущего базового списка. Использование Delta CRL позволяет сократить объем передаваемых клиенту данных [4].

Дело в том, что CRL кэшируется на клиенте, чтобы не загружать избыточно канал связи, и его не надо загружать при каждой проверке сертификата. Соответственно, имея кэшированным базовый CRL, нам будет достаточно получить только разностный список отзыва. Когда же будет опубликован новый базовый CRL, то его придется снова скачивать.

Теперь давайте вспомним, что делается для проверки того, не отозван ли сертификат. Проверяется поле сертификата CRL Distribution Point (CDP), которое и содержит информацию о месте расположения списка отзыва сертификатов, за которым нам и предстоит обратиться.

Вот тут и возникает сложность: список может быть большим, да и клиентов, которым он нужен, может быть существенное количество. Итак, клиентов может быть много, а стало быть, это создает нагрузку на сеть. В итоге она может быть весьма серьезной.

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

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

В сущности, мы используем файл-серверную технологию, и возникает вопрос: как бы тут перейти к клиент-серверной, можно ли проверить статус сертификата, не загружая весь CRL каждый раз при проверке?

Оказывается, такое решение уже давно есть и называется «сетевой ответчик» или online responder Online Certificate Status Protocol (OCSP) [5]. Эта функциональность есть в составе центра сертификации Microsoft [6].

В отличие от списков отзыва сертификатов (CRL), которые распространяются периодически и содержат сведения обо всех отозванных и приостановленных сертификатах, сетевой ответчик обрабатывает только отдельные запросы от клиентов о состоянии сертификата. Объем получаемых данных на один запрос остается постоянным вне зависимости от возможного количества отозванных сертификатов. Это позволяет снизить накладные расходы при проверках сертификатов. Однако ссылка на OCSP Online Responder должна быть включена в проверяемый сертификат. Дополнительно можно указать OCSP Online Responder через групповые политики [7].

Суть работы OCSP простая (см. рис. 1). Клиент для проверки статуса сертификата отправляет запрос на OCSP Responder с указанием серийного номера проверяемого сертификата. Online Responder на своей стороне проверяет статус сертификата и возвращает этот статус клиенту. Сначала ответчик OCSP определяет, имеет ли он кэшированные ответы для одного и того же запроса. Если да, то он может отправить ответ клиенту.

Рисунок 1. Алгоритм работы OCSP

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

Использовать протокол OCSP умеют только клиенты под управлением Windows Vista и выше. Предыдущие ОС могут его поддерживать только за счет сторонних компонентов [8].

Очевидно, использование этой технологии целесообразно, особенно в больших компаниях.

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

У нас есть следующие очевидные основания, чтобы его внедрить:

Для установки роли сетевого ответчика необходимо выбрать сервер. Роль сетевого ответчика может быть установлена как на сервер центра сертификации, так и на отдельный сервер.

Сервер продолжает быть доступен как пользователям из внутренней сети компании, так и внешним, то есть подключающимся через интернет. В этой ситуации нам будет значительно удобнее использовать в этом качестве веб-сервер.

При желании и наличии дополнительных ресурсов можно разместить роль сетевого ответчика и веб-сервер публикации списков отозванных сертификатов на разных серверах.

Приступим к установке OCSP. Начнем с настройки на стороне издающего сервера сертификатов.

Заходим на сервер учетной записью пользователя, обладающей правами Enterprise Admin, и переходим к установке.

Теперь можно приступать к установке Online Responder на веб-сервере.

Рисунок 2. Выбор сертификата

Примечание: IssuingCA01 – в данном случае имя используемого издающего центра сертификации

Рисунок 3. Пути к спискам отзыва

Примечание: маршруты удобно взять из утилиты pkiview.msc, запустив ее на издающем центре сертификатов. pki.netraders.msft – путь, используемый в тестовом примере.

Установка OCSP завершена.

Проверка работы Online Responder.

Рисунок 4. Проверка работоспособности

Примечание: websrv1.nwtraders.msft – используемый в примере сервер веб.

Рисунок 5. Просмотр свойств сертификата

Рисунок 6. Свойства сертификата. Вкладка General

Рисунок 7. Свойства сертификата. Вкладка Details

Примечание: в статусе может быть ошибка, не стоит беспокоиться по этому поводу, причина в том, что OSCP еще ни разу не использовался, далее, запросив и установив сертификат, проверим его, и все будет работать штатно.

Продолжение следует…

Ключевые слова: центр сертификации, служба сертификации, сетевой ответчик.