Корпоративный 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.