Главная Networks, Security, Новое Внедрение Инфраструктуры Открытых Ключей на основе Windows Server. Сетевой ответчик, особенности настройки.
  • Внедрение Инфраструктуры Открытых Ключей на основе Windows Server. Сетевой ответчик, особенности настройки.

    Степан Москалев, Леонид Шапиро

     

    В предыдущих статьях нашего цикла [1], [2], [3] мы разобрались установкой нашей двухуровневой иерархии центров сертификации, получив вполне рабочий вариант, который уже можно использовать корпоративной среде с некоторыми оговорками, поскольку речь пока еще не шла об отказоустойчивости и доступности, не все решено с центрами распространения, но об этом речь пойдет позже. Так или иначе, получается масштабируемая среда, которую в дальнейшем можно развивать.

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

    Со временем список отзыва сертификатов будет расти, особенно если мы будем внедрять различные типы сертификатов и количество пользователей системы будет увеличиваться. Сертификаты надо будет отзывать, например, если пользователь покидает компанию, и его сертификат надо аннулировать, или же сертификат скомпрометирован и нуждается в отзыве. Такой сертификат, верней, его серийный номер помещается в список отзыва сертификатов (CRL), который должен быть опубликован и доступен клиентам на Distribution Point – центре распространения. Обычно это WEB сервер и 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 определяет, имеет ли он кешированные ответы для одного и того же запроса. Если да, то он может отправить ответ клиенту.

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

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

     

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

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

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

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

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

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

     

    Приступим к установке OCSP.

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

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

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

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

    1. Перезагрузите службу сертификатов: 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. Нажмите ToolsInternet 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 Certifícate 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

     

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

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

    21. В окне Add Revocation Configuration на вкладе Revocation Provider нажмите Provider….

    22. Убедитесь, что в окне Revocation Provider Properties в области Base CRLs: (область Delta CRLs: пока оставляем без изменений) путь http стоит первым. См. Рисунок 3.

     

    Рисунок 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.

     

    Примечание: Маршруты удобно взять из утилиты 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: Nwtraders.msft.
    4. Убедитесь, что напротив IssuingCA01 стоит статус Working. См. Рисунок 4.

     

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

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

     

    5. Нажмите левой кнопкой мыши на Array Configuration и нажмите на имени WEB сервера. См. Рисунок 5.

     

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

    6. Нажмите левой кнопкой мыши на View Signing Certificate и посмотрите свойства сертификата:

    • Кем выдан.
    • Кому выдан.
    • Срок действия.
    • Какой шаблон использован при выдаче.

     

    См. Рисунок 6,  Рисунок 7

     

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

     

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

    7. Зайдите на сервер издающего удостоверяющего центра с правами администратора сервера «nwtraders\Administrator».

    Запустите из командной строки утилиту pkiview.msc.

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

    9. Посмотрите статус напротив пути OCSP Location#1.

     

     

    Примечание   В статусе может быть ошибка, не стоить беспокоиться по этому поводу, причина в том, что 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/