СТЕПАН МОСКАЛЕВ, инженер ИТ-систем, 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. Часть 2. RootCA

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

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

Процедура самой установки службы сертификатов не отличается от установки любой другой роли Windows Server 2016 и знакома системному администратору. Добавляется новая роль – Active Directory Certificate Service. Перед установкой следует разместить файл capolicy.inf [1], содержимое которого мы обсуждали в предыдущей статье [3], в папке systemroot (см. рис. 1).

Рисунок 1. Сохранение файла capolicy.inf

Это позволит нам выполнить начальную конфигурацию сервера сертификатов. В процессе установки сервиса, вернее будет сказать после установочной настройки (см. рис. 2), потребуется задать учетную запись, от имени которой будет работать служба, тип развертывания – Stand Alone CA, роль удостоверяющего центра – RootCA.

Рисунок 2. Завершение процесса настройки сервера сертификатов

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

Рисунок 3. Значение AIA по умолчанию

Рисунок 4. Значения CDP по умолчанию

AIA расшифровывается как Au-thority Information Access и определяет место хранения актуальных сертификатов нашего сервера. CDP дает нам возможность определить место хранения списков отзывов, подписанных нашим сервером сертификатов. Оба эти расширения содержатся во всех выданных удостоверяющим центром сертификатах и, соответственно, должны быть доступны всем потребителям.

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

Изменение этих настроек может быть выполнено разными способами. Могут быть использованы графический интерфейс (GUI), утилита certutil [4], с помощью которой можно полностью выполнять любые задачи из командной строки, наконец, воспользоваться командлетами powershell.

Certutil.exe – программа командной строки, которая устанавливается как часть служб сертификации. Используется для сбора информации о конфигурации удостоверяющего центра, настройки служб сервиса, резервного копирования и восстановления компонентов ЦС и проверки сертификатов, пар ключей и цепочек сертификатов.

Администратор может вносить изменения в AIA и CDP-расширения, однако на уже выданные сертификаты это никак не повлияет, они содержат предыдущие значения, соответственно, надо учитывать этот факт и не лишать обладателей ранее выданных сертификатов возможности работы. Порядок строк в CDP определяет последовательность проверки списка отзыва сертификатов. Получается, что при наличии внешних клиентов надо учесть, что проверка, скажем, LDAP-пути, который поумолчанию стоит раньше в списке, будет для них просто невозможна. То есть станут возникать задержки [5], пока получится добраться до «рабочего» варианта. В этой ситуации целесообразно первым разместить HTTP-путь. Это же будет относиться и к не Windows-клиентам, которые не станут использовать LDAP для поиска сертификатов и списков отзыва.

Вообще наиболее часто используемым будет именно HTTP-вариант, поскольку он универсален и подходит любому клиенту независимо от его членства в домене AD DS и типа.

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

Еще один важный момент: как выполнить эти настройки? Конечно, это может быть сделано «вручную» с помощью графического интерфейса, однако при таком способе вероятность ошибок из-за невнимательности возрастает, поэтому лучше воспользоваться заранее подготовленным и отлаженным скриптом, который и выполнит все необходимые модификации реестра и настроит CA.

Для настройки параметров CDP будем применять утилиту certutil и воспользуемся следующей командой:

CertUtil [Options] -setreg

[{ca|restore|policy|exit|template|enroll|chain|PolicyServers}[ProgId]] RegistryValueName Value+ []

с помощью, которой и назначим точки публикации CRL.

Определимся с тем, каких результатов нам надо добиться.

Список отзыва сертификатов публикуется на самом сервере сертификатов в виде обычного файла с расширением CRL. Стало быть, надо указать папку, где будет этот файл храниться. Например, тот вариант, который предлагается по умолчанию: C:\Windows\system32\CertSrv\CertEnroll.

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

Пусть все настроено и наши клиенты уже работают с сертификатами, например пытаются подключиться по SSL.

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

Значит, список отзыва RootCA должен быть включен в выданные им сертификаты.

Какие пути надо включить? Первым будет HTTP, а вторым – LDAP-путь для клиентов AD. Вероятнее всего, до проверки LDAP дело не дойдет, но мы все-таки дополнительно внесем и этот путь.

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

certutil -setreg CA\CRLPublicationURLs

"1:C:\Windows system32\CertSrv\CertEnroll\%3%8.crl\n2:http://pki.nwtraders.msft/PKI/%3%8.crl\n10:

ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10"

Сам сертификат УЦ тоже должен где-то храниться, мы используем путь по умолчанию: C:\Windows\system32\CertSrv\CertEnroll.

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

Настройку AIA выполним таким образом:

certutil -setreg CA\CACertPublicationURLs

"1:C:\Windows\system32\CertSrv\CertEnroll\%3%4.crt\n2:http://pki.nwtraders.msft/PKI//%3%4.crt\n2:

ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11"

Для настройки срока действия сертификата и периодичности публикации CRL, если нам требуется изменить уже внесенные с помощью capolicy.inf значения, с помощью все той же утилиты certutil выполняются нижеследующие команды:

certutil -setreg CA\ValidityPeriodUnits 20

certutil -setreg CA\ValidityPeriod "Years"

certutil -setreg CA\CRLPeriodUnits 26

certutil -setreg CA\CRLPeriod "Weeks"

certutil -setreg CA\CRLOverlapUnits 2

certutil -setreg CA\CRLOverlapPeriod "Weeks"

certutil -setreg CA\CRLDeltaPeriodUnits 0

certutil -setreg CA\CRLDeltaPeriod "Hours"

Последовательно здесь настраиваются:

• Период действия сертификата центра сертификации
• Единицы измерения для ValidityPeriodUnits
• Периодичность выпуска списков CRL и Delta CRL, а также срок продленного действия списков CRL

Последнее, что осталось нам сделать, – настроить необходимый аудит.

certutil -setreg CA\AuditFilter 127

Наконец, для определения значения переменной %6 -<ConfigurationContainer> выполните следующую команду:

certutil -setreg ca\DSConfigDN "CN=Configuration,DC=nwtraders,DC= msft"

Вот теперь мы можем считать, что корневой центр сертификации развернут.

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

1. How CA Certificates Work. Overview of Capolicy.inf – https://technet.microsoft.com/en-us/library/cc737264(WS.10).aspx.
2. Prepare the Capolicy.inf – https://docs.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/server-certs/prepare-the-capolicy-inf-file.
3. Шапиро Л. Внедрение инфраструктуры открытых ключей на основе Windows Server 2016. Часть 1. Предварительный этап. / «Системный администратор», № 1-2, 2018 г. – С. 23-27. URL: http://samag.ru/archive/article/3576.
4. Certutil – https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/certutil.
5. Certification Authority Guidance – https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831574(v=ws.11).

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

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