Общий план развёртывания
Для развёртывания службы сертификатов нам потребуется четыре машины с Windows Server 2016, которые будут выполнять следующие функции:
- Контроллер домена — необходим для функционирования домена Active Directory;
- Веб-сервер — будет обеспечивать доступ к сертификатам ЦС и спискам отзывов для клиентов;
- Корневой ЦС — будет выполнять функции корневого ЦС;
- Подчинённый ЦС — будет выполнять функции издающего ЦС.
Развёртывание PKI будет проходить поэтапно на каждом сервере в том порядке, в котором они указаны выше. Подготовка контроллера домена будет сводиться к обеспечению функций Active Directory, GPO и учётных записей.
Задача: установить сертификат на определённой группы в домене polygon.local
Имеем домен контроллер dc1.polygon.local
Контейнер IT – располагаются рабочие станции.
Имеем сертификат (C:\OracleCorporation.cer, который я получил в предыдущей заметке), который нужно экспортировать все компьютерам в домене.
Я его переименовал в c:\OracleJDE.cer.
В качестве примера исходный путь, где располагается сертификат — C:\OracleJDE.cer
:
Разворачиваем лес polygon.local, после домен polygon.local и на контейнере IT
Называем её именем отражающим цель создания политики:
Политика будет назначаться:
на контейнер IT и группу GPO_CertInstall, в которую включены имена компьютеров.
Это мы создали пустую политику, а теперь .
Открываем на редактирование:
Для установки сертификата нужно отредактировать следующие ключи групповой политики:
«Computer Configuration» – «Policies» – «Windows Settings» – «Public Key Policies» –
«Trusted Publishers», далее импортируем наш сертификат OracleJDE.cer.
Жмём Next и указываем месторасположение сертификата ( В качестве примера C:\OracleJDE.cer).
Место оставляем всё как есть:
Всё, политика настроена. Ниже предстаставлен, скриншот, что в итоге должно получиться:
Политика настроена. На этом всё, удачи.
Приведенный ниже VBS скрипт добавляет все сертификаты из папки, указанной в переменной «path» в хранилище доверенных корневых сертификатов на локальном компьютере:
path = "\Root\"
Set WshShell = WScript.CreateObject( "WScript.Shell" )
Set objNetwork = CreateObject( "WScript.Network" )
set fso = CreateObject( "Scripting.FileSystemObject" )
Set fLog = fso.OpenTextFile( "!log_root_certs.txt", 8, True )
fLog.write vbCrLf & "=Начало=" & Now( ) & vbCrLf
fLog.write "Имя компа: " & objNetwork.ComputerName & vbCrLf
fLog.write "Имя пользователя: " & objNetwork.UserName & vbCrLf
fLog.write "Были установлены следующие сертификаты:" & vbCrLf & vbCrLf
i = 0
for each f in FSO.GetFolder( WshShell.CurrentDirectory & path ).Files 'тут указано имя папки, в которой ищем.
if right(f.name, 4) = ".cer" then
WshShell.Run "certmgr -add -c " & chr(34) & f & chr(34) & " -s -r localMachine root", 7, true
fLog.write f.name & vbCrLf
i = i + 1
end if
next
fLog.write vbCrLf & "Установлено сертификатов: " & i & vbCrLf & vbCrLf
fLog.close
Но, как я понял, проделать такой трюк с Active Directory с помощью утилиты «Certmgr», задействованной скриптом — не удастся.
Для этого слегка модернизируем скрипт в части параметров утилиты «Certmgr», то есть вместо хранилища локального компьютера укажем файл:
path = "\Root\"
Set WshShell = WScript.CreateObject( "WScript.Shell" )
Set objNetwork = CreateObject( "WScript.Network" )
set fso = CreateObject( "Scripting.FileSystemObject" )
Set fLog = fso.OpenTextFile( "!log_root_certs.txt", 8, True )
fLog.write vbCrLf & "=Начало=" & Now( ) & vbCrLf
fLog.write "Имя компа: " & objNetwork.ComputerName & vbCrLf
fLog.write "Имя пользователя: " & objNetwork.UserName & vbCrLf
fLog.write "Были установлены следующие сертификаты:" & vbCrLf & vbCrLf
i = 0
for each f in FSO.GetFolder( WshShell.CurrentDirectory & path ).Files 'тут указано имя папки, в которой ищем.
if right(f.name, 4) = ".cer" then
WshShell.Run "certmgr -add -c " & chr(34) & f & chr(34) & " certs.sst", 7, true
fLog.write f.name & vbCrLf
i = i + 1
end if
next
fLog.write vbCrLf & "Установлено сертификатов: " & i & vbCrLf & vbCrLf
fLog.close
После выполнения скрипта мы получим готовый файл «certs.sst», который будет включать в себя все сертификаты из папки, указанной в переменной «path». Этот файл можно использовать для импорта в AD (Конфигурация компьютера -> Политики -> Конфигурация Windows -> параметры безопасности -> Политики открытого ключа).
Протестировано на Windows Server 2008 R2.
* Авторство исходного кода (предположительно!) принадлежит компании «Тензор».
А вот и финальная третья часть нашей серии статей о центре сертификации на предприятии. Сегодня рассмотрим развертывание службы сертификатов на примере Windows Server 2016. Поговорим о подготовке контроллера домена, подготовке веб-сервера, установке корневого и издающего центров сертификации и об обновлении сертификатов. Заглядывайте под кат!
Первая часть серии
Вторая часть серии
Словарь терминов
В этой части серии использованы следующие сокращения и аббревиатуры:
- 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) — документ, описывающий процедуры управления инфраструктурой открытого ключа и цифровыми сертификатами.
If you use a self-signed SSL certificate for your Exchange server, the message will appear on the client computers during the first start of Outlook: this certificate is not trusted and it is not safe to use it.
First of all, you have to export the self-signed certificate from your Exchange server. To do it, logon to your server, run mmc.exe and add Certificates (for a local computer) snap-in.
Go to the section Certificates (Local Computer) -> Trusted Root Certification Authorities -> Certificates.
Find your Exchange certificate in the right pane, right click on it and select All Tasks -> Export.
In the Export Wizard, select DER encoded binary X.509 (.CER) format and specify the path to the certificate file.
You can also export the SSL certificate directly from the browser. In Internet Explorer, open the HTTPS address of your web server with an untrusted certificate (in the case of Exchange, this is usually an address of the form ). Click the Certificate Error icon in the address bar, click View Certificate, and go to the Details tab. Click the Copy to File button to open the Certificate Export to CER file wizard.
You can also get the SSL certificate of the HTTPS site and save it in a CER file from PowerShell using the WebRequest method:
Specify the policy name (Install-Exchange-Certificate) and switch to the policy edit mode.
In the GPO Editor, go to the section Computer Configuration –> Policies –> Windows Settings –> Security Settings –> Public Key Policies –> Trusted Root Certification Authorities.
Right-click in the right part of the GPO editor window and select Import.
The certificate distribution policy created. You can target this policy on the clients more accurately using Security Filtering or WMI GPO filtering.
Let’s test the group policy settings by running gpupdate /force
on the client. Verify that your certificate has appeared in the list of trusted certificates. It can be done either in the Manage Certificate snap-in (Trusted Root Certification Authorities -> Certificates) or in the Internet Explorer settings (Internet Options -> Content -> Certificates -> Trusted Root Certification Authorities).
Now during Outlook configuration the warning of the untrusted certificate won’t appear.
You can check that in the browser when you open your HTTPS site (in our example, this is Exchange OWA), a warning about an untrusted SSL certificate will no longer appear. Now, when you configure Outlook to connect your Exchange server (manual configuration of the Exchange server in Outlook 2016 is possible only through the registry), the warning of the untrusted certificate won’t appear.
If computers don’t have direct Internet access, in this way you can update trusted root certificates on all devices in the domain. But there is a simpler and more correct way to update root and revoked certificates in the isolated domains.
Thus, you have certain a policy of automatic certificate distribution on all domain computers (on a specific organizational unit or domain security group). The certificate will be automatically installed on all new computers, without requiring any manual actions from technical support team. For security reasons, it is advisable to periodically scan the Windows Certificate Root store for suspicious and revoked certificates.
Установка самоподписанных сертификатов весьма частая задача для системного администратора.
Обычно это делается вручную, но если машин не один десяток? И как быть при переустановке системы или покупке нового ПК, ведь сертификат может быть и не один. Писать шпаргалки-напоминалки? Зачем, когда есть гораздо более простой и удобный способ — групповые политики ActiveDirectory. Один раз настроив политику можно больше не беспокоится о наличии у пользователей необходимых сертификатов.
Наша задача будет стоять следующим образом — автоматически распространять сертификат на все компьютеры входящие в подраздление (OU) — Office. Это позволит не устанавливать сертификат туда, где он не нужен: на севера, складские и кассовые рабочие станции и т.д.
Откроем оснастку Управление групповой политикой и создадим новую политику в контейнере Объекты групповой политики, для этого щелкните на контейнере правой кнопкой и выберите Создать. Политика позволяет устанавливать как один, так и несколько сертификатов одновременно, как поступить — решать вам, мы же предпочитаем создавать для каждого сертификата свою политику, это позволяет более гибко менять правила их применения. Также следует задать политике понятное имя, чтобы открыв консоль через полгода вам не пришлось мучительно вспоминать для чего она нужна.
После чего перетащите политику на контейнер Office, что позволит применить ее к данному подразделению.
Теперь щелкнем на политику правой кнопкой мыши и выберем Изменить. В открывшемся редакторе групповых политик последовательно разворачиваем Конфигурация компьютераКонфигурация WindowsПараметры безопасностиПолитики открытого ключаДоверенные корневые центры сертификации. В правой части окна в меню правой кнопкой мыши выбираем Импорт и импортируем сертификат.
Политика создана, теперь самое время проверить правильность ее применения. Управление групповой политикойМоделирование групповой политики и запустим по правому щелчку Мастер моделирования
Большинство параметров можно оставить по умолчанию, единственное что следует задать — это пользователя и компьютер для которых вы хотите проверить политику.
Выполнив моделирование можем убедиться, что политика успешно применяется к указанному компьютеру, в противном случае раскрываем пункт Отклоненные объекты и смотрим причину по которой политика оказалась неприменима к данному пользователю или компьютеру.
Поскольку сертификаты добавляются в блок политик для компьютера, то для нормального применения политики, компьютер надо перезагрузить.
После перезагрузки компьютера откроем хранилище сертификатов. Проще всего это сделать через Internet ExplorerСвойства обозревателя Содержание Сертификаты. Наш сертификат должен присутствовать в контейнере Доверенные корневые центры сертификации
Как видим — все работает и одной головной болью у администратора стало меньше, сертификат будет автоматически распространяться на все компьютеры помещенные в подразделение Office. При необходимости можно задать более сложные условия применения политики, но это уже выходит за рамки данной статьи.
Deploying the certificates
Expand Computer Configuration, Policies, Security Settings, and select Public Key Policies. In the right pane, double click Certificate Services Client – Auto-Enrollment.
Select the dropdown box next to Configuration Model and select Enabled. We also want to select the first two check boxes. Once complete, click OK.
We want to select the same options as the computer certificate and then click OK.
Подготовка контроллера домена
Ряд операций на подчинённом ЦС требуют прав 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"
Установка издающего ЦС
Как и в случае с корневым ЦС, установка издающего ЦС включает в себя четыре этапа:
- Подготовка предустановочных конфигурационных файлов (CAPolicy.inf);
- Установка компонента ЦС;
- Выполнение постустановочной конфигурации;
- Проверка установки и конфигурации.
Предустановочная конфигурация
Если для корневого ЦС предустановочный конфигурационный файл нам не требовался, то для издающего ЦС он понадобится. В нём мы настроим расширения Certificate Policies и Basic Constraints для сертификата ЦС. Если с политиками всё понятно, то в расширении Basic Constraints мы запретим выдачу сертификатов другим ЦС с издающего ЦС, поскольку у нас двухуровневая иерархия и добавление новых уровней только усложняет нашу структуру и увеличивает время, затрачиваемое на проверку сертификатов клиентами. Также отключим автоматическую загрузку шаблонов из Active Directory в список выдаваемых шаблонов. По умолчанию, сервер ЦС загружает на выдачу некоторый набор шаблонов сертификатов. Это вредно по двум причинам:
- Контроллеры домена практически мгновенно обнаруживают появление ЦС в лесу и даже при отключённой политике автоматической выдачи сами запрашивают себе сертификаты.
- Администраторы сами должны определять какие шаблоны будут использовать в организации.
Поэтому мы сконфигурируем ЦС так, что список шаблонов к выдаче будет пустым. Это возможно сделать только через CAPolicy.inf. В нашем случае он будет иметь следующее содержимое:
; заголовок INI файла
[Version]
Signature= "$Windows NT$"
; указываем список политик, которые будут включены в сертификат ЦС. В нашем
; случае будет одна политика под названием AllIssuancePolicies.
[PolicyStatementExtension]
Policies = AllIssuancePolicy
; конфигурируем детали самой политики. Ссылку на документ Certificate Practice
; Statement (CPS) и объектный идентификатор политики
[AllIssuancePolicy]
URL = http://cdp.contoso.com/pki/contoso-cps.html
OID = 2.5.29.32.0
[BasicConstraintsExtension]
IsCA = True
PathLegth = 0
IsCritical = True
; секция прочих настроек ЦС
[certsrv_server]
; отключаем автоматическую загрузку шаблонов сертификатов для выдачи
LoadDefaultTemplates = 0
Файл с именем CAPolicy.inf необходимо скопировать в системную папку Windows до установки ЦС.
Установка компонента ЦС
Прежде всего необходимо добавить установочные компоненты для AD CS:
Install-WindowsFeature AD-Certificate, ADCS-Cert-Authority -IncludeManagementTools
После этого посмотрим на установочную таблицу, чтобы определить параметры установки:
В таблице я выделил только те параметры, которые задаются в процессе установки. Остальные параметры будут настраиваться после установки. Исходя из этих данных сформируем параметры для командлета 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. Но прежде всего посмотрим установочную таблицу и выясним параметры, которые нам необходимо настроить:
Аналогичная таблица составляется и для издающего ЦС.
За основу мы возьмём скрипт с корневого ЦС и изменим только отдельные фрагменты:
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: 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 установлена верно.
Creating the certificates
Expand the Roles tree and select Certificate Templates in the left pane.
Depending on your environment, you may select 2003 or 2008. For simplicity sake, I have selected 2003. Click OK.
Again, 2048 is the smallest recommended length. You can always go stronger but remember that the longer the key is, the bigger the impact of performance.
Another thing that you have to think about at this point is whether or not you want this certificate to be exportable. The recommended setting is to not allow an export. Deselect Allow private key to be exported and click the Security tab at the top.
Now we will need to make this new template available to be deployed. In the Server Manager, right click on Certificate Templates under the CA server name, select New, and Certificate Template to Issue.
Ensure that the certificate is present under the Certificate Templates.
The steps are basically the same for creating the computer cert. Select Certificate Templates on the left above the server name in the left pane of the Server Manager.
This time we will right click the Computer template, select All Tasks, and then Duplicate Template.
Again, choose whether you will be utilizing 2003 or 2008. Click OK.
Give the computer cert a meaningful name such as “CompanyName Computer Cert” and select the Request Handling tab.
Ensure that the key length is at least 2048 and that it cannot be exported. Select the Security tab.
Since these are the computer certificates, select Domain Computers in the top, check the permissions for Enroll and Autoenroll at the bottom, and click OK.
Perform the same steps to make the computer certificate available to deploy by right clicking Certificate Templates under the server name, selecting New and Certificate Template to Issue.
Select the certificate you just created and click OK.
Ensure that the certificate is now available in the Certificate Templates.
Summary
As always, if there are any questions please leave a comment below. I would love you hear from you. Until then, thanks for reading!
Установка корневого ЦС
Фактическая установка ЦС будет включать в себя несколько этапов:
- Подготовка предустановочных конфигурационных файлов (CAPolicy.inf);
- Установка компонента ЦС;
- Выполнение постустановочной конфигурации;
- Проверка установки.
Перед установкой корневого ЦС, необходимо ещё раз вернуться к конфигурационным таблицам:
В таблице я выделил только те параметры, которые задаются до и в процессе установки. Остальные параметры будут настраиваться после установки.
Предварительная конфигурация
Предварительные конфигурационные файлы необходимы для ряда настроек, которые невозможно задать во время установки компонента (ни при помощи графического интерфейса, ни при помощи командной строки или PowerShell). К ним обычно относятся настройки расширений сертификата ЦС. Например, для настройки расширения сертификата Certificate Policies, необходимо использовать предварительный конфигурационный файл, в котором настраиваются параметры расширения. Для Microsoft ADCS таким файлом является файл CAPolicy.inf, который должен быть расположен по следующему пути: %windir%\CAPolicy.inf. С синтаксисом этого файла можно ознакомиться в следующей статье: How CA Certificates Work. Поскольку никаких специфичных или нестандартных настроек в сертификате корневого ЦС мы делать не будем, поэтому и предварительный конфигурационный файл сейчас нам не потребуется.
Установка компонента ЦС
Прежде всего необходимо добавить установочные компоненты для AD CS:
Install-WindowsFeature AD-Certificate, ADCS-Cert-Authority -IncludeManagementTools
После этого сверьтесь с предыдущей таблицей, чтобы определить параметры установки. Исходя из данных таблицы, зададим параметры для командлета 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")
Итоговая настройка
После установки компонента ЦС необходимо настроить рабочие параметры ЦС. Рассмотрим ещё раз элементы, которые нам необходимо настроить:
* — копируется на сервер 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 приведено в следующей таблице:
Если взять путь для 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 является служебным символом. Сервер ЦС так же использует знак процента для указания, что это переменная. Для исключения конфликта в командном процессоре используется последовательность из двух знаков процента.
Следующая таблица содержит описание всех доступных переменных и их краткое описание:
В нашем конкретном случае будут использоваться только две переменные: <CertificateName> и <CRLNameSuffix>. Для исходного сертификата ЦС эти переменные пустые. При обновлении сертификата ЦС, переменная будет заменяться на «(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
Подготовка веб-сервера
На веб-сервере нам потребуется выполнить следующее: установить службу 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
Import-Module -Name WebAdministration
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter /system.webServer/security/requestFiltering -name allowdoubleescaping -Value 'true'
Рекомендации
После того, как все ЦС установлены, сконфигурированы и их работоспособность проверена, можно приступать к их эксплуатации. В этом разделе я дам несколько полезных рекомендаций, которых следует придерживаться, чтобы предостеречь себя от возможных потенциальных проблем во время эксплуатации 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 отмечены такие проблемы. Примеры статей:
При генерации новой ключевой пары для каждого сертификата будет гарантирован только один путь к корневому сертификату и модуль построения цепочек сертификатов уже не ошибётся.
Резервное копирование
Вопросы резервного копирования и восстановления после отказа являются отдельной темой. Здесь я лишь отмечу основные моменты, которые следует учесть при планировании стратегии резервного копирования.
Microsoft Active Directory Certificate Services предоставляет инструменты для резервного копирования компонентов ЦС:
- Оснастка Certification Authority MMC (certsrv.msc);
- Утилита certutil.exe с параметром -backup.
С ними можно сделать резервную копию для ключевой пары ЦС и базы данных. Однако эти инструменты не позволяют делать резервную копию настроек ЦС. Эти операции необходимо выполнять вручную. Все настройки ЦС находятся в реестре по следующему пути:
HKLM\System\CurrentControlSet\Services\CertSvc
При резервном копировании всегда экспортируйте данную ветку реестра. При восстановлении ЦС сохранённый REG файл импортируется обратно в реестр после установки роли ЦС.
Полный список элементов ЦС, который подлежит обязательному резервному копированию выглядит так:
- Ключи и сертификаты ЦС;
- База данных ЦС;
- Настройки ЦС из реестра;
- Предустановочный конфигурационный файл;
- Установочные и конфигурационные скрипты.
Этот список не зависит от принятой в вашей компании стратегии резервного копирования, он всегда должен быть включён в список резервных копий.
Certificate Authority Server setup
The first thing we’ll need to do in order to create the CA is to add the Active Directory Certificate Services Role. To accomplish this go to Start, right-click on Computer and select Manage.
Click on the Roles tree in the left panel and Add Roles on the right.
Tick the checkbox next to Active Directory Certificate Services and click Next.
This next dialog box is just some information about certificate services and how to get further help. Click Next.
This is the first, and in this case only, CA we will be deploying so check the Certificate Authority box and then Next.
Here we can select if we want to use Enterprise or Standard. In order to take advantage of all of the features Active Directory has to offer, select Enterprise and click Next.
Again, this is our first and only CA so select the Root CA radio button and click Next.
There are some cases in which you would want to use an existing private key such as an upgrade or migration. However, because this is a how to, select Create a new private key and click Next.
This next dialog box is where we can select the strength and hash algorithm of the private key. 2048 is the lowest recommended setting for character length. When you decide how secure you want the key to be, click Next.
Unless there is a specific reason to change this information, leave it default and click Next.
Selecting the length of time the CA certificate is valid is a company set policy. For the sake of this tutorial, I will leave it at five years. Click Next.
This is another screen that you should keep at the defaults unless there is a specific reason to change it. Click Next.
The next dialog box gives information about the installation that is about to take place and lets us verify everything. It also gives a nice little warning that you cannot change the CA name after the role has been installed. Once you have verified, click Install.
The role will then begin installation. Depending on your server specifications, this shouldn’t take long at all.
Once finished, the Installation Results will pop up and hopefully will read Installation succeeded at which point the basic CA installation has been completed.
Об авторе
Вадим Поданс — специалист в области автоматизации PowerShell и Public Key Infrastructure, Microsoft MVP: Cloud and Datacenter Management с 2009 года и автор модуля PowerShell PKI. На протяжении 9 лет в своём блоге освещает различные вопросы эксплуатации и автоматизации PKI на предприятии. Статьи Вадима о PKI и PowerShell можно найти на его сайте.