Служба сертификации active directory. Windows Server. Создание автономного центра сертификации. Проверка работы ЦС

Установка самоподписанных сертификатов весьма частая задача для системного администратора. Обычно это делается вручную, но если машин не один десяток? И как быть при переустановке системы или покупке нового ПК, ведь сертификат может быть и не один. Писать шпаргалки-напоминалки? Зачем, когда есть гораздо более простой и удобный способ - групповые политики ActiveDirectory. Один раз настроив политику можно больше не беспокоится о наличии у пользователей необходимых сертификатов.

Сегодня мы рассмотрим распространение сертификатов на примере корневого сертификата Zimbra, который мы экспортировали в . Наша задача будет стоять следующим образом - автоматически распространять сертификат на все компьютеры входящие в подразделение (OU) - Office . Это позволит не устанавливать сертификат туда, где он не нужен: на севера, складские и кассовые рабочие станции и т.д.

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

После чего перетащите политику на контейнер Office , что позволит применить ее к данному подразделению.

Теперь щелкнем на политику правой кнопкой мыши и выберем Изменить . В открывшемся редакторе групповых политик последовательно разворачиваем Конфигурация компьютера - Конфигурация Windows - Параметры безопасности - Политики открытого ключа - . В правой части окна в меню правой кнопкой мыши выбираем Импорт и импортируем сертификат.

Политика создана, теперь самое время проверить правильность ее применения. В оснастке Управление групповой политикой выберем Моделирование групповой политики и запустим по правому щелчку Мастер моделирования .

Большинство параметров можно оставить по умолчанию, единственное что следует задать - это пользователя и компьютер для которых вы хотите проверить политику.

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

После чего проверим работу политики на клиентском ПК, для этого обновим политики вручную командой:

Gpupdate

Теперь откроем хранилище сертификатов. Проще всего это сделать через Internet Explorer : Свойства обозревателя - Содержание - Сертификаты . Наш сертификат должен присутствовать в контейнере Доверенные корневые центры сертификации .

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

Служба сертификации Active Directory (AD CS) является очень удобным и полезным инструментом в доменной сети. Данный компонент входит в состав Windows Server 2012 R2, позволяет бесплатно выдавать ssl-сертификаты внутри вашего домена и управлять ими. Такие сертификаты могут понадобиться при работе с почтовым сервером Microsoft Exchange, сеансами удаленных рабочих столов и т. д.

Службу AD CS не рекомендуется устанавливать на контроллер домена. В данной статье в качестве примера будут использоваться 3 сервера под управлением операционной системы Windows Server 2012 R2: DC-01 (контроллер домена), FS-01 (сервер, на который будет установлена служба AD CS) и TS-00 (сервер, для которого мы будем получать ssl-сертификат).

1. Заходим в Диспетчер серверов на сервере FS-01:

Выбираем пункт «Управление» и далее «Добавить роли и компоненты».

2. Откроется Мастер добавления ролей и компонентов. На вкладке «Тип установки» выбираем пункт «Установка ролей и компонентов»:

Нажимаем «Далее».

3. На вкладке «Выбор сервера» отмечаем пункт «Выберите сервер из пула серверов» и в области «Пул серверов» выбираем конечный сервер для установки Active Directory Certificate Services:

В моем случае это локальный сервер FS-01 с ip-адресом 192.168.1.22. Нажимаем «Далее».

4. На вкладке «Роли сервера» выбираем роль «Службы сертификатов Active Directory»:

В новом окне предстоит добавить компоненты, необходимые для Службы сертификатов Active Directory:

Ставим галочку напротив пункта «Включить средства управления (если применимо)» и нажимаем кнопку «Добавить компоненты». После этого вновь откроется Мастер добавления ролей и компонентов на вкладке «Роли сервера», где необходимо нажать кнопку «Далее».

5. На вкладке «Компоненты» оставляем все настройки по умолчанию и нажимаем «Далее»:

6. Информационная вкладка Службы сертификации Active Directory:

На данной вкладке представлены краткие сведения о Службах сертификации Active Directory. В частности сообщается о том, что нельзя менять имя и параметры домена компьютера, на котором установлена AD CS. После прочтения информации нажимаем «Далее».

7. На вкладке «Службы ролей» выбираем службу «Центр сертификации»:

Нажимаем «Далее».

8. На вкладке «Подтверждение» можно ознакомиться со списком всех служб ролей и компонентов, которые будут установлены на данном сервере:

Для изменения настроек воспользуйтесь кнопкой «Назад». Если все правильно, нажимаем кнопку «Установить». Перед установкой рекомендую активировать пункт «Автоматический перезапуск конечного сервера, если потребуется», чтобы при необходимости сервер смог автоматически перезагрузиться в процессе установки службы сертификации AD CS.

9. Начнется установка службы сертификации AD CS и других служб ролей и компонентов:



Дождитесь завершения установки. Данное окно можно закрыть.

10. Когда установка AD CS завершится, перейдите в Диспетчер серверов, нажмите на «флажок» с восклицательным знаком в желтом треугольнике и выберите пункт «Настроить службы сертификатов Active Directory»:

11. Откроется окно «Конфигурация службы сертификатов Active Directory». На вкладке «Учетные данные» укажите учетные данные пользователя для настройки служб роли:

Обратите внимание, что для установки служб ролей «Автономный центр сертификации», «Служба регистрации в центре сертификации через Интернет» и «Сетевой ответчик» пользователь должен быть членом локальный группы «Администраторы». Для установки служб ролей «Центр сертификации предприятия», «Веб-служба политик регистрации сертификатов», «Веб-служба регистрации сертификатов» и «Служба регистрации на сетевых устройствах» пользователь должен быть членом доменной группы «Администраторы предприятия». Выберите пользователя при помощи кнопки «Изменить» и нажмите «Далее».

12. Выбор службы роли для настройки (Центр сертификации):

На вкладке «Службы ролей» выбираем «Центр сертификации» и нажимаем «Далее». Обратите внимание, что необходимо сначала настроить службу роли «Центр сертификации», а затем другие службы, т. е. одновременный выбор нескольких служб на данной вкладке не поддерживается.

13. Вариант установки Центра сертификации:

На вкладке «Вариант установки» выберите пункт «ЦС предприятия» и нажмите «Далее».

14. Тип Центра сертификации:

На вкладке «Тип ЦС» выбираем пункт «Корневой ЦС» и нажимаем «Далее».

15. Тип закрытого ключа:

На вкладке «Закрытый ключ» выбираем пункт «Создать новый закрытый ключ» и нажимаем «Далее».

16. Параметры шифрования:

На вкладке «Шифрование» предлагаю параметры «Поставщик служб шифрования» (RSA#Microsoft Software Key Storage Provider) и «Длина ключа» (2048) оставить по умолчанию, а значение «Хэш-алгоритма для подписывания сертификатов, выдаваемых этим ЦС» указать «SHA256». Нажимаем «Далее».

17. Имя Центра сертификации:

На вкладке «Имя ЦС» можно указать общее имя для этого центра сертификации, суффикс различающегося имени и предпросмотр различающегося имени. В моем случае все значения остаются по умолчанию. Нажимаем «Далее».

18. Срок действия сертификата:

На вкладке «Срок действия» необходимо указать период действия сертификата для данного Центра сертификации. Обратите внимание, что срок действия сертификата для Центра сертификации должен превышать срок действия сертификатов, которые он будет выдавать. Нажимаем «Далее».

19. Расположение базы данных сертификатов:

На вкладке «База данных сертификатов» укажите расположение базы данных сертификатов и журнала базы данных сертификатов. В моем случае значения остаются по умолчанию. Нажимаем «Далее».

20 Подтверждение установки Центра сертификации:

На данной вкладке можно ознакомиться со всеми выбранными настройками и при необходимости их изменить, воспользовавшись кнопкой «Назад». Если все правильно, нажимаем «Настроить».

21. Настройка Центра сертификации выполнена успешно:

Если процесс завершился без ошибок, нажимаем кнопку «Закрыть».

22. Переходим в Диспетчер серверов:

Установка Службы сертификации Active Directory (AD CS) выполнена успешно.

Как известно, сертификаты нужны для надежной аутентификации, создания SSL-соединений, отправки S/MIME-сообщений и других действий, направленных на обеспечение безопасности. С каждым годом использование сертификатов растет, и для того, чтобы удовлетворять новым требованиям, Microsoft довольно серьезно переработала старую службу Certificate Services.

В Windows Server 2008 службы сертификации теперь относятся к службам Active Directory. Мы можем установить роль Active Directory Certificate Services (AD CS) и на сервер, не входящий в домен, но часть функций при этом будет недоступна. Например, для управления шаблонами требуется контроллер домена, так как шаблоны хранятся на нем. В состав роли AD CS в Windows Server 2008 R2 входит шесть компонентов:

1. Certification authorities (CAs) – этот компонент позволяет установить и настроить корневой (root) или подчиненный (subordinate) центры сертификации (они же «удостоверяющие центры»), которые служат для выдачи сертификатов пользователям, компьютерам и службам.
2. Web enrollment необходим для запроса сертификатов и получения информации об отозванных сертификатах через веб-браузер.
3. Online Responder позволяет клиентам получать информацию о статусе одного сертификата без получения списков отзыва.
4. Network Device Enrollment Service (NDES) используется маршрутизаторами и другими сетевыми устройствами без учетных записей в домене для получения сертификатов. Служба подачи заявок на сетевые устройства использует протокол SCEP (Simple Certificate Enrollment Protocol), который был разработан Cisco. Расширение NDES для IIS конфигурируется через ключи реестра HKEY_LOCAL_ROOT\Software\Microsoft\Cryptography\MSCEP.
5. Certificate Enrollment Web Service позволяет клиентам автоматически подавать заявки на сертификаты и получать их по HTTPS.
6. Certificate Enrollment Policy Web Service позволяет определить политики для автоматической регистрации сертификатов и передавать их клиентам по HTTPS. В то время, как Web Service получает информацию о политиках из AD по протоколу LDAP.

В предыдущих версиях Windows Server в состав Certificate Services входили только первые два компонента, которые назывались Certificate Services CA и Certificate Services Web Enrollment Support, а последние два компонента появились только в Windows Server 2008 R2.

Варианты установки и управления AD CS

AD CS нельзя установить на Itanium редакции Windows Server 2008, а на Server Core все компоненты AD CS можно устанавливать, начиная с Windows Server 2008 R2. Довольно серьезные ограничения по использованию AD CS присутствуют и в стандартной редакции Server 2008 (возможность установки только компонента CA, невозможность использовать Restricted Enrollment Agent и другие новшества), часть из которых были сняты в R2 (наконец в стандартной редакции появилась возможность работать с шаблонами сертификатов версий выше первой).

Все компоненты можно поставить на один сервер, но рекомендуется разносить CA, Online Responder и Web enrollment на различные сервера. Для полноценной работы AD CS требуется AD DS (Active Directory Domain Services). При этом можно обойтись без обновления схемы – AD CS в Server 2008 и в Server 2008 R2 будет работать и на схеме, которая поставляется с Windows Server 2003. Но для работы Certificate Enrollment Web Services уже необходима схема не ниже 47 версии, которая идет с Windows Server 2008 R2. Для работы большинства компонентов также требуется IIS.

Установка AD CS производится через добавление ролей в оснастке Server Manager. Как и раньше, для настройки параметров установки применяется конфигурационный файл CAPolicy.inf, который должен находиться в %SYSTEMROOT%. Если необходимо установить на сервер два компонента Certification Authority и Certificate Enrollment Web Service, то это надо делать в два этапа, так как при установке CA нельзя выбрать для установки компонент Web Service.

В Windows Server 2008 были добавлены новые COM-объекты (подробную информацию о свойствах ICertSrvSetup можно найти на MSDN), которые можно использовать для установки CA. Например, можно автоматизировать установку и настройку с помощью VBScript.

Службы сертификации являются хорошими кандидатами на виртуализацию. Но при этом очень важно обеспечить необходимый уровень безопасности для закрытых ключей. Этого можно достичь, используя аппаратные криптографические модули (HSM). В этом случае, даже если виртуалка целиком попадет к злоумышленнику (например, из резервной копии), то закрытые ключи не будут потеряны и не придется перестраивать всю инфраструктуру, так как ключи останутся в HSM. Microsoft официально поддерживает виртуализацию служб сертификации начиная с Windows Server 2003 SP1.

Для управления и настройки AD CS можно использовать MMC-оснастки, скрипты или командную строку. Большая часть инструментов существовала и в предыдущих версиях, таких как оснастки Certificates (certmgr.msc), Certification Authority (certsrv.msc) и Certificate Templates (certtmpl.msc), утилиты certutil.exe и сertreq.exe. Добавилась оснастка Online Responder Management (ocsp.msc) для управления одноименным компонентом. Кроме того, в состав ОС вошла оснастка Enterprise PKI (pkiview.msc), которая ранее была частью Windows Server 2003 Resource Kit и называлась PKI Health Tool.

Enterprise PKI позволяет одновременно отслеживать состояние и доступность нескольких CA, проверяет статус сертификатов CA, доступность AIA (Authority Information Access) и списков отзыва. С помощью разноцветных отметок можно судить о доступности и состоянии PKI. Pkiview удобно использовать, когда в организации развернуто несколько CA, и информацию о них можно получить из нескольких источников, работающих по различным протоколам.

Некоторые изменения произошли и в резервном копировании AD CS в Server 2008 R2. Так как закрытые ключи теперь хранятся в скрытой папке %SYSTEMDRIVE%\ProgramData\Microsoft\Crypto\Keys, к которой можно получить доступ через %SYSTEMDRIVE%\Users\All Users\Microsoft\Crypto\Keys, то они не попадают в резервную копию состояния системы. Чтобы можно было восстановить или мигрировать CA при создании использование в качестве резервной копии System State Backup, надо еще создать резервную копию закрытых ключей. Для этого можно воспользоваться командой certutil –backupKey <путь_для_резервной_копии> или оснасткой Certification Authority.

Шаблоны сертификатов

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

В Windows Server 2000 присутствовали только шаблоны первой версии, которые нельзя изменять – иначе говоря, можно использовать только те шаблоны, которые идут в составе ОС и задавать для них только разрешения на выдачу сертификатов. Шаблоны второй версии поддерживают восстановление и архивацию ключей, и автоматическую выдачу сертификатов (certificate autoenrollment) и были представлены в Windows Server 2003.

В Windows Server 2008 появились шаблоны версии 3, главная новая возможность которых – работа с CNG (Cryptography Next Generation). CNG – это замена CryptoAPI, в которой реализована поддержка алгоритмов из CryptoAPI 1.0 и поддержка ранее неподдерживаемых криптографических алгоритмов, среди которых алгоритмы ЭЦП и обмена ключами на основе эллиптических кривых, а также дополнительные алгоритмы хеширования. Стоит отметить, что использование сертификатов на основе NSA Suite B Cryptography (к которым относятся алгоритмы на основе эллиптических кривых) поддерживается только ОС, начиная с Windows Vista. То есть нельзя, например, использовать сертификат с ключом для алгоритма, использующего эллиптические кривые, в Windows XP и Windows Server 2003, хотя можно использовать классические алгоритмы, такие как RSA, даже если ключ был сгенерирован с использованием CNG. Использование шаблонов третьей версии для работы со смарт-картами также затруднено, так как CSP (Cryptography Service Provider) для смарт-карт не поддерживают новые алгоритмы CNG.

Вторая и третья версии шаблонов поддерживаются в редакциях Enterprise и Datacenter. В редакции Standard новые версии шаблонов поддерживаются только в Server 2008 R2. Сертификаты по шаблонам третьей версии можно издавать и на CA на Windows Server 2003.

В Windows Server 2008 R2 и Windows 7 был добавлен интерфейс программирования (Certificate Template API), который позволяет при установке приложения добавлять новые шаблоны сертификатов. Данная возможность может очень пригодиться, например, в такой ситуации: разработчики пишут приложение, которое использует сертификаты с нестандартными расширениями. Раньше надо были писать подробные инструкции для администраторов, чтобы они создали в своей системе необходимый шаблон. Теперь можно добавить новый шаблон программно с помощью импорта предварительно экспортированного шаблона, созданного в тестовой среде. Шаблон необходимо создавать через стандартную оснастку certtmpl.msc, чтобы быть уверенным, что он не нарушает огромное количество ограничений, которые накладываются на сертификаты (например, разрешение архивирования ключей только для сертификатов, которые используются для шифрования).

Новые способы запроса сертификатов

Кстати, а каким образом пользователи и компьютеры получают сертификаты? Иначе говоря, как они могут подавать запрос на сертификат и устанавливать его на компьютер? Можно, конечно, руками создать PKCS#10 запрос и с помощью командной строки и certreq передать запрос на CA, но не всегда есть возможность объяснить пользователям, как это сделать. Если пользователь доменный и подключен к корпоративной сети, то можно с помощью групповых политик настроить автоматическую подачу и обработку заявок. В результате пользователь может даже не подозревать, что ему был установлен новый сертификат или обновлен старый.

Клиенты, которые не входят в домен или не имеют прямого доступа в сеть с CA, могут запросить сертификат через веб-интерфейс. Компонент Web Enrollment, который необходим для этого, присутствовал и ранее, но был существенно переработан. Старая библиотека XEnroll.dll, которая была написана много лет назад и долго дополнялась новыми функциями и багами, была заменена на новую – CertEnroll.dll, так как оказалось легче написать с нуля, чем исправить то, что было. Web Enrollment позволяет подавать заявки в формате PKCS #10 или создавать запросы интерактивно через браузер, автоматическая подача заявок не поддерживается.

В Windows Server 2008 и более ранних версиях для аутентификации пользователей и компьютеров при запросе сертификатов использовался протокол Kerberos, а в качестве транспортного протокола – Distributed COM (DCOM). При таком способе аутентификации автоматическая подача заявок (autoenrollment) недоступна для компьютеров, которые не подсоединены к корпоративной сети, или для компьютеров, которые находятся в другом лесе, чем центр сертификации. CA Web Enrollment, появившийся в Server 2008 R2, использует для подачи заявок новый протокол WS-Trust. Новые сервисы – Certificate Enrollment Policy Web Service и Certificate Enrollment Web Service – позволяют получить политики и подать заявки на сертификаты через HTTPS. При этом в качестве аутентификации можно использовать не только Kerberos, но и пароли, и сертификаты.

Если необходимо избежать запросов к CA на новые сертификаты из интернета, но есть клиенты, которым надо обновлять сертификаты, когда они, например, в командировках, то можно использовать режим только обновления (renewal-only). В этом случае клиенты при первом получении сертификата должны быть в той же сети, что и CA, а в случае обновления сертификатов могут воспользоваться возможностями CA Web Enrollment.

Политики для этих служб настраиваются через групповые политики или на клиенте, через оснастку Certificates.

Списки отзыва vs. Online Responder

При проверке валидности сертификата среди прочего проверяется срок его действия и состояние отзыва. Сертификат может быть отозван, как в случае компрометации ключа, так и при изменении информации о владельце, например, смене должности или фамилии. Традиционно информация об отозванных сертификатах помещается в списки отзыва (CRL (certificate revocation list)). Чтобы узнать, был ли отозван сертификат, надо получить список отзыва и проверить наличие в нем рассматриваемого сертификата. Если в организации большое количество сертификатов, то список будет быстро расти, а клиенты при проверке статуса сертификата будут ждать закачки списка. Кроме обычных списков существуют еще и разностные (Delta CRL), которые содержат в себе только информацию о сертификатах, статус которых был изменен по сравнению с предыдущим списком отзыва. Delta CRL частично решают проблемы с объемом списков отзыва, но не решают всех проблем, связанных с актуальностью информации. Так как списки публикуются с заданным интервалом, то может быть такая ситуация, что сертификат уже отозван, а информации об этом в CRL еще нет.

В Windows Server 2008 появились сетевые ответчики (Online Responder). Их можно использовать как альтернативу или в дополнение к спискам отзыва сертификатов. Компонент Online Responder использует протокол OCSP (Online Certificate Status Protocol), описанный в RFC 2560. Ответчик разбирает запросы от клиентов, оценивает статус сертификата и отправляет обратно подписанный ответ с информацией о статусе запрошенного сертификата. В случае если клиенту требуется информация о статусе большого количества сертификатов, то целесообразно использовать списки отзыва, так как их достаточно получить один раз, без необходимости многократных запросов к серверу.

Протокол OCSP поддерживают клиенты, начиная с Windows Vista. Они могут быть настроены с помощью новых параметров групповой политики (Certificate Path Validation Settings вкладка Revocation).

В отличие от использования списков отзыва, Online Responder требуется вначале установить и настроить. Для этого надо выполнить следующие шаги:

1. Добавить компонент Online Responder роли AD CS. Для работы Online Responder требуется IIS, который будет автоматически предложено установить.
2. В свойствах CA для AIA указать путь, по которому доступен ответчик.
3. Так как ответ о статусе сертификата подписывается, то для работы Online Responder требуется соответствующий сертификат. Сертификат, который будет использоваться ответчиком, должен обладать следующими атрибутами: короткий срок действия (несколько недель), наличие расширения id-pkix-ocsp-nocheck и расширенного использования ключа id-kp-OCSPSigning, отсутствие CDP и AIA. Эти атрибуты уже настроены в шаблоне OCSP Response Signing. В случае использования Enterprise CA надо только добавить его к доступным шаблонам в Active Directory, настроив на него разрешения (Read и Enroll) для сервера, на который установлен Online Responder. Для StandAlone CA надо еще менять значение соответствующего флага командой certutil -v -setreg policy\editflags +EDITF_ENABLEOCSPREVNOCHECK. Действия по настройке шаблона в Windows Server 2003 отличаются и здесь не рассматриваются.
4. На последнем этапе необходимо настроить сам сетевой ответчик. Для этого в оснастке Online Responder Management с помощью мастера надо создать revocation configuration.
5. Для корректной работы Online Responder в период, когда происходит обновление ключа CA, необходимо разрешить обновления сертификатов Online Responder с использованием существующих ключей центра сертификации. Для этого надо выполнить на CA команду certutil -setreg ca\UseDefinedCACertInRequest 1. Данное действие необходимо для получения возможности подписывать ответы Online Responder с помощью сертификата, подписанного тем же ключом CA, который использовался для подписания сертификата, статус которого запрашивается.

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

Заключение

Видоизменения служб сертификации производились и в Windows Server 2008, и в R2. В итоге появились возможности, которые будут интересны специалистам по безопасности, инструменты, которые облегчат жизнь администратора, и функции, которые позволят пользователям еще меньше разбираться в сертификатах.

Во-первых, добивалась поддержка новых протоколов и криптографических алгоритмов. Протокол OCSP, который уже не один год присутствовал в других программных продуктах, наконец-то дошел до серверных ОС Microsoft. Таким образом, у администраторов и программистов появились различные варианты для проверки статуса отозванных сертификатов, которые позволяют выбирать между скоростью, объемом данных и актуальностью информации. Немаловажно и появление поддержки алгоритмов на эллиптических кривых. К сожалению, поддерживаются не российские, а американские стандарты, но ожидать иного было бы странно.

Во-вторых, многие библиотеки (например, Crypto API и XEnroll.dll) переписаны с нуля, из-за чего можно надеяться на избавление от старых ошибок и проблем, и ждать новых.
В-третьих, значительно расширились способы запроса и получения сертификатов. Теперь сертификаты могут получать и сетевые устройства без записи в домене, и пользователи без прямого доступа к сети с CA.

И наконец, без внимания не оставлены и любители автоматизации и скриптописания – новые объекты и функции позволят им реализовать свои фантазии.

В этой части серии использованы следующие сокращения и аббревиатуры:

• PKI (Public Key Infrastructure ) - инфраструктура открытого ключа, набор средств (технических, материальных, людских и т. д.), распределённых служб и компонентов, в совокупности используемых для поддержки криптозадач на основе закрытого и открытого ключей. Поскольку аббревиатура ИОК не является распространённой, здесь и далее будет использоваться более знакомая англоязычная аббревиатура PKI.
• X.509 - стандарт ITU-T для инфраструктуры открытого ключа и инфраструктуры управления привилегиями.
• ЦС (Центр Сертификации ) - служба выпускающая цифровые сертификаты. Сертификат - это электронный документ, подтверждающий принадлежность открытого ключа владельцу.
• CRL (Certificate Revocation List ) - список отзыва сертификатов. Подписанный электронный документ, публикуемый ЦС и содержащий список отозванных сертификатов, действие которых прекращено по внешним причинам. Для каждого отозванного сертификата указывается его серийный номер, дата и время отзыва, а также причина отзыва (необязательно). Приложения могут использовать CRL для подтверждения того, что предъявленный сертификат является действительным и не отозван издателем… Приложения могут использовать CRL для подтверждения, что предъявленный сертификат является действительным и не отозван издателем.
• SSL (Secure Sockets Layer ) или TLS (Transport Layer Security ) - технология обеспечивающая безопасность передачи данных между клиентом и сервером поверх открытых сетей.
• HTTPS (HTTP/Secure ) - защищённый HTTP, является частным случаем использования SSL.
• Internet PKI - набор стандартов, соглашений, процедур и практик, которые обеспечивают единый (унифицированный) механизм защиты передачи данных на основе стандарта X.509 по открытым каналам передачи данных.
• CPS (Certificate Practice Statement ) - документ, описывающий процедуры управления инфраструктурой открытого ключа и цифровыми сертификатами.

Общий план развёртывания

Для развёртывания службы сертификатов нам потребуется четыре машины с Windows Server 2016, которые будут выполнять следующие функции:

1. Контроллер домена - необходим для функционирования домена Active Directory;
2. Веб-сервер - будет обеспечивать доступ к сертификатам ЦС и спискам отзывов для клиентов;
3. Корневой ЦС - будет выполнять функции корневого ЦС;
4. Подчинённый ЦС - будет выполнять функции издающего ЦС.

Развёртывание PKI будет проходить поэтапно на каждом сервере в том порядке, в котором они указаны выше. Подготовка контроллера домена будет сводиться к обеспечению функций Active Directory, GPO и учётных записей.

Подготовка контроллера домена

Перед развёртыванием PKI необходимо убедиться в работоспособности домена Active Directory и что все необходимые серверы (а именно, веб-сервер и подчинённый ЦС) введены в домен. А так же, что подготовлены необходимые учётные записи. На данном этапе нам потребуется только учётная запись с правами Enterprise Admins.

Ряд операций на подчинённом ЦС требуют прав Enterprise Admins, поскольку производится запись в раздел configuration naming context. Если это корневой домен леса, то для этих операций достаточно прав Domain Admins.

Следующим шагом будет конфигурирование политики автоматической выдачи сертификатов (autoenrollment). Эта политика нужна будет в процессе эксплуатации служб сертификатов для автоматической выдачи и обновления истёкших сертификатов на клиентах. Политика настраивается в конфигурации компьютера и пользователя:

• Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Infrastructure\Certificate Services Client – Auto-Enrollment
• User Configuration\Policies\Windows Settings\Security Settings\Public Key Infrastructure\Certificate Services Client – Auto-Enrollment

Политика в обоих разделах должна быть сконфигурирована как показано на следующей картинке:

Сконфигурированный объект групповых политик (GPO) должен быть пристыкован к корню домена. Данную процедуру необходимо повторить во всех доменах текущего леса Active Directory.

Далее, необходимо создать запись типа CNAME с именем CDP на сервере ДНС, который будет указывать на веб-сервер (IIS). Эту процедуру необходимо выполнить как на внутреннем, так и на внешнем (который обслуживает зону в интернете) серверах ДНС. Запись можно создать при помощи PowerShell:

Add-DnsServerResourceRecord -CName -Name "cdp" -HostNameAlias "iis.contoso.com" -ZoneName "contoso.сom" 

Подготовка веб-сервера

На веб-сервере нам потребуется выполнить следующее: установить службу IIS (если ещё не установлена), создать общую папку и сконфигурировать веб-сайт на использование этой папки.

• Установка службы IIS

Для установки службы IIS можно воспользоваться следующей командой:

Install-WindowsFeature -Name Web-Server, Web-WebServer -IncludeManagementTools

• Создание папки PKIdata

Согласно нашей конфигурационной таблице (см. часть 2), для хранения сертификатов ЦС и списков отзыва нам потребуется общая папка с сетевым именем PKI по следующему пути: C:\InetPub\wwwroot\PKIdata

New-Item -ItemType Directory -Path C:\InetPub\wwwroot -Name PKIdata -Force New-SmbShare -Path C:\inetpub\wwwroot\PKIdata -Name PKI -FullAccess everyone
После этого нужно выдать права NTFS на запись в эту папку для группы Cert Publishers.

• Создание веб-сайта

Теперь нам необходимо создать отдельный веб-сайт с именем “CDP” и хост-именем “cdp.contoso.com”:

New-Website -Name CDP -HostHeader cdp.contoso.com -PhysicalPath C:\inetpub\wwwroot\PKIdata New-WebVirtualDirectory -Site cdp -Name pki -PhysicalPath C:\inetpub\wwwroot\PKIdata

• Включение поддержки Delta CRL

В нашем сценарии издающий ЦС будет публиковать Delta CRL, которые содержат символ плюс «+» в имени файла (например, contoso-pica+.crl). По умолчанию, IIS будет расценивать этот символ в запросе как метасимвол и не позволит клиентам скачать список отзыва. Для этого необходимо включить двойной эскейпинг в настройках IIS, чтобы расценивать знак плюса в запросе как литерал:

Import-Module -Name WebAdministration Set-WebConfigurationProperty -PSPath "MACHINE/WEBROOT/APPHOST" -Filter /system.webServer/security/requestFiltering -name allowdoubleescaping -Value "true"

Установка корневого ЦС

Фактическая установка ЦС будет включать в себя несколько этапов:

1. Установка компонента ЦС;
2. Проверка установки.

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

Предварительная конфигурация

Предварительные конфигурационные файлы необходимы для ряда настроек, которые невозможно задать во время установки компонента (ни при помощи графического интерфейса, ни при помощи командной строки или PowerShell). К ним обычно относятся настройки расширений сертификата ЦС. Например, для настройки расширения сертификата Certificate Policies, необходимо использовать предварительный конфигурационный файл, в котором настраиваются параметры расширения. Для Microsoft ADCS таким файлом является файл CAPolicy.inf, который должен быть расположен по следующему пути: %windir%\CAPolicy.inf. С синтаксисом этого файла можно ознакомиться в следующей статье: How CA Certificates Work . Поскольку никаких специфичных или нестандартных настроек в сертификате корневого ЦС мы делать не будем, поэтому и предварительный конфигурационный файл сейчас нам не потребуется.
 

Установка компонента ЦС

После этого сверьтесь с предыдущей таблицей, чтобы определить параметры установки. Исходя из данных таблицы, зададим параметры для командлета Install-AdcsCertificationAuthority :

Install-AdcsCertificationAuthority -CACommonName "Contoso Lab Root Certification Authority" ` -CADistinguishedNameSuffix "OU=Division Of IT, O=Contoso Pharmaceuticals, C=US" ` -CAType StandaloneRootCA ` -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" ` -KeyLength 4096 ` -HashAlgorithmName SHA256 ` -ValidityPeriod "years" ` -ValidityPeriodUnits 15 ` -DatabaseDirectory $(Join-Path $env:SystemRoot "System32\CertLog")

Итоговая настройка

После установки компонента ЦС необходимо настроить рабочие параметры ЦС. Рассмотрим ещё раз элементы, которые нам необходимо настроить:

Название параметра	Значение параметра
Сервер ЦС
	15 лет
Точки публикации CRT	1) По-умолчанию 2) C:\CertData\contoso-rca< CertificateName >.crt < CertificateName >.crt*
Точки распространения CRT	1) cdp.contoso.com/pki/contoso-rca < CertificateName >.crt
Точки публикации CRL	1) По-умолчанию 2) C:\CertData\contoso-rca< CRLNameSuffix >.crt 3) IIS:\InetPub\PKIdata\contoso-rca< CRLNameSuffix >.crt*
Точки распространения CRL	1) cdp.contoso.com/pki/contoso-rca < CRLNameSuffix >.crt
Сертификат
Состав CRL	Base CRL
Base CRL
Тип	Base CRL
Срок действия	6 месяцев
Расширение срока действия	1 месяц
Алгоритм подписи	SHA256
Публикация в AD	Нет

* - копируется на сервер IIS

Скрипт настройки

Для конфигурирования настроек ЦС мы будем использовать BATCH скрипт с использованием утилиты certutil.exe:

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: Root CA post-installation script:: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: все комментарии помечены знаком двойного двоеточия (::) :: записываем пути для публикации и распространения сертификатов ЦС и списков отзыва:: в отдельные переменные SET CrlLocal=C:\CertData\contoso-rca%%8.crl SET CDP=http://cdp.contoso.com/pki/contoso-rca%%8.crl SET AIA=http://cdp.contoso.com/pki/contoso-rca%%4.crt:: Создаём папку в корне системного диска, куда будут записываться файлы ЦС. Эта папка:: создаётся для удобства, чтобы не искать папку CertEnroll в глубине папки Windows. md C:\CertData:: Настраиваем пути публикации и распространения для сертификатов ЦС и списков отзыва. certutil -setreg CA\CRLPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%3%%8.crl\n1:%CrlLocal%\n2:%CDP%" certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:%AIA%" :: Поскольку мы не можем указывать пути публикации для файла сертификата, мы:: вручную переименовываем его в необходимый формат и копируем в папку CertData ren %windir%\system32\CertSrv\CertEnroll\*.crt contoso-rca.crt copy %windir%\system32\CertSrv\CertEnroll\contoso-rca.crt C:\CertData:: Задаём срок действия издаваемых сертификатов certutil -setreg CA\ValidityPeriodUnits 15 certutil -setreg CA\ValidityPeriod "Years" :: Задаём время жизни списков отзыва согласно нашей конфигурации certutil -setreg CA\CRLPeriodUnits 180 certutil -setreg CA\CRLPeriod "Days" certutil -setreg CA\CRLOverlapPeriod "Months" certutil -setreg CA\CRLOverlapUnits 1:: Отключаем дифференциальные списки отзыва (или Delta CRL) certutil -setreg CA\CRLDeltaPeriodUnits 0:: Отключаем генерацию кросс-сертификатов certutil -setreg ca\CRLFlags +CRLF_DISABLE_ROOT_CROSS_CERTS:: Конфигурируем ЦС для включения истёкших отозванных сертификатов в списки отзыва certutil –setreg ca\CRLFlags +CRLF_PUBLISH_EXPIRED_CERT_CRLS:: Включаем полный аудит событий на ЦС** certutil -setreg CA\AuditFilter 127:: если версия ОС ниже, чем Windows Server 2016 необходимо задать алгоритм подписи. :: Windows Server 2016 по умолчанию использует SHA256. Certutil -setreg ca\csp\CNGHashAlgorithm SHA256:: Перезапускаем службу ЦС для применения изменений. net stop certsvc && net start certsvc:: Публикуем списки отзыва. certutil -CRL
Ряд команд нуждается в более развёрнутом пояснении. Команды с настройкой расширений CRL Distribution Points и Authority Information Access имеют специфический синтаксис. Во-первых, пути публикации и распространения указываются в одну строку и разделяются символом новой строки «\n». Каждый путь начинается с числа и отделяется от самого пути символом двоеточия. Это число в начале пути указывает битовую маску флагов публикации для конкретного пути. Значение каждого бита для расширений CDP и AIA приведено в следующей таблице:

Название галочки в MMC	Числовое значение	Название галочки в MMC	Числовое значение
Publish CRLs to this location.	1	Include in the AIA extension of issued certificates.	2
Include in the CDP extension of issued certificates.	2	Include in the Online Certificate Status. Protocol (OCSP) extension.	32
Include in CRLs. Clients use this to find Delta CRL locations.	4
Include in all CRLs. Specifies where to publish in AD DS when publishing manually.	8
Publish Delta CRLs to this location.	64
Include in the IDP extension of issued CRLs.	128

Если взять путь для CDP: 1:%windir%\system32\CertSrv\CertEnroll\%%3%%8.crl, то цифра 1 в начале строки говорит о том, что это путь физического размещения файла (Publich CRLs to this location). Другие опции здесь не используются. Для включения пути, который будет публиковаться в издаваемых сертификатах, мы будем использовать опцию «Include in the CDP extension of issued certificates» с числовым значением 2. Такой же принцип применяется и для остальных путей.

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

Первый знак процента используется как эскейп-символ, чтобы процессор командной строки воспринял следующий знак процента как литерал. Дело в том, что знак процента в командном процессоре CMD является служебным символом. Сервер ЦС так же использует знак процента для указания, что это переменная. Для исключения конфликта в командном процессоре используется последовательность из двух знаков процента.

Следующая таблица содержит описание всех доступных переменных и их краткое описание:

Переменная в редакторе расширений CDP и AIA	Переменная в скрипте	Где используется	Значение
< ServerDNSName >	%1	CDP/AIA	Полное ДНС имя сервера ЦС
< ServerShortName >	%2	CDP/AIA	Короткое (NetBIOS) имя сервера ЦС
< CaName >	%3	CDP/AIA	Имя ЦС (атрибут CN в сертификате)
< CertificateName >	%4	AIA	Индекс сертификата ЦС. Используется только при обновлении сертификата ЦС.
< ConfigurationContainer >	%6	CDP/AIA	Путь к configuration naming context в Active Directory
< CATruncatedName >	%7	CDP/AIA	Укороченное (санитизированное) имя сертификата ЦС. В общем случае будет совпадать с полным именем ЦС
< CRLNameSuffix >	%8	CDP	Индекс ключа ЦС, которым был подписан данный CRL. Используется при обновлении ключевой пары ЦС.
< DeltaCRLAllowed >	%9	CDP	Добавляет суффикс для Delta CRL (знак «+»).
< CDPObjectClass >	%10	CDP
< CAObjectClass >	%11	CDP/AIA	Класс объекта в Active Directory

В нашем конкретном случае будут использоваться только две переменные: и . Для исходного сертификата ЦС эти переменные пустые. При обновлении сертификата ЦС, переменная будет заменяться на «(index)», где index - номер сертификата ЦС. Индексирование начинается с нуля. Например, имя файла для последующего сертификата ЦС будет иметь вид: contoso-rca(1).crt. И так далее. То же самое касается и переменной, только здесь будет указываться индекс ключевой пары ЦС.

Отдельного внимания заслуживает команда, которая включает аудит операций на сервере ЦС, которые регистрируются в системном журнале Security.evtx. К ним относятся все основные операции: запуск/остановка службы, отправление запроса, выпуск или отклонение сертификата, выпуск списка отзыва. Эту строчку можно найти практически в каждом постустановочном скрипте для ЦС, которые можно найти в похожих статьях в интернете. И практически никто не утруждает себя в подробном объяснении механизма его работы, просто копируют из статьи в статью.

Особенность ведения аудита ЦС заключается в том, что настройка флагов аудита на ЦС является необходимым, но не достаточным условием. Механизм аудита основан на регистрации событий в журнале Security.evtx, который, в свою очередь зависит от настройки политики Audit Object Access в групповых политиках. Т.е. без настройки групповых политик никакого аудита не будет.

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

Прочие настройки

После того как корневой ЦС установлен и сконфигурирован, убедитесь, что всё прошло без ошибок:

• Откройте оснастку Certification Authorities MMC (certsrv.msc), убедитесь, что служба запущена;
• Выберите свойства узла ЦС и проверьте поля сертификата, что они соответствуют ожидаемым значениям;
• Найдите в корне системного диска папку CertData и убедитесь, что там находится два файла: сертификат и список отзыва. Убедитесь, что поля списка отзыва соответствуют ожидаемым значениям.

Если всё хорошо, тогда скопируйте содержимое папки C:\CertData на сервер IIS в папку PKIData. Сертификат корневого ЦС уже можно импортировать на все устройства, которые будут использовать нашу PKI.

Для импорта сертификата на доменные клиенты, достаточно загрузить его в Active Directory и после обновления групповых политик на клиентах, сертификат будет установлен в локальные хранилища сертификатов во всём лесу. Для публикации сертификата в AD необходимо выполнить следующую команду:

Certutil -f -dspublish path\contoso-rca.crt RootCA
Для установки сертификата на клиентах в рабочих группах и мобильные устройства необходимо воспользоваться другими инструментами, которые есть в вашем распоряжении. Например, System Center Configuration Manager или Mobile Device Management. Если подходящих инструментов нет, можно копировать и устанавливать сертификат на компьютеры при помощи утилиты certutil.exe. Для установки сертификата в локальное хранилище сертификатов выполните следующую команду:

Certutil -f -addstore Root path\contoso-rca.crt

Установка издающего ЦС

Как и в случае с корневым ЦС, установка издающего ЦС включает в себя четыре этапа:

1. Подготовка предустановочных конфигурационных файлов (CAPolicy.inf);
2. Установка компонента ЦС;
3. Выполнение постустановочной конфигурации;
4. Проверка установки и конфигурации.

Предустановочная конфигурация

Если для корневого ЦС предустановочный конфигурационный файл нам не требовался, то для издающего ЦС он понадобится. В нём мы настроим расширения Certificate Policies и Basic Constraints для сертификата ЦС. Если с политиками всё понятно, то в расширении Basic Constraints мы запретим выдачу сертификатов другим ЦС с издающего ЦС, поскольку у нас двухуровневая иерархия и добавление новых уровней только усложняет нашу структуру и увеличивает время, затрачиваемое на проверку сертификатов клиентами. Также отключим автоматическую загрузку шаблонов из Active Directory в список выдаваемых шаблонов. По умолчанию, сервер ЦС загружает на выдачу некоторый набор шаблонов сертификатов. Это вредно по двум причинам:

1. Контроллеры домена практически мгновенно обнаруживают появление ЦС в лесу и даже при отключённой политике автоматической выдачи сами запрашивают себе сертификаты.
2. Администраторы сами должны определять какие шаблоны будут использовать в организации.

Поэтому мы сконфигурируем ЦС так, что список шаблонов к выдаче будет пустым. Это возможно сделать только через CAPolicy.inf. В нашем случае он будет иметь следующее содержимое:

; заголовок INI файла Signature= "$Windows NT$" ; указываем список политик, которые будут включены в сертификат ЦС. В нашем; случае будет одна политика под названием AllIssuancePolicies. Policies = AllIssuancePolicy ; конфигурируем детали самой политики. Ссылку на документ Certificate Practice ; Statement (CPS) и объектный идентификатор политики URL = http://cdp.contoso.com/pki/contoso-cps.html OID = 2.5.29.32.0 IsCA = True PathLegth = 0 IsCritical = True ; секция прочих настроек ЦС ; отключаем автоматическую загрузку шаблонов сертификатов для выдачи LoadDefaultTemplates = 0
Файл с именем CAPolicy.inf необходимо скопировать в системную папку Windows до установки ЦС.

Установка компонента ЦС

Прежде всего необходимо добавить установочные компоненты для AD CS:

Install-WindowsFeature AD-Certificate, ADCS-Cert-Authority -IncludeManagementTools
После этого посмотрим на установочную таблицу, чтобы определить параметры установки:

Название параметра	Значение параметра
Сервер ЦС
Класс ЦС	Enterprise CA
Тип ЦС	Subordinate CA
Нет
Сертификат
Имя сертификата	Contoso Lab Issuing Certification authority
Дополнительный суффикс	OU=Division Of IT, O=Contoso Pharmaceuticals, C=US
Провайдер ключа	RSA#Microsoft Software Key Storage Provider
Длина ключа	4096 бит
Алгоритм подписи	SHA256
Срок действия	15 лет (определяется вышестоящим ЦС)
Политики выдачи	1) Имя: All Issuance Policies OID=2.5.29.32.0 URL=http://cdp.contoso.com/pki/contoso-cps.html
Basic Constraints	isCA=True (тип сертификата - сертификат ЦС) PathLength=0 (запрещается создание других промежуточных ЦС под текущим ЦС).

В таблице я выделил только те параметры, которые задаются в процессе установки. Остальные параметры будут настраиваться после установки. Исходя из этих данных сформируем параметры для командлета Install-AdcsCertificationAuthority :

Install-AdcsCertificationAuthority -CACommonName "Contoso Lab Issuing Certification authority" ` -CADistinguishedNameSuffix "OU=Division Of IT, O=Contoso Pharmaceuticals, C=US" ` -CAType EnterpriseSubordinateCa ` -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" ` -KeyLength 4096 ` -HashAlgorithmName SHA256
После выполнения этой команды будет выведено сообщение о том, что установка ЦС не завершена и для её завершения необходимо отправить сгенерированный запрос (находится в корне системного диска) на вышестоящий ЦС и получить подписанный сертификат. Поэтому находим файл с расширением «.req» в корне системного диска и копируем его на корневой ЦС и на корневом ЦС выполняем следующие команды:

# отправляем запрос на ЦС. certreq -submit "C:\CA-01.contoso.com_Contoso Lab Issuing Certification authority.req" # предыдущая команда выведет номер запроса. Укажите этот номер запроса в следующей команде # в моём случае это номер 2 certutil -resubmit 2 # после выпуска сертификата сохраните его в файл. При этом укажите тот же самый номер # запроса, который был указан после выполнения первой команды certreq -retrieve 2 C:\subca.crt
Полученный файл (subca.crt) необходимо скопировать обратно на издающий ЦС и завершить инсталляцию:

Certutil -installcert c:\subca.crt net start certsvc
Мы устанавливаем на ЦС выписанный сертификат и запускаем службу сертификатов. После успешной установки можно запустить оснастку Certification Authorities MMC (certsrv.msc) и убедиться, что сертификат успешно установлен и ЦС в работающем состоянии. Теперь осталось дело за постустановочной конфигурацией.

Итоговая настройка

По аналогии с корневым ЦС, нам потребуется сконфигурировать ряд параметров на издающем ЦС. Для этого мы снова напишем BATCH скрипт с использованием утилиты certutil.exe. Но прежде всего посмотрим установочную таблицу и выясним параметры, которые нам необходимо настроить:

Аналогичная таблица составляется и для издающего ЦС.

Название параметра	Значение параметра
Сервер ЦС
Срок действия издаваемых сертификатов	Максимально: 5 лет (остальное контролируется шаблонами сертификатов)
Публикация в AD (контейнеры)	AIA NTAuthCertificates
Состав CRL	Base CRL Delta CRL
Точки публикации CRT	1) По-умолчанию 2) \\IIS\PKI\contoso-pica< CertificateName >.crt
Точки распространения CRT	1) cdp.contoso.com/pki/contoso-pica < CertificateName >.crt
Точки публикации CRL	1) По-умолчанию 2) \\IIS\PKI\contoso-pica< CRLNameSuffix >< DeltaCRLAllowed >.crl
Точки распространения CRL	1) cdp.contoso.com/pki/contoso-pica < CRLNameSuffix >< DeltaCRLAllowed >.crl
Base CRL
Тип	Base CRL
Срок действия	1 неделя
Расширение срока действия	По умолчанию
Алгоритм подписи	SHA256
Публикация в AD	Нет
Delta CRL
Тип	Delta CRL
Срок действия	1 день
Расширение срока действия	По-умолчанию
Алгоритм подписи	SHA256
Публикация в AD	Нет

За основу мы возьмём скрипт с корневого ЦС и изменим только отдельные фрагменты:

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: Issuing CA post-installation script:: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: все комментарии помечены знаком двойного двоеточия (::) :: записываем пути для публикации и распространения сертификатов ЦС и списков отзыва:: в отдельные переменные SET CrlLocal=\\IIS\PKI\contoso-pica%%8%%9.crl SET CDP=http://cdp.contoso.com/pki/contoso-pica%%8%%9.crl SET AIA=http://cdp.contoso.com/pki/contoso-pica%%4.crt:: Настраиваем пути публикации и распространения для сертификатов ЦС и списков отзыва. certutil -setreg CA\CRLPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n65:%CrlLocal%\n6:%CDP%" certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:%AIA%" :: Поскольку мы не можем указывать пути публикации для файла сертификата, мы:: вручную переименовываем его в необходимый формат и копируем в сетевую папку ren %windir%\system32\CertSrv\CertEnroll\*.crt contoso-pica.crt copy %windir%\system32\CertSrv\CertEnroll\contoso-pica.crt \\IIS\PKI:: Задаём срок действия издаваемых сертификатов certutil -setreg CA\ValidityPeriodUnits 5 certutil -setreg CA\ValidityPeriod "Years" :: Задаём время жизни списков отзыва согласно нашей конфигурации:: базовый CRL certutil -setreg CA\CRLPeriodUnits 1 certutil -setreg CA\CRLPeriod "weeks" :: Delta CRL certutil -setreg CA\CRLDeltaPeriodUnits 1 certutil -setreg CA\CRLDeltaPeriod "days" :: Включаем полный аудит событий на ЦС** certutil -setreg CA\AuditFilter 127:: Включаем наследование расширения Certificate Policies в издаваемых сертификатах certutil -setreg Policy\EnableRequestExtensionList +"2.5.29.32" :: Включаем поддержку расширения OcspRevNoCheck, если планируется установка:: сетевого ответчика (Online Responder или OCSP сервера) certutil -v -setreg policy\editflags +EDITF_ENABLEOCSPREVNOCHECK:: если версия ОС ниже, чем Windows Server 2016 необходимо задать алгоритм подписи. :: Windows Server 2016 по умолчанию использует SHA256. Certutil -setreg ca\csp\CNGHashAlgorithm SHA256:: Перезапускаем службу ЦС для применения изменений. net stop certsvc && net start certsvc:: Публикуем списки отзыва. certutil -CRL
Заметим, что в путях CRLDistribution Points, изменены флаги публикации (добавлена публикация Delta CRL) и добавлена переменная %9 в имя файла для поддержки уникального имени для дельты.

Здесь мы больше не создаём папку в корне системного диска, а используем сетевую папку PKI на сервере IIS, куда напрямую копируем файл сертификата и публикуем списки отзыва.

Прочие настройки

После того как издающий ЦС установлен и сконфигурирован, убедитесь, что всё прошло без ошибок:

• Откройте оснастку Certification Authorities MMC (certsrv.msc), убедитесь, что служба запущена
• Выберите свойства узла ЦС и проверьте поля сертификата, что они соответствуют ожидаемым значениям.
• Откройте сетевую папку PKI (на сервере IIS) и убедитесь, что там есть два файла сертификата (корневого и издающего ЦС) и три списка отзыва (один для корневого, два для издающего ЦС). Убедитесь, что поля в сертификатах и списках отзыва соответствуют ожидаемым значениям.

Когда основные параметры проверены, необходимо убедиться в правильной связи иерархии ЦС и доступности всех внешних файлов для клиентов. Для этого на сервере ЦС (а лучше, на рабочей станции, где установлены средства удалённого администрирования ЦС) необходимо запустить оснастку Enterprise PKI Health (pkiview.msc). Оснастка автоматически построит текущую иерархию и проверит доступность всех путей для скачивания сертификатов ЦС и списков отзыва. Никаких ошибок быть не должно. Если есть ошибка, необходимо её точно идентифицировать и устранить. В случае успешной настройки оснастка будет выглядеть следующим образом для корневого ЦС:

И для издющего ЦС:

Если вся итоговая конфигурация соответствует ожидаемым значениям и оснастка Enterprise PKI Health не показывает ошибок, это может судить о том, что PKI установлена верно.
 

После того, как все ЦС установлены, сконфигурированы и их работоспособность проверена, можно приступать к их эксплуатации. В этом разделе я дам несколько полезных рекомендаций, которых следует придерживаться, чтобы предостеречь себя от возможных потенциальных проблем во время эксплуатации PKI.

Шаблоны сертификатов

Наряду с установкой издающего ЦС, в Active Directory устанавливается набор уже готовых шаблонов сертификатов. Их можно просмотреть в оснастке Certificate Templates MMC (certtmpl.msc). Рекомендации по шаблонам сертификатов:

Использование готовых шаблонов сертификатов

Я рекомендую использовать их копии, даже если вы не планируете вносить в них изменения. Для создания копии шаблона выберите в списке подходящий шаблон, в контекстном меню выберите Duplicate Template и создайте его копию. Целесообразно в имя шаблона включить название компании, чтобы отличить предустановленный шаблон от вами созданного. Например, Contoso Web Server, Contoso Smart Card Logon . Это позволит сравнить настройки исходного и вами созданного шаблона в случае неработоспособности шаблона.

Версия шаблона

Начиная с Windows Server 2012, интерфейс создания шаблона несколько изменился. В самом начале появляется окно с выбором версии ОС на ЦС и предполагаемом клиенте:

Если у вас используются современные версии ОС (например, Windows 7 и выше), может появиться желание выставить настройки на максимум. Если вы не уверены, что ваше приложение совместимо с CNG (Cryptography Next Generation), следует использовать настройки, которые приведены на картинке. Если вы выставляете ОС сервера и клиента выше, чем Windows Server 2003/Windows XP, шаблон будет использовать криптографию несовместимую с этими приложениями. Например, большинство приложений, написанных на.NET, семейство продуктов System Center, службы федераций (AD FS) и т.д. не смогут использовать ключи таких сертификатов (но проверять смогут).

Успешно такие сертификаты смогут использовать приложения, которые используют не.NET, а нативные функции CryptoAPI. К таким приложениям можно отнести, например, IIS, Remote Desktop Services.
Поля Subject и Subject Alternative Names

Существует два метода заполнения поля Subject и расширения Subject Alternative Names: автоматический и ручной. Это настраивается в настройках шаблона сертификата, во вкладке Subject Name.

Если выбран второй пункт (как на картинке), ЦС игнорирует имя субъекта из запроса сертификата и заполняет эти поля из свойств учётной записи пользователя или устройства, которое запрашивает сертификат. В ряде случаев это не подходит (например, сертификаты для внутренних веб-сайтов) и имя субъекта заполняется из значения в запросе сертификата. Тогда переключатель необходимо выставить в верхнее положение. Дополнительно к этому, на вкладке Issuance Requirements обязательно надо выставить галочку «CA certificate manager approval».

Это необходимо затем, что имя для сертификата никак не проверяется. Если этот момент не контролировать, пользователь может запросить сертификаты на любое имя и скомпрометировать весь лес Active Directory. Вряд ли вы позволите рядовому пользователю получить сертификат на имя администратора. После требования одобрения запроса менеджером сертификатов на ЦС, каждый запрос с явным указанием субъекта сертификата будет попадать на ЦС в папку Pending Requests и не будет подписан, пока оператор ЦС не изучит его содержимое и не примет решение о выпуске. Т.е. каждый такой запрос необходимо вручную проверять на содержимое и убедиться, что в запросе указаны верные и допустимые имена. В противном случае запрос должен быть отклонён.

Права на шаблоны сертификатов

Шаблоны сертификатов в Active Directory хранятся в разделе configuration naming context, который реплицируется между всеми контроллерами домена в лесу. Поэтому для назначения прав на шаблоны сертификатов можно использовать только глобальные и универсальные группы. Избегайте назначения прав отдельным пользователям и устройствам.
 

Обновление сертификатов ЦС

Периодически необходимо обновлять сертификаты ЦС. Рассмотрим несколько аспектов, связанных с обновлением сертификатов ЦС.

Периодичность обновления сертификата ЦС

Это делается в следующих случаях:

• Срок жизни сертификата ЦС истекает;
• Ключ ЦС скомпрометирован;
• Необходимо изменить длину ключа или алгоритм подписи;
• Слишком большой список отзыва (больше нескольких мегабайт).

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

Сертификат издающего ЦС должен обновляться за максимальный срок действия издаваемых сертификатов. В нашем случае срок действия сертификата издающего ЦС 15 лет, а максимальный срок действия издаваемых сертификатов 5 лет (см. конфигурационную таблицу). Это означает, что сертификат издающего ЦС необходимо обновить через 10 лет. Если это время затянуть, то мы не сможем обеспечить необходимый срок действия для самого долгосрочного шаблона.

Порядок обновления ЦС

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

Генерация ключей при обновлении сертификатов ЦС

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

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

Перед каждым администратором рано или поздно возникает необходимость обеспечить безопасный обмен информации через интернет, внешние и внутренние сети, а также проверку подлинности каждой из сторон, участвующих в обмене информацией. На помощь здесь приходит инфраструктура открытых ключей (PKI) и службы сертификации Windows.

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

Для чего это может быть нужно на практике? Цифровые сертификаты позволяют использовать шифрование на уровне приложений (SSL/TLS) для защиты веб-страниц, электронной почты, служб терминалов и т.п., регистрацию в домене при помощи смарт-карт, аутентификацию пользователей виртуальных частных сетей (VPN), шифрование данных на жестком диске (EFS), а также в ряде случаев обойтись без использования паролей.

Для создания центра сертификации нам понадобится сервер, работающий под управлением Windows Server, который может быть как выделенным, так и совмещать роль центра сертификации с другими ролями. Однако следует помнить, что после развертывания центра сертификации вы не сможете поменять имя компьютера и его принадлежность к домену (рабочей группе).

Центр сертификации (ЦС) может быть двух типов: ЦС предприятия и изолированный (автономный) ЦС, рассмотрим их отличительные особенности:

ЦС предприятия

• Требует наличия ActiveDirectory
• Автоматическое подтверждение сертификатов
• Автоматическое развертывание сертификатов
• Возможность запроса сертификатов через Web-интерфейс, мастер запросов и автоматическое развертывание

Изолированный (автономный) ЦС

• Не требует наличия ActiveDirectory
• Ручное подтверждение сертификатов
• Отсутствие возможности автоматического развертывания
• Запрос сертификатов только через Web-интерфейс

Методика развертывания ЦС для Windows Server 2003 и Windows Server 2008 несколько различаются, поэтому мы решили рассмотреть их в отдельности.

Windows Server 2003

Для возможности использования Web-интерфейса для выдачи сертификатов нам понадобится установленный web-сервер IIS. Установим его через диспетчер сервера: Пуск - Управление данным сервером - Добавить или удалить роль .
В списке ролей выбираем роль Сервера приложений . В следующем окне устанавливаем галочку Включить ASP.NET , если IIS уже установлен данный шаг можно пропустить.

После установки IIS приступим к развертыванию Центра сертификации, это делается через оснастку Установка и удаление программ - Установка компонентов Windows , где выбираем Службы сертификации .

Следующим шагом выберите тип ЦС и его подчиненность. Так как в нашем случае сеть не имеет доменной структуры, то ЦС Предприятия недоступен для выбора. Поскольку это первый (и пока единственный ЦС) следует выбрать корневой сервер, подчиненный тип следует выбирать для развертывания следующих ЦС, например для филиалов.

Далее вводим имя ЦС (должно совпадать с именем сервера) и пути размещения файлов. В процессе установки программа предложит перезапустить IIS и, если не была включена поддержка страниц ASP.NET, предложит ее включить, с чем следует согласиться.

Windows Server 2008 R2

В Windows Server 2008 (2008 R2) все настройки консолидированы в одном месте, что делает установку ЦС более простой и удобной. Выбираем Диспетчер сервера - Роли - Добавить роли , в списке ролей выбираем Службы сертификации Active Directory .

В следующем окне обязательно добавляем компонент Служба регистрации в центре сертификации через интернет . При этом будут автоматически определены необходимые службы ролей и компоненты (такие как IIS) и будет предложено их добавить.

Дальнейшая настройка аналогична Windows Server 2003. Вводим тип ЦС, его имя и место хранения файлов, подтверждаем выбор компонент и завершаем установку.

Проверка работы ЦС

Для первоначальной проверки работоспособности ЦС можете запустить оснастку Центр сертификации (Пуск - Администрирование - Центр Сертификации). Если все сделано правильно вы должны увидеть следующее окно:
Попробуем теперь получить сертификат для клиентского ПК. Запустим браузер, в адресной строке которого укажем адрес http://имя_сервера/certsrv , где имя_сервера - имя сервера ЦС. Вы попадете на главную страницу центра сертификации.
Прежде всего необходимо загрузить сертификат ЦС и поместить его в хранилище доверенных коренных центров сертификации. Если в вашей сети несколько ЦС следует загрузить и установить цепочку сертификатов. Для этого выбираем: Загрузка сертификата ЦС, цепочки сертификатов или CRL , затем или и сохраняем сертификат в любое удобное место.

Теперь перейдем к установке, для этого щелкнем правой кнопкой на файле сертификата и выберем Установить сертификат , откроется мастер импорта, в котором откажемся от автоматического выбора хранилища вручную выбрав Доверенные корневые центры сертификации , теперь данный ПК будет доверять всем сертификатам выданным данным ЦС.

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

При попытке создать запрос сертификата вы можете получить следующее предупреждение:

В этом случае можно добавить данный узел в зону Надежные узлы и установить низкий уровень безопасности для этой зоны. В Windows Server понадобится также разрешить загрузку неподписанных ActiveX.

Теперь на сервере откроем оснастку Центр сертификации и в разделе Запросы на ожидание найдем наш запрос и щелкнув на него правой кнопкой выберем Все задачи - Выдать .

Теперь вернемся на клиентский ПК и еще раз откроем сайт ЦС. На этот раз выберем Просмотр состояния ожидаемого запроса сертификата , вы увидите свой запрос, щелкнув на которой вы попадете на страницу Сертификат выдан и сможете сразу его установить.

Если все сделано правильно, то сертификат успешно установится в хранилище личных сертификатов.

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

• Теги:

Please enable JavaScript to view the comments powered by Disqus.

Трекбэк

Протокол RDP с защитой на уровне сети (SSL), к сожалению, не получил широкого распространения среди системных администраторов, предпочитающих защищать терминальные соединения другим способом. Возможно это связано с кажущейся сложностью способа, однако...