Active Directory Certificate Services: корпоративный PKI с нуля для офиса 50+ ПК

Привет! Я, Семёнов Евгений Сергеевич, директор АйТи Фреш. За 15 лет в администрировании корпоративных AD-инфраструктур мне довелось развернуть больше двух десятков PKI. Чего только не было: от двухсерверных схем для офисов всего на 30 рабочих мест до многоуровневых иерархий с HSM, обслуживающих 800-местные производства. И каждый раз я вижу одну и ту же картину: компании покупают коммерческие сертификаты для своих внутренних веб-серверов, страдают от предупреждений браузера на самоподписанных и вручную раздают Wi-Fi-пароли сотрудникам. А ведь всё это можно решить одной грамотно настроенной инфраструктурой Active Directory Certificate Services!

Что такое AD CS и зачем он среднему офису

Так вот, что такое Active Directory Certificate Services? Это, по сути, встроенная роль в Windows Server. Она позволяет буквально превратить ваш домен в свой собственный, полноценный удостоверяющий центр. И это очень удобно! Сертификаты, выпущенные таким CA, автоматически становятся доверенными для всех машин в домене. Больше никаких раздражающих всплывающих окон с сообщениями типа «Сертификат не доверенный»! Почему? Всё просто: корневой сертификат публикуется прямо в AD, а потом раздаётся всем компьютерам через групповые политики.

А зачем это среднему офису на 50 рабочих мест? Минимум для пяти задач:

• HTTPS на внутренних веб-сервисах — корпоративные порталы, 1С веб-клиент, Helpdesk-системы, Confluence без красного предупреждения в браузере.
• Wi-Fi WPA2-Enterprise / 802.1X — аутентификация пользователей по сертификату вместо общего пароля. Уволили сотрудника — отозвали сертификат, в общую сеть он не зайдёт.
• VPN с двухфакторной аутентификацией — RADIUS+EAP-TLS для OpenVPN, AnyConnect, Always-On VPN.
• S/MIME для почты — подпись и шифрование писем внутри организации без покупки сертификатов у Comodo/DigiCert.
• Code signing — подпись внутренних PowerShell-скриптов и MSI-пакетов для распространения через GPO.

Лицензионно AD CS входит в стоимость Windows Server Standard и отдельных CAL не требует. То есть если домен у вас уже есть — PKI вам не стоит ничего, кроме времени на настройку.

Двухуровневая иерархия — стандарт для корпоратива

Прежде чем вообще что-то начинать устанавливать, советую хорошенько подумать над архитектурой. Я лично всегда предпочитаю строить двухуровневую иерархию. Это значит, что у меня будет один офлайн корневой CA (мы его называем Root CA, или Standalone) и затем один-два подчинённых CA (это уже Issuing CA, Enterprise) прямо в домене. Такой подход даёт нам сразу три очень важных плюса:

• Корневой ключ хранится в выключенной виртуальной машине без сети — украсть его извне нельзя.
• Если подчинённый CA скомпрометирован — отзываете его сертификат корневым, поднимаете новый Issuing CA. Если бы CA был один, пришлось бы менять всю иерархию.
• Срок жизни корневого сертификата 15–20 лет, перевыпуск раз в десятилетие. Issuing CA — 5–10 лет, регулярная ротация.

Для офиса на 50 ПК этого хватает. Для крупных многосайтовых сетей советуют трёхуровневую схему с промежуточным Policy CA, но на наших масштабах это перебор.

Подготовка корневого CA: офлайн Standalone

Теперь о корневом CA. Это такая виртуальная машина, которая не должна быть присоединена к домену. Большую часть времени она вообще работает без сетевого подключения. И, конечно, обязательно сделайте её снэпшот, который нужно хранить сразу в нескольких надёжных местах. По минимальным требованиям: вам понадобится Windows Server 2019/2022 Standard, 2 vCPU, 4 ГБ RAM и диск на 60 ГБ. А имя машины я бы посоветовал выбрать что-то нейтральное, например, ROOTCA01, без всяких указаний домена в названии.

Установка роли через PowerShell:

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

Install-AdcsCertificationAuthority `
  -CAType StandaloneRootCA `
  -CACommonName "ITFresh Corporate Root CA" `
  -KeyLength 4096 `
  -HashAlgorithmName SHA256 `
  -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
  -ValidityPeriod Years -ValidityPeriodUnits 20 `
  -DatabaseDirectory "C:\Windows\System32\CertLog" `
  -LogDirectory "C:\Windows\System32\CertLog" `
  -Force

После установки правим CAPolicy.inf и реестр для правильных путей CRL/AIA, перезапускаем службу certsvc и публикуем CRL на длинный срок (обычно 26 недель — чтобы машина могла стоять выключенной полгода без проблем):

certutil -setreg ca\CRLPeriodUnits 26
certutil -setreg ca\CRLPeriod "Weeks"
certutil -setreg ca\CRLDeltaPeriodUnits 0
certutil -setreg ca\CRLOverlapPeriodUnits 4
certutil -setreg ca\CRLOverlapPeriod "Weeks"
certutil -setreg ca\ValidityPeriodUnits 10
certutil -setreg ca\ValidityPeriod "Years"
Restart-Service certsvc
certutil -crl

Экспортируем корневой сертификат и CRL в файл, переносим на USB-флешку и публикуем на доменном CDP-веб-сервере. После этого — снимаем сетевой адаптер у виртуалки и физически выключаем машину. До следующего цикла обновления CRL она вам не нужна.

Подготовка подчинённого Issuing CA

Что касается Issuing CA, то это уже тот самый сервер, который фактически выдаёт все сертификаты и пользователям, и компьютерам. Он, конечно, обязательно должен быть присоединён к домену и доступен по сети. Именно его данные, его реквизиты, мы и прописываем во всех шаблонах. Какую конфигурацию я бы рекомендовал? Это 4 vCPU, 8 ГБ RAM, 100 ГБ SSD и, конечно, Windows Server 2022.

# Установка роли
Install-WindowsFeature AD-Certificate, ADCS-Cert-Authority, ADCS-Web-Enrollment, `
  ADCS-Online-Cert -IncludeManagementTools

# Установка подчинённого CA
Install-AdcsCertificationAuthority `
  -CAType EnterpriseSubordinateCA `
  -CACommonName "ITFresh Corporate Issuing CA 01" `
  -KeyLength 2048 `
  -HashAlgorithmName SHA256 `
  -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
  -OutputCertRequestFile "C:\Install\IssuingCA.req" `
  -DatabaseDirectory "D:\CertLog" `
  -LogDirectory "D:\CertLog" `
  -Force

Команда сгенерирует CSR-запрос. Переносим его на флешке на корневой CA, подписываем там и возвращаем готовый сертификат на Issuing CA:

# На Root CA
certreq -submit "C:\Install\IssuingCA.req"
# Запоминаем номер запроса (Request ID), затем
certreq -retrieve  "C:\Install\IssuingCA.crt"

# На Issuing CA
certutil -installCert "C:\Install\IssuingCA.crt"
Start-Service certsvc

Шаблоны сертификатов: основа автоматизации

Шаблоны сертификатов (Certificate Templates) — это типовые конфигурации, которые определяют срок жизни, набор расширений, ключи и кому разрешён выпуск. Open certtmpl.msc на Issuing CA, дальше — дублируете встроенные шаблоны и настраиваете под себя. Я никогда не использую шаблоны по умолчанию — это плохая практика безопасности.

Ключевые настройки на каждом шаблоне:

• General — задайте «Display name» и «Validity period», поставьте галку «Publish certificate in Active Directory».
• Compatibility — выберите минимально поддерживаемую версию Windows Server и клиента.
• Cryptography — RSA 2048 минимум, SHA256, провайдер «Key Storage Provider».
• Subject Name — «Build from this Active Directory information» с вариантом «Common name» для пользователей и «DNS name» для серверов.
• Security — нужная группа с правами Read+Enroll+Autoenroll (последнее только для шаблонов автовыпуска).

После настройки публикуем шаблон на CA через PowerShell:

Add-CATemplate -Name "ITFresh-Computer-2026" -Force
Get-CATemplate  # Проверка

Автоэнроллмент через групповую политику

Автоэнроллмент — это магия, ради которой вообще существует Enterprise CA. Один раз настраиваете шаблон и GPO, и дальше сертификаты на всех новых компьютерах и пользователях выдаются автоматически, без вмешательства админа.

1. Откройте gpmc.msc, создайте новую GPO «Certificate Autoenrollment» и привяжите к OU с компьютерами или пользователями.
2. Перейдите в Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Certificate Services Client - Auto-Enrollment.
3. Включите политику (Enabled), поставьте галки «Renew expired certificates, update pending certificates, and remove revoked certificates» и «Update certificates that use certificate templates».
4. Аналогично — для User Configuration, если выпускаете сертификаты на пользователей.

Итак, через 90 минут после того, как политика применится (или если вы нетерпеливы, то сразу после выполнения команды gpupdate /force), на вашей машине должен появиться сертификат компьютера. Как это проверить? Вот так:

certutil -store -silent My
# или через mmc - certificates - Local Computer - Personal - Certificates

Публикация CRL и OCSP — обязательная часть

Без правильно настроенных CRL Distribution Point (CDP) и Authority Information Access (AIA) ваш PKI работать не будет. Когда клиент получает сертификат, он должен скачать список отозванных и проверить цепочку — если URL недоступен, сертификат отвергается. Это очень часто забывают, и из-за этого PKI «вроде работает», но половина сервисов выдаёт ошибки.

Вот стандартная схема, как это обычно делается: мы поднимаем отдельный веб-сервер на своей виртуалке (кстати, можно использовать тот же IIS, который у вас уже хостит CA Web Enrollment). А затем просто публикуем по HTTP и CRL, и сам сертификат CA. Всё просто!

# На Issuing CA задаём CDP/AIA
$cdpUrls = @(
  "C:\Windows\System32\CertSrv\CertEnroll\%3%8%9.crl",
  "http://pki.corp.example.ru/CertEnroll/%3%8%9.crl",
  "ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10"
)
certutil -setreg ca\CRLPublicationURLs $($cdpUrls -join "`n")

$aiaUrls = @(
  "1:C:\Windows\System32\CertSrv\CertEnroll\%1_%3%4.crt",
  "2:http://pki.corp.example.ru/CertEnroll/%1_%3%4.crt",
  "2:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11"
)
certutil -setreg ca\CACertPublicationURLs $($aiaUrls -join "`n")

Restart-Service certsvc
certutil -crl

Дополнительно настраиваем OCSP Responder — это HTTP-сервис, который проверяет статус одного сертификата без скачивания всего CRL. Для офиса на 50 машин не критично, но если у вас 500+ устройств с частой проверкой — снижает нагрузку и ускоряет аутентификацию.

Реальный кейс: PKI для производственного холдинга

Помню, в январе 2026 года к нам обратился один интересный клиент. Это было производство металлоконструкций, находится в Подмосковье. У них там 240 рабочих мест, два цеха, отдельный офисный блок, а домен работал на Server 2019. Перед нами стояло целых три задачи. Во-первых, нужно было избавиться от этих надоедливых предупреждений браузеров на 1С веб-клиенте и Битрикс24-портале. Во-вторых, перевести Wi-Fi на работу с сертификатами, вместо того чтобы использовать один общий пароль. И, в-третьих, подписать их собственные PowerShell-скрипты для GPO.

За пять рабочих дней мы развернули двухуровневую иерархию:

• Root CA (RSA 4096, SHA256, 20 лет) на изолированной виртуалке Hyper-V с экспортированным образом в офлайн-сейф.
• Issuing CA (RSA 2048, SHA256, 10 лет) на доменном Windows Server 2022.
• Шаблоны Web Server, Computer, RAS-and-IAS Server, Code Signing — все с правильными правами и политикой обновления.
• Автоэнроллмент через GPO для компьютеров и пользователей.
• RADIUS на Windows Network Policy Server для WPA2-Enterprise на двух точках доступа Aruba.
• OCSP-респондер на отдельной виртуалке для проверки в реальном времени.

Конечно, в первую неделю после внедрения мы получили 3 заявки в саппорт с классическим вопросом «у меня Wi-Fi не подключается». Но, к счастью, все они решились очень просто — пересозданием профиля на ноутбуке. А вот что было действительно круто: уже через месяц IT-директор заметил, что нагрузка на хелпдеск снизилась аж на 12%! Представляете? Просто исчезли все эти надоевшие проблемы типа «не открывается портал, ругается на сертификат». Кстати, стоимость всех работ составила 165 000 руб. за весь проект. И что самое интересное, этот проект окупился всего за два года, если сравнивать с постоянной покупкой коммерческих сертификатов для 12 внутренних веб-сервисов.

Типичные ошибки при развёртывании AD CS

За много лет я собрал список типовых граблей, на которые наступают админы при первом развёртывании PKI:

• Корневой CA в домене. Самое страшное — ставить Root CA как Enterprise и держать его постоянно в сети. При компрометации сервера злоумышленник получает корневой ключ и может подписать что угодно.
• SHA1 вместо SHA256. Современные браузеры и Windows 10/11 жалуются на SHA1, а с конца 2020 годов отказывают в подключении.
• Короткий CRL у Root CA. Если CRL живёт неделю, вам придётся включать офлайн-машину каждую неделю и публиковать новый список. Минимум 26 недель.
• CDP/AIA без LDAP-варианта. Internal CDP по LDAP-у работает даже без HTTP-сервера, и это страховка на случай, если веб-сервер упал.
• Шаблоны без галки Publish in AD. Без неё пользовательский сертификат не попадает в атрибут userCertificate, и Outlook S/MIME не может найти ключ получателя.
• Не отзывают сертификаты при увольнении. Учётку отключили, а сертификат на ноутбуке остался — человек продолжает заходить в Wi-Fi или VPN. Обязательная процедура: certutil -revoke + публикация нового CRL.

Мониторинг и обслуживание PKI

Подняли — это ещё не значит «забыли». PKI требует регулярного внимания, иначе через 5 лет вы получите массовые отказы аутентификации. Чек-лист обслуживания:

• Раз в неделю — мониторинг места на CA-базе (NTDS.dit), очередь pending requests.
• Раз в месяц — проверка работы автоэнроллмента: на тестовом ПК выдаётся ли сертификат, обновляется ли заранее.
• Раз в квартал — публикация CRL с офлайн Root CA, проверка цепочки доверия.
• Раз в полгода — аудит выпущенных сертификатов, отзыв забытых уволенных учёток.
• Раз в 5 лет — перевыпуск сертификата Issuing CA до окончания срока действия (за полгода-год вперёд).
• Бэкап CA: ключи, базу и реестр HKLM\SYSTEM\CurrentControlSet\Services\CertSvc — обязательно в отдельный защищённый бэкап.

# Бэкап CA
Backup-CARoleService -Path "D:\Backups\CA-$(Get-Date -Format yyyyMMdd)" `
  -Password (ConvertTo-SecureString "ВашСтойкийПароль" -AsPlainText -Force)

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

Зачем нужен корпоративный PKI на базе AD CS?

AD CS позволяет выпускать собственные SSL-сертификаты для внутренних сервисов, аутентифицировать пользователей и компьютеры по сертификатам, шифровать почту S/MIME, защищать VPN и Wi-Fi 802.1X — без покупки коммерческих сертификатов и с автоматической ротацией.

Чем отличается standalone CA от enterprise CA?

Standalone CA не интегрирован с AD и используется для офлайн корневого центра. Enterprise CA интегрируется с Active Directory, поддерживает шаблоны сертификатов и автоэнроллмент — основной режим для подчинённого CA.

Зачем выносить корневой CA в офлайн?

Двухуровневая иерархия с офлайн Root CA — стандарт безопасности. Корневой ключ используется только для подписи подчинённого CA и его CRL раз в полгода-год, остальное время сервер выключен и физически отключён от сети. Это защищает корневой ключ от компрометации.

Сколько живёт сертификат подчинённого CA?

Стандартный срок — 5–10 лет. Срок жизни корневого CA — 15–20 лет. Конечные сертификаты пользователей и компьютеров обычно живут 1–2 года с автоматической перевыдачей.

Как настроить автовыпуск сертификатов на рабочие станции?

Создайте шаблон сертификата с разрешением Read+Enrol+Autoenrol для группы Domain Computers, опубликуйте его на CA, и настройте групповую политику Computer Configuration → Public Key Policies → Certificate Services Client - Auto-Enrollment в режим Enabled.