Для чего вообще городить отдельный Offline Root CA?

Корневой ключ — это фундамент доверия всей PKI. Если Issuing CA взломают, достаточно отозвать его сертификат и поднять новый. Если уйдёт ключ корня — пересоздаём всю иерархию и выкидываем корневой сертификат из доверенных на каждом устройстве. Поэтому корень должен жить в выключенной машине.

Можно ли поставить роль CA прямо на контроллер домена?

Технически можно, на деле — не советую. CA накрепко привязывается к имени сервера, и понизить такой DC вы уже не сможете. В малом офисе до 80 машин бывает, что это решение оправдано экономией, но всегда проговариваю с заказчиком риски.

Как перевыпустить сертификат Issuing CA, если он скоро истечёт?

За полгода до истечения включаем Root CA, запускаем certutil -renewcert либо правый клик по ЦС в certsrv.msc → Renew CA Certificate. Решаем, генерировать ли новую пару ключей. Запрос подписываем на корне, новый сертификат ставим на Issuing CA и публикуем свежий CRL.

Как быстро отозвать скомпрометированный сертификат?

В consolec certsrv.msc заходим в Issued Certificates, находим запись, Revoke Certificate с указанием причины (Key Compromise, CA Compromise и т.п.). Сразу публикуем CRL: certutil -CRL. Клиенты подхватят обновление при следующей проверке — от секунд до часа в зависимости от кэшей.

Выпускает ли AD CS wildcard-сертификаты?

Да, но ручками. Берём шаблон Web Server, дублируем, на вкладке Subject Name включаем Supply in the request. В CSR указываем CN=*.itfresh.ru. Права на шаблон обязательно ужимаем до группы админов — иначе любой с правом Enroll выпустит себе wildcard.

Active Directory 11 июля 2025 · 17 мин чтения

Корпоративный PKI на AD CS: собираем двухуровневую иерархию без сюрпризов

Семёнов Евгений Сергеевич, директор АйТи Фреш. Лет за пятнадцать я насмотрелся на все виды самодельных «центров сертификации»: от самоподписанных сертов OpenSSL на одном веб-сервере до разваливающегося AD FS с кучей самоподписанных токенов. Однажды в 2024 пришёл клиент — у них корпоративный PKI жил на контроллере домена, а CRL протух ещё в 2022. Когда такая конструкция падает, она тянет за собой Wi-Fi, VPN, почту и веб-порталы. Поэтому расскажу, как это делать нормально.

Зачем офису собственный удостоверяющий центр

Закупать коммерческие сертификаты на каждый внутренний сервис — дорого и неудобно. AD CS решает этот вопрос раз и навсегда, потому что корневой сертификат автоматически расползается по доменным машинам через групповые политики. Браузер у сотрудника перестаёт орать про «сертификат не является доверенным», а вы получаете инструмент для целой серии задач.

TLS для внутренних порталов, 1С-веб, Confluence, Bitrix24-портала и прочего, что торчит на корпоративных адресах.
Аутентификация по смарт-картам и token-ам, EAP-TLS для Wi-Fi 802.1X.
S/MIME для корпоративной почты — подписание и шифрование.
Подпись PowerShell-скриптов, которые уходят через GPO, и MSI-пакетов.
IPsec между филиалами, сертификаты для OpenVPN/AnyConnect.

Роль AD CS входит в базовую лицензию Windows Server Standard, клиентских CAL не требует. То есть финансово всё, что вам стоит — время на правильную настройку.

Двухуровневая архитектура: как и почему

Рекомендую схему: один Standalone Root CA в режиме офлайн плюс один-два Enterprise Issuing CA в домене. Root подписывает только сертификаты подчинённых и свой собственный CRL раз в полгода-год. Остальные 99% времени он стоит выключенным, виртуальный диск лежит в сейфе.

Уровень	Роль	Ключ	Срок
Root CA	Standalone, не в домене	RSA 4096, SHA256	15–20 лет
Issuing CA	Enterprise, в домене	RSA 2048/4096, SHA256	5–10 лет
Конечные сертификаты	Пользователи, компьютеры, сервисы	RSA 2048, SHA256	1–2 года

Офлайн Root CA — файл CAPolicy.inf и установка

Root CA — это виртуалка Windows Server 2019/2022 без присоединения к домену, 2 vCPU, 4 ГБ RAM, 60 ГБ диск. До первого включения заливаем файл C:\Windows\CAPolicy.inf:

[Version]
Signature="$Windows NT$"

[Certsrv_Server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
CRLPeriod=Weeks
CRLPeriodUnits=26
CRLDeltaPeriod=Days
CRLDeltaPeriodUnits=0
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=0

Дальше ставим роль и конфигурируем:

Install-WindowsFeature AD-Certificate -IncludeManagementTools

Install-AdcsCertificationAuthority `
  -CAType StandaloneRootCA `
  -CACommonName "ITFresh Root CA" `
  -KeyLength 4096 -HashAlgorithmName SHA256 `
  -ValidityPeriod Years -ValidityPeriodUnits 20 `
  -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" -Force

# Куда публиковать CRL и AIA
certutil -setreg CA\CRLPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%3%8.crl\n2:http://pki.itfresh.ru/CertEnroll/%3%8.crl"
certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%3%4.crt\n2:http://pki.itfresh.ru/CertEnroll/%3%4.crt"
Restart-Service certsvc
certutil -crl

Результат — CRL, .crt-файл и cert-запрос от Issuing CA. Всё это уходит на флешке в сторону Issuing. После — виртуальный сетевой адаптер отстёгиваем, машину выключаем, снепшот кладём в два разных места.

Enterprise Issuing CA внутри домена

Issuing ставим на доменный сервер — 4 vCPU, 8 ГБ RAM, 100 ГБ SSD. На проекте у клиента в Мытищах в 2025 году для 90 рабочих мест разместил Issuing на той же ESXi-хост, где живёт второй DC, но в отдельной виртуалке.

Install-WindowsFeature AD-Certificate, ADCS-Cert-Authority, ADCS-Web-Enrollment `
  -IncludeManagementTools

Install-AdcsCertificationAuthority `
  -CAType EnterpriseSubordinateCA `
  -CACommonName "ITFresh Issuing CA 01" `
  -KeyLength 4096 -HashAlgorithmName SHA256 `
  -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
  -OutputCertRequestFile "C:\Install\Issuing01.req" -Force

Запрос .req везём на Root, подписываем, возвращаем .cer и ставим обратно:

# На Root
certreq -submit "C:\Install\Issuing01.req"
# Одобряем в certsrv.msc → Pending, экспортируем в .cer

# На Issuing
certutil -installcert "C:\Install\Issuing01.cer"
Start-Service certsvc

# Публикация CRL и веб-регистрация
Install-AdcsWebEnrollment -Confirm:$false

Отдельным шагом надо поднять IIS-сайт pki.itfresh.ru, который раздаёт CRL и корневой сертификат, причём обязательно разрешить double escaping — иначе файлы с плюсом в имени посыплются на 404.

New-WebVirtualDirectory -Site "Default Web Site" `
  -Name "CertEnroll" `
  -PhysicalPath "C:\Windows\System32\CertSrv\CertEnroll"

Set-WebConfigurationProperty -PSPath 'IIS:\Sites\Default Web Site\CertEnroll' `
  -Filter system.webServer/security/requestFiltering `
  -Name allowDoubleEscaping -Value $true

Шаблоны: без них Enterprise CA не раскроется

Важное правило, которое я набил на практике: встроенные шаблоны не использую никогда. Любой шаблон — дубликат с чётким именем «ITFresh-...» и своими правами. Поменять встроенный Web Server потом бесконечно сложно, а дубликат выкинуть и пересоздать — дело пяти минут.

Открываем certtmpl.msc.
На нужном шаблоне (Web Server, Computer, User, RAS and IAS Server, Code Signing) правый клик → Duplicate Template.
General: имя «ITFresh-Computer-2025», срок 2 года, галка Publish certificate in AD.
Subject Name: для компьютеров — Build from AD → DNS Name, для пользователей — Common Name + UPN.
Security: убираем Authenticated Users, добавляем нужную группу с Read + Enroll + Autoenroll (последнее только для авто-шаблонов).

Публикуем шаблон на CA:

Add-CATemplate -Name "ITFresh-Computer-2025" -Force
Add-CATemplate -Name "ITFresh-WebServer-2025" -Force
Get-CATemplate

Автоэнроллмент через GPO

Вся магия Enterprise CA — в автоматической выдаче. Один раз настроенный шаблон и правильная политика делают так, что новый компьютер получает сертификат в момент ввода в домен. Создаём GPO «ITFresh-PKI-Autoenroll» и привязываем к OU с компьютерами.

Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Certificate Services Client - Auto-Enrollment: Enabled, обе галки (обновление истекающих, обновление по шаблонам).
Аналогично для User Configuration, если нужны пользовательские сертификаты.

# Проверка на клиенте
gpupdate /force
certutil -pulse
certutil -store -silent My

Реальный кейс: холдинг в Одинцово

Март 2025, холдинг из трёх юрлиц, общий домен, 160 рабочих мест. Пришли с задачей: избавиться от предупреждений браузера на внутреннем сайте закупок, перевести Wi-Fi на сертификаты и подписать пачку PowerShell-скриптов для GPO. До нас у них всё держалось на одном CA, прикрученном к единственному контроллеру домена, сертификат Root истёк через полтора года.

Развернули за пять рабочих дней: Offline Root 4096, Issuing 4096, шаблоны Web Server/Computer/Code Signing/RAS-IAS, IIS на pki.domain.ru с правильным CDP, RADIUS на NPS для двух точек доступа Mikrotik. В первую неделю после переезда — два тикета про «не подключается к Wi-Fi», оба лечатся пересозданием профиля на ноутбуке. Стоимость — 142 000 рублей вместе с документацией и передачей админу. Через 15 месяцев клиент вернулся за расширением PKI на филиал в Тверской области — это лучший показатель.

Публикация CRL, AIA и OCSP

Самая обидная и частая поломка — не настроенный или забытый CDP. Когда клиент получает сертификат, он идёт по URL из расширения CRL Distribution Point. Если URL не открывается — сертификат отвергается. Поэтому в списке CDP у Issuing всегда должно быть минимум два пункта: LDAP и HTTP.

$cdp = @(
  "1:C:\Windows\System32\CertSrv\CertEnroll\%3%8%9.crl",
  "2:http://pki.itfresh.ru/CertEnroll/%3%8%9.crl",
  "10:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10"
)
certutil -setreg CA\CRLPublicationURLs ($cdp -join "`n")

$aia = @(
  "1:C:\Windows\System32\CertSrv\CertEnroll\%1_%3%4.crt",
  "2:http://pki.itfresh.ru/CertEnroll/%1_%3%4.crt",
  "32:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11"
)
certutil -setreg CA\CACertPublicationURLs ($aia -join "`n")
Restart-Service certsvc
certutil -crl

Для инфраструктур от 300 устройств добавляю OCSP Online Responder — он проверяет конкретный сертификат за миллисекунды без скачивания полного CRL.

Обслуживание и регулярные задачи

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

Раз в неделю — мониторинг места на базе CA (NTDS.dit-подобная) и очереди Pending.
Раз в месяц — тестовая выдача на чистой VM, проверка цепочки через certutil -verify -urlfetch file.cer.
Раз в квартал — включаем Root CA, публикуем новый CRL, выкладываем на pki-сайт.
Раз в полгода — аудит выпущенных сертификатов, отзыв забытых уволенных учёток.
Раз в 5 лет — перевыпуск сертификата Issuing до окончания срока, с запасом в полгода.

Backup-CARoleService -Path "D:\Backups\CA-$(Get-Date -Format yyyyMMdd)" `
  -Password (ConvertTo-SecureString "S3cureBackup!" -AsPlainText -Force)

Поднимем и поддержим корпоративный PKI

Проектирую и разворачиваю AD CS с нуля, перевожу самопальные CA на нормальную двухуровневую схему, настраиваю автоэнроллмент, RADIUS для Wi-Fi, мониторинг CRL и регламент обслуживания. Офис до 200 ПК — в пять-десять рабочих дней. Бесплатный аудит существующей PKI — за два часа на месте или удалённо.

Телефон: +7 903 729-62-41
Telegram: @ITfresh_Boss
Семёнов Евгений Сергеевич, директор АйТи Фреш

FAQ — частые вопросы по AD Certificate Services

Для чего вообще городить отдельный Offline Root CA?: Корневой ключ — это фундамент доверия всей PKI. Если Issuing CA взломают, достаточно отозвать его сертификат и поднять новый. Если уйдёт ключ корня — пересоздаём всю иерархию и выкидываем корневой сертификат из доверенных на каждом устройстве. Поэтому корень должен жить в выключенной машине.
Можно ли поставить роль CA прямо на контроллер домена?: Технически можно, на деле — не советую. CA накрепко привязывается к имени сервера, и понизить такой DC вы уже не сможете. В малом офисе до 80 машин бывает, что это решение оправдано экономией, но всегда проговариваю с заказчиком риски.
Как перевыпустить сертификат Issuing CA, если он скоро истечёт?: За полгода до истечения включаем Root CA, запускаем certutil -renewcert либо правый клик по ЦС в certsrv.msc → Renew CA Certificate. Решаем, генерировать ли новую пару ключей. Запрос подписываем на корне, новый сертификат ставим на Issuing CA и публикуем свежий CRL.
Как быстро отозвать скомпрометированный сертификат?: В консоли certsrv.msc заходим в Issued Certificates, находим запись, Revoke Certificate с указанием причины (Key Compromise, CA Compromise и т. п.). Сразу публикуем CRL: certutil -CRL. Клиенты подхватят обновление при следующей проверке.
Выпускает ли AD CS wildcard-сертификаты?: Да, но ручками. Берём шаблон Web Server, дублируем, на вкладке Subject Name включаем Supply in the request. В CSR указываем CN=*.itfresh.ru. Права на шаблон обязательно ужимаем до группы админов — иначе любой с правом Enroll выпустит себе wildcard.