Зачем нужен корпоративный 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.

Active Directory 17 апреля 2026 · 16 мин чтения

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, дальше — дублируете встроенные шаблоны и настраиваете под себя. Я никогда не использую шаблоны по умолчанию — это плохая практика безопасности.

Шаблон-донор	Назначение	Срок	Кому выпускаем
Computer	Аутентификация компьютеров в 802.1X/Wi-Fi	2 года	Domain Computers (Autoenroll)
User	S/MIME, EAP-TLS для VPN	1 год	Domain Users (Autoenroll)
Web Server	HTTPS для внутренних веб-сервисов	2 года	Web Servers Group (Enroll)
Code Signing	Подпись скриптов PowerShell	3 года	IT Department (Enroll)
Workstation Authentication	VPN-аутентификация ноутбуков	1 год	Laptops Group (Autoenroll)

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

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, и дальше сертификаты на всех новых компьютерах и пользователях выдаются автоматически, без вмешательства админа.

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

Развернём корпоративный PKI под ключ

Я лично проектирую и внедряю AD CS в офисах от 30 рабочих мест. Двухуровневая иерархия с офлайн Root CA, шаблоны под ваши задачи, автоэнроллмент на ПК и пользователей, RADIUS для Wi-Fi 802.1X — за 5–10 рабочих дней. Бесплатный аудит существующей инфраструктуры и расчёт стоимости — за 2 часа на месте.

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

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.