СТЕПАН МОСКАЛЕВ, инженер ИТ-систем, MCSE, MCSE:S, MCSE:M, MCITP EA, MCITP EMA, HP AIS, msv121@mail.ru

 ЛЕОНИД ШАПИРО, архитектор ИТ-систем, MVP, MCT, MCSE, MCITP:EA, MCSE:S, MCSE:M, shapiro_leonid@yahoo.com

Инфраструктура открытых ключей
в 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].

Как работает Online Certificate Status Protocol

В отличие от списков отзыва сертификатов (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].

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

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

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

• Наличие удаленных клиентов, использующих медленные каналы связи.
• Инфраструктура должна обеспечивать высокую производительность при проверке состояния сертификатов, например массовая аутентификация пользователей в сети, использование шифрованного почтового обмена и т.п.
• Организации необходимы эффективные средства для распространения данных отзыва для сертификатов, выпущенных не Microsoft CA, а сторонним центром сертификации.
• Компания ограничивает возможность просмотра всего списка отзыва сертификатов, предоставляя только требуемую для проверки отдельных запросов статуса сертификата информацию.

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

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

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

Установка Online Certificate Status Protocol

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

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

1. Запустите Server Manager. Нажмите Tools → Certification Authority.
2. Нажмите правой кнопкой мыши на Certificate Templates и выберите Manage.
3. Выберите шаблон OCSP Response Signing и измените свойства Properties.
4. На вкладке Security добавьте учетную запись компьютера, на котором устанавливается OCSP, и дайте ей права Read, Enroll и Auto Enroll.
5. Нажмите OK для принятия изменений в шаблоне OCSP Response Signing.
6. На вкладке General посмотрите продолжительность действия сертификата Validity period: по умолчанию стоит две недели, если OCSP-сервер не будет у вас членом домена, то есть смысл в увеличении данного параметра (выдача будет производиться в ручном режиме).
7. Закройте Certificate Templates.
8. Нажмите правой кнопкой мыши на кнопку Certificate Templates и выберите New → Certificate Template to Issue.
9. Выберите шаблон OCSP Response Signing и нажмите OK.
10. Запустите Windows PowerShell [8].
11. Для добавления путей публикации OCSP в Authority Information Access (AIA) выполните следующую команду:

    Add-CAAuthorityInformationAccess http://pki.nwtraders.msft/ocsp -AddToCertificateOcsp -Force

12. Перезагрузите службу сертификатов:

    Restart-Service CertSvc

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

1. Выполните установку OCSP при помощи PowerShell, для чего запустите Windows PowerShell.
2. Для установки роли выполните следующую команду:

   Install-WindowsFeature ADCS-Online-Cert –IncludeManagementTools

3. Выполните следующую команду:

   Install-ADcsOnlineResponder

4. Нажмите Y.
5. Запустите Server Manager.
6. Нажмите Tools далее Internet Information Services Manager.
7. Нажмите на имени сервера.
8. Нажмите Sites.
9. Нажмите Default Web Site.
10. Убедитесь в наличии сайта OCSP.
11. В Server Manager.
12. Нажмите Tools далее Online Responder Management.
13. Нажмите правой кнопкой мыши на Revocation Configuration и выберите Add Revocation Configuration.
14. В окне Add Revocation Configuration на вкладе Getting Started With Adding A Revocation Configuration нажмите Next.
15. В окне Add Revocation Configuration на вкладе Name The Revocation Configuration введите имя конфигурации (оно может быть любое) IssuingCA01 и нажмите Next.
16. В окне Add Revocation Configuration на вкладе Select CA Certificate Location выберите Select a certificate for an Existing enterprise CA и нажмите Next.
17. В окне Add Revocation Configuration на вкладе Choose CA Certificate выберите Browse CA certificates published in Active Directory и нажмите Browse.
18. В окне Select Certification Authority выберите сертификат издающего центра и нажмите кнопку OK.
19. Нажмите Next.
20. В окне Add Revocation Configuration на вкладе Select Signing Certificate выберите Automatically select a signing certificate, установите флаг Auto-Enroll for an OCSP signing certificate и нажмите Next (см. рис. 2).

    

     

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

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

21. В окне Add Revocation Configuration на вкладе Revocation Provider нажмите Provider…
22. Убедитесь, что в окне Revocation Provider Properties в области Base CRLs: (область Delta CRLs: пока оставляем без изменений) путь http стоит первым (см. рис. 3).
23. В окне Revocation Provider Properties в области Delta CRLs: нажмите кнопку ADD… и введите маршрут http://pki.nwtraders.msft/PKI/IssuingCA01+.crl, нажмите кнопку OK.
24. В окне Revocation Provider Properties в области Delta CRLs: нажмите кнопку ADD… и введите маршрут: ///CN=IssuingCA01,CN=ICA01,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=Nwtraders,DC=msft?deltaRevocationList?base?objectClass=cRLDistributionPoint, нажмите кнопку OK.

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

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

25. Нажмите кнопку OK.
26. В окне Add Revocation Configuration на вкладе Revocation Provider нажмите Finish.

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

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

1. В Server Manager.
2. Нажмите Tools → Online Responder Management.
3. Нажмите левой кнопкой мыши на Online Responder: WEBSRV1.Nwtraders.msft.
4. Убедитесь, что напротив IssuingCA01 стоит статус Working (см. рис. 4).

   

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

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

5. Нажмите левой кнопкой мыши на Array Configuration и нажмите на имени веб-сервера (см. рис. 5).
6. Нажмите левой кнопкой мыши на View Signing Certificate и посмотрите свойства сертификата (cм. рис. 6, 7.):
   • Кем выдан.
   • Кому выдан.
   • Срок действия.
   • Какой шаблон использован при выдаче.
7. Зайдите на сервер издающего удостоверяющего центра с правами администратора сервера

   nwtraders/Administrator

8. Запустите из командной строки утилиту pkiview.msc.
9. Уберитесь в наличии пути OCSP Location#1 в настройках издающего центра сертификатов.
10. Посмотрите статус напротив пути OCSP Location#1.

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

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

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

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

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

1. Шапиро Л. Внедрение инфраструктуры открытых ключей на основе Windows Server 2016. Часть 1. Предварительный этап. / «Системный администратор», № 1-2, 2018 г. – С. 23-27. URL: http://samag.ru/archive/article/3576.
2. Москалев С., Шапиро Л. Инфраструктура открытых ключей в Windows Server 2016. Часть 2. RootCA. / «Системный администратор», № 3, 2018 г. – С. 16-19. URL: http://samag.ru/archive/article/3605.
3. Москалев С., Шапиро Л. Инфраструктура открытых ключей в Windows Server 2016. Часть 3. Установка и настройка издающего центра сертификации (Issuing CA)./ «Системный администратор», № 7-8, 2018 г. – С. 26-28. URL: http://samag.ru/archive/more/184.
4. PKI Design Considerations: Certificate Revocation and CRL Publishing Strategies – https://blogs.technet.microsoft.com/xdot509/2012/11/26/pki-design-considerations-certificate-revocation-and-crl-publishing-strategies/.
5. Online Certificate Status Protocol – https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol.
6. Certification Authority Guidance – https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831574(v=ws.11).
7. PKI Design Considerations: Certificate Revocation and CRL Publishing Strategies – https://blogs.technet.microsoft.com/xdot509/2012/11/26/pki-design-considerations-certificate-revocation-and-crl-publishing-strategies/.
8. PowerShell Documentation – https://docs.microsoft.com/en-us/powershell/.

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

Комментарии могут оставлять только зарегистрированные пользователи