Active Directory Certificate Services: как развернуть PKI в Windows Server?

Инфраструктура открытых ключей (PKI) лежит в основе безопасности корпоративной сети: шифрование трафика, аутентификация по сертификатам, подпись кода и защита электронной почты. В экосистеме Microsoft роль центра сертификации выполняет компонент Active Directory Certificate Services (AD CS). Несмотря на встроенную интеграцию с Active Directory, развёртывание PKI вызывает массу вопросов — от выбора архитектуры до отладки автоэнроллмента. В этом руководстве мы разберём установку корневого и подчинённого центра сертификации, настройку шаблонов, автоматическую выдачу сертификатов через GPO, управление отзывом и типичные ошибки, которые встречаются в продакшене. Материал рассчитан на системных администраторов, работающих с Windows Server 2019/2022 и PowerShell, и содержит готовые команды для каждого этапа.

Что такое AD CS и зачем нужен собственный центр сертификации?

Active Directory Certificate Services — это серверная роль Windows Server, реализующая стандарты X.509 и позволяющая организации выпускать, управлять и отзывать цифровые сертификаты. Зачем разворачивать собственный CA вместо покупки сертификатов у внешнего удостоверяющего центра? Во-первых, внутренний CA позволяет выпускать неограниченное количество сертификатов без затрат на каждый из них. Во-вторых, корпоративный CA (Enterprise CA), интегрированный с Active Directory, поддерживает автоматическую выдачу сертификатов компьютерам и пользователям домена через механизм автоэнроллмента. В-третьих, вы получаете полный контроль над жизненным циклом сертификатов: политиками выдачи, сроками действия, алгоритмами шифрования и списками отзыва (CRL). Документация Microsoft по AD CS Overview описывает полный набор возможностей.

Как выбрать архитектуру PKI: одноуровневая или двухуровневая?

Перед установкой необходимо определиться с иерархией центров сертификации. В простейшем случае разворачивается единственный корневой CA (Root CA), который одновременно выпускает сертификаты конечным потребителям. Такая одноуровневая схема подходит для тестовых сред и небольших организаций до 100 рабочих станций. Корневой сертификат хранится на том же сервере, что обслуживает запросы, и компрометация этого сервера приведёт к полному краху всей PKI. Двухуровневая архитектура предполагает отдельный офлайн Root CA, который выпускает сертификат для подчинённого Subordinate (Issuing) CA. Корневой сервер после этого выключается и хранится в сейфе (или как виртуальная машина на зашифрованном носителе). Все рабочие запросы обрабатывает Issuing CA. При компрометации подчинённого CA его сертификат отзывается корневым, а инфраструктура остаётся работоспособной. Для продакшена рекомендуется именно двухуровневая модель, описанная в документации Microsoft по ролям CA.

Как установить роль AD CS на Windows Server через PowerShell?

Установка роли выполняется в два этапа: добавление компонентов и конфигурирование CA. На сервере, который станет Enterprise Issuing CA, откройте PowerShell с правами администратора и выполните следующие команды для установки роли, веб-интерфейса регистрации и средств управления:

# Установка роли AD CS с компонентами
Install-WindowsFeature AD-Certificate -IncludeManagementTools
Install-WindowsFeature ADCS-Cert-Authority
Install-WindowsFeature ADCS-Web-Enrollment
Install-WindowsFeature ADCS-Enroll-Web-Pol

После установки компонентов необходимо сконфигурировать центр сертификации. Для Enterprise Subordinate CA (подчинённого корпоративного CA) команда выглядит так:

# Конфигурирование Enterprise Subordinate CA
Install-AdcsCertificationAuthority `
    -CAType EnterpriseSubordinateCA `
    -CACommonName "Corp-Issuing-CA" `
    -KeyLength 4096 `
    -HashAlgorithmName SHA256 `
    -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
    -ValidityPeriod Years `
    -ValidityPeriodUnits 5 `
    -Force

Если вы разворачиваете одноуровневую схему с единственным корневым CA, замените EnterpriseSubordinateCA на EnterpriseRootCA и укажите -ValidityPeriodUnits 10 (корневой сертификат обычно выпускается на более длительный срок). После конфигурирования служба CertSvc запускается автоматически. Проверить её статус можно командой Get-Service CertSvc. Аналогичную настройку можно выполнить через Server Manager, но PowerShell позволяет автоматизировать процесс и воспроизводить его в любой среде.

Как настроить шаблоны сертификатов для разных сценариев?

Шаблоны сертификатов (Certificate Templates) определяют параметры выпускаемого сертификата: назначение, срок действия, алгоритм, минимальную длину ключа и права доступа. По умолчанию AD CS поставляется с набором стандартных шаблонов, однако для продакшена следует создавать собственные. Управление шаблонами выполняется через оснастку certtmpl.msc или через PowerShell-модуль ADCSTemplate. Процедура создания шаблона для веб-сервера с расширенными параметрами:

# Просмотр списка доступных шаблонов
certutil -CATemplates

# Публикация шаблона на CA (после создания в certtmpl.msc)
Add-CATemplate -Name "WebServerCustom" -Force

# Просмотр шаблонов, опубликованных на CA
Get-CATemplate | Format-Table Name, Oid

При создании кастомного шаблона в оснастке certtmpl.msc дублируйте существующий шаблон Web Server, откройте его свойства и измените следующие параметры: на вкладке General задайте имя и срок действия (рекомендуется 1-2 года для веб-серверов); на вкладке Cryptography выберите RSA с длиной ключа 2048 или 4096 бит; на вкладке Security добавьте группу серверов с правами Read, Enroll и Autoenroll; на вкладке Extensions в Application Policies оставьте Server Authentication. После сохранения шаблона не забудьте опубликовать его на CA командой Add-CATemplate. Для сертификатов аутентификации пользователей и компьютеров также понадобятся отдельные шаблоны, аналогичную настройку можно выполнить через GPO.

Как включить автоэнроллмент сертификатов через групповые политики?

Автоэнроллмент — одно из ключевых преимуществ Enterprise CA перед Standalone CA. Этот механизм позволяет автоматически выпускать и обновлять сертификаты для компьютеров и пользователей домена без участия администратора. Настройка состоит из двух шагов: подготовка шаблона (мы рассмотрели выше) и создание GPO. Откройте Group Policy Management (gpmc.msc), создайте новую политику и перейдите в раздел:

# Путь для компьютеров:
Computer Configuration → Policies → Windows Settings →
  Security Settings → Public Key Policies →
  Certificate Services Client - Auto-Enrollment

# Путь для пользователей:
User Configuration → Policies → Windows Settings →
  Security Settings → Public Key Policies →
  Certificate Services Client - Auto-Enrollment

В свойствах Auto-Enrollment установите Configuration Model в значение Enabled, отметьте флажки Renew expired certificates, update pending certificates, and remove revoked certificates и Update certificates that use certificate templates. Привяжите GPO к нужному OU и выполните на клиентах gpupdate /force. После обновления политик клиент обратится к CA, найдёт шаблоны, на которые у него есть права Autoenroll, и автоматически запросит сертификат. Проверить результат можно в оснастке certlm.msc (для компьютера) или certmgr.msc (для пользователя). Если сертификат не появился, смотрите логи в Event Viewer в разделе Applications and Services Logs → Microsoft → Windows → CertificateServicesClient-Lifecycle-System.

Как выпустить сертификат вручную через PowerShell и certreq?

Не все сценарии покрываются автоэнроллментом. Для Linux-серверов, сетевого оборудования или изолированных систем сертификат запрашивается вручную. Процесс состоит из создания запроса (CSR), отправки его на CA, одобрения и установки. PowerShell и встроенная утилита certreq позволяют автоматизировать каждый шаг:

# 1. Создание INF-файла для запроса
$inf = @"
[NewRequest]
Subject = "CN=web01.corp.local"
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
RequestType = PKCS10
[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.1 ; Server Authentication
[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=web01.corp.local&"
_continue_ = "dns=web01&"
"@
$inf | Out-File C:\Temp\web01.inf -Encoding ASCII

# 2. Генерация CSR
certreq -new C:\Temp\web01.inf C:\Temp\web01.req

# 3. Отправка запроса на CA
certreq -submit -config "CA-SERVER\Corp-Issuing-CA" `
    C:\Temp\web01.req C:\Temp\web01.cer

# 4. Установка сертификата
certreq -accept C:\Temp\web01.cer

Если на CA настроено ручное одобрение (Manager Approval), после шага 3 запрос окажется в очереди Pending Requests. Администратор CA должен одобрить его в оснастке certsrv.msc или командой certutil -resubmit <RequestID>. Для массовой выдачи сертификатов удобно использовать PowerShell-скрипт, который перебирает список серверов, генерирует INF-файлы и отправляет запросы. Об управлении серверами через PowerShell можно также прочитать в нашей статье про управление модулями PowerShell.

Как настроить списки отзыва сертификатов (CRL и OCSP)?

Каждый выпущенный сертификат может быть отозван до истечения срока действия — при компрометации закрытого ключа, увольнении сотрудника или выводе сервера из эксплуатации. Клиенты проверяют статус сертификата двумя способами: через список отзыва (Certificate Revocation List, CRL) или через протокол OCSP (Online Certificate Status Protocol, RFC 6960). CRL представляет собой подписанный файл со списком серийных номеров отозванных сертификатов. CA публикует Base CRL и Delta CRL с определёнными интервалами. Для настройки параметров публикации используется утилита certutil:

# Просмотр текущих настроек CRL
certutil -getreg CA\CRLPeriod
certutil -getreg CA\CRLPeriodUnits
certutil -getreg CA\CRLDeltaPeriod
certutil -getreg CA\CRLDeltaPeriodUnits

# Изменение интервала публикации Base CRL (7 дней)
certutil -setreg CA\CRLPeriodUnits 7
certutil -setreg CA\CRLPeriod "Days"

# Изменение интервала Delta CRL (1 день)
certutil -setreg CA\CRLDeltaPeriodUnits 1
certutil -setreg CA\CRLDeltaPeriod "Days"

# Перезапуск службы для применения
Restart-Service CertSvc

# Принудительная публикация CRL
certutil -CRL

OCSP-ответчик устанавливается как дополнительная роль AD CS (Online Responder). Его преимущество — клиент получает ответ о статусе конкретного сертификата, а не скачивает весь CRL. Это критически важно для крупных организаций с десятками тысяч сертификатов, где Base CRL может достигать мегабайтов. Точки распространения CRL (CDP) и OCSP-адреса прописываются в расширениях сертификата CA. При первоначальной настройке CA убедитесь, что CDP-адреса доступны для всех клиентов — как внутренних, так и внешних (если сертификаты используются для публичных сервисов).

Как мониторить срок действия сертификатов через PowerShell?

Просроченный сертификат может привести к отказу сервиса — от невозможности подключения к RDP до неработающего веб-приложения. Автоматический мониторинг сроков действия — обязательная практика для зрелой PKI-инфраструктуры. PowerShell позволяет опросить как локальное хранилище сертификатов, так и базу данных CA. Скрипт для проверки сертификатов, истекающих в ближайшие 30 дней:

# Сертификаты на локальном компьютере, истекающие в 30 дней
$threshold = (Get-Date).AddDays(30)
Get-ChildItem Cert:\LocalMachine\My |
    Where-Object { $_.NotAfter -lt $threshold -and $_.NotAfter -gt (Get-Date) } |
    Select-Object Subject, Thumbprint, NotAfter |
    Sort-Object NotAfter

# Все выданные сертификаты с CA (для администратора CA)
Get-IssuedRequest -CertificationAuthority "CA-SERVER\Corp-Issuing-CA" |
    Where-Object { $_.NotAfter -lt $threshold } |
    Select-Object CommonName, NotAfter, CertificateTemplate

# Быстрая проверка конкретного сервера (удалённо)
$cert = [System.Net.Security.RemoteCertificateValidationCallback]{$true}
$tcp = New-Object System.Net.Sockets.TcpClient("web01.corp.local", 443)
$ssl = New-Object System.Net.Security.SslStream($tcp.GetStream(), $false, $cert)
$ssl.AuthenticateAsClient("web01.corp.local")
$ssl.RemoteCertificate | Select Subject, Issuer,
    @{N='Expires';E={$_.GetExpirationDateString()}}
$ssl.Close(); $tcp.Close()

Для автоматизации рекомендуется создать задание в Task Scheduler, которое запускает скрипт мониторинга ежедневно и отправляет отчёт по электронной почте. Подробнее о настройке планировщика через PowerShell — в нашей статье Task Scheduler и PowerShell. Также полезно настроить мониторинг через SSL, что мы описывали в материале про мониторинг SSL-сертификатов.

Как создать резервную копию центра сертификации?

Потеря базы данных CA без резервной копии — катастрофа, восстановление которой потребует перевыпуска всех сертификатов в организации. Бэкап CA включает базу данных, закрытый ключ и конфигурацию. Утилита certutil предоставляет встроенные средства резервного копирования, а PowerShell позволяет автоматизировать процесс:

# Резервная копия базы данных и закрытого ключа CA
Backup-CARoleService -Path "D:\CABackup" -Password (
    ConvertTo-SecureString "ComplexP@ssw0rd!" -AsPlainText -Force
) -DatabaseOnly

# Альтернативный способ через certutil
certutil -backup D:\CABackup
# (запросит пароль для защиты закрытого ключа)

# Бэкап реестра CA
reg export "HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration" `
    D:\CABackup\CA-Registry.reg

# Список шаблонов CA (для документирования)
certutil -CATemplates > D:\CABackup\Templates.txt

Рекомендуется выполнять бэкап минимум раз в неделю для Issuing CA и после каждого изменения конфигурации. Для автоматизации создайте scheduled task с PowerShell-скриптом. Информация о Windows Server Backup доступна в нашей статье про wbadmin и резервное копирование.

Что делать если появляются ошибки при запросе сертификата?

Проблемы с выдачей сертификатов — одна из самых частых задач администратора PKI. Разберём типичные ошибки и их решения. Ошибка "The RPC server is unavailable" (0x800706ba) означает, что клиент не может связаться с CA. Проверьте сетевое подключение и работу службы CertSvc на сервере CA. Ошибка "The certificate template is not supported by this CA" (0x80094800) указывает на то, что шаблон не опубликован на CA — выполните Add-CATemplate -Name "TemplateName". Ошибка "Denied by Policy Module" (0x80094012) обычно связана с недостаточными правами — проверьте ACL шаблона в certtmpl.msc.

# Диагностика: проверка доступности CA
certutil -ping
certutil -config "CA-SERVER\Corp-Issuing-CA" -ping

# Просмотр очереди отклонённых запросов
certutil -view -restrict "Disposition=31" -out "RequestID,CommonName,StatusCode"

# Проверка прав на шаблон
$template = [ADSI]"LDAP://CN=WebServerCustom,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=local"
$template.psbase.ObjectSecurity.Access | Format-Table IdentityReference, AccessControlType, ActiveDirectoryRights

# Проверка автоэнроллмента на клиенте
certutil -pulse

При сложных проблемах включите расширенное логирование: certutil -setreg CA\LogLevel 5 на сервере CA. Логи будут записываться в %SystemRoot%\certsrv.log. Не забудьте вернуть уровень логирования после диагностики командой certutil -setreg CA\LogLevel 0. Также проверьте события в журнале Security на контроллере домена — для аудита запросов к AD может пригодиться наш материал о анализе журналов событий Windows.

Как защитить PKI-инфраструктуру от типичных атак?

PKI-инфраструктура — привлекательная цель для злоумышленников. Атака ESC1-ESC13 (Certified Pre-Owned) демонстрирует, как неправильно настроенные шаблоны позволяют рядовому пользователю получить сертификат доменного администратора. Для защиты необходимо следовать принципу наименьших привилегий при настройке шаблонов. Каждый шаблон должен иметь минимально необходимый набор EKU (Enhanced Key Usage), а права Enroll должны быть предоставлены только целевым группам. Отключите шаблоны, которые не используются, через Remove-CATemplate.

# Аудит опасных шаблонов (проверка на ESC1)
Get-CATemplate | ForEach-Object {
    $tpl = $_
    $dn = "CN=$($tpl.Name),CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=local"
    $obj = [ADSI]"LDAP://$dn"
    $flags = $obj.Properties["msPKI-Certificate-Name-Flag"].Value
    if ($flags -band 1) {
        Write-Warning "Template '$($tpl.Name)' allows ENROLLEE_SUPPLIES_SUBJECT — potential ESC1!"
    }
}

# Отключение неиспользуемых шаблонов
Remove-CATemplate -Name "SubCA" -Force
Remove-CATemplate -Name "SmartcardLogon" -Force

# Проверка SAN-флага (Subject Alternative Name)
certutil -v -template "WebServerCustom" | Select-String "msPKI-Certificate-Name-Flag"

Дополнительные меры: используйте HSM (Hardware Security Module) для хранения ключа Root CA в продакшене; включите аудит доступа к CA (события 4886, 4887, 4888 в журнале Security); регулярно проводите аудит шаблонов с помощью инструмента Certify или PSPKIAudit. Ограничьте сетевой доступ к CA — только порты RPC (135, 49152-65535) и HTTP (80/443 для CRL/OCSP). Используйте Windows Firewall с PowerShell для точной настройки правил.

Как перенести центр сертификации на новый сервер?

Миграция CA требуется при обновлении ОС, замене оборудования или реорганизации серверной инфраструктуры. Процесс включает экспорт базы данных и ключа на старом сервере, установку роли на новом и импорт данных. Критически важно сохранить то же имя CA (Common Name), иначе все выданные сертификаты станут невалидными.

# На старом сервере: экспорт
certutil -backup C:\CAMigration
# Сохраните пароль для закрытого ключа!

# Экспорт реестра
reg export "HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration" C:\CAMigration\caconfig.reg

# На новом сервере: установка роли (без конфигурирования!)
Install-WindowsFeature AD-Certificate -IncludeManagementTools
Install-WindowsFeature ADCS-Cert-Authority

# Восстановление из бэкапа
certutil -restore C:\CAMigration

# Импорт реестра
reg import C:\CAMigration\caconfig.reg

# Конфигурирование CA с существующим ключом
Install-AdcsCertificationAuthority `
    -CAType EnterpriseSubordinateCA `
    -CertFile C:\CAMigration\CA-SERVER.corp.local.p12 `
    -CertFilePassword (ConvertTo-SecureString "BackupP@ss" -AsPlainText -Force) `
    -Force

# Проверка
certutil -ping
certutil -CAInfo

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

Как управлять PKI в гибридной среде с Azure AD?

Современные организации всё чаще используют гибридную модель, где часть ресурсов находится в облаке Azure/Microsoft 365. В такой среде PKI должна обслуживать как on-premises ресурсы, так и облачные. Azure AD поддерживает аутентификацию по сертификатам (Certificate-Based Authentication, CBA), что позволяет использовать сертификаты, выпущенные внутренним CA, для входа в облачные сервисы Microsoft. Для этого необходимо опубликовать корневой сертификат CA в Azure AD через портал Entra (Azure AD) в разделе Security → Certificate authorities. Также нужно обеспечить доступность CRL и OCSP из интернета, что обычно реализуется через публикацию CDP на веб-сервере с внешним доменным именем. Для устройств, управляемых через Intune, сертификаты доставляются через SCEP-профиль или PKCS-профиль, интегрированный с NDES (Network Device Enrollment Service) — ещё одной ролью AD CS. Гибридная PKI требует тщательного планирования, но позволяет унифицировать аутентификацию и шифрование во всей инфраструктуре.