В этой статье рассмотрим, как на базе Windows Server и Active Directory развернуть инфраструктуру открытых ключей (PKI) с помощью роли Active Directory Certificate Services (AD CS).
Разберём архитектуру, этапы установки и настройки, шаблоны сертификатов, а также меры безопасности и управление жизненным циклом. Материал основан на актуальных данных Microsoft и предназначен для практической реализации в корпоративной среде.
Что такое Active Directory Certificate Services
AD CS — это роль Windows Server, предназначенная для выпуска и управления цифровыми сертификатами. Она обеспечивает создание инфраструктуры открытых ключей (PKI) внутри организации.
С помощью AD CS можно:
– централизованно выдавать сертификаты пользователям, компьютерам и сервисам домена;
– использовать сертификаты для шифрования, электронной подписи, VPN, Wi-Fi (EAP-TLS), почты (S/MIME) и веб-серверов (HTTPS);
– реализовать автоматическое получение и продление сертификатов через групповые политики (autoenrollment);
– управлять списками отозванных сертификатов (CRL) и поддерживать Online Responder (OCSP).
Планирование инфраструктуры PKI
Перед установкой важно определить архитектуру, уровень безопасности и способы обслуживания центров сертификации.
Типы архитектуры
– Одноуровневая (Single-tier) — один центр сертификации (CA) одновременно является корневым и выдающим. Просто в настройке, но уязвимо с точки зрения безопасности.
– Двухуровневая (Two-tier) — корневая CA (обычно офлайн) подписывает подчинённую (Issuing CA), которая уже выдаёт сертификаты пользователям. Это стандартная корпоративная схема.
– Трёхуровневая (Three-tier) — используется в особо защищённых организациях, где есть отдельный промежуточный уровень для дополнительной изоляции.
Типы центров сертификации
– Enterprise CA — интегрируется с Active Directory, поддерживает шаблоны сертификатов и автоматическую регистрацию.
– Standalone CA — работает независимо от AD, требует ручной обработки запросов и подходит для автономных или изолированных систем.
Основные параметры проектирования
– Алгоритмы и длина ключей: рекомендуется использовать RSA 2048 или выше, SHA-256 как минимальный алгоритм хэширования.
– Срок действия сертификатов: сертификат подчинённой CA не может быть дольше корневого.
– Период публикации CRL и дельта-CRL — важно, чтобы клиенты всегда могли проверить актуальность.
– Хранилище ключей: возможно использование аппаратных модулей безопасности (HSM) для защиты ключей CA.
– Настройка путей AIA (Authority Information Access) и CDP (CRL Distribution Point), где клиенты смогут получить сертификаты CA и списки отзыва.
Установка и настройка AD CS
1. Добавление роли AD CS
Через Server Manager → Add Roles and Features выбрать роль Active Directory Certificate Services.
При выборе компонентов можно установить следующие службы:
– Certification Authority (CA) — обязательная служба;
– Certification Authority Web Enrollment — веб-интерфейс для подачи запросов;
– Network Device Enrollment Service (NDES) — регистрация устройств без домена;
– Online Responder — проверка статуса сертификатов (OCSP).
После установки запустить мастер настройки и выбрать нужный тип CA.
2. Конфигурация центра сертификации
– Тип CA: Root (корневая) или Subordinate (подчинённая).
– Тип интеграции: Enterprise или Standalone.
– Генерация нового ключа или использование существующего.
– Алгоритм подписи — например, SHA-256 с RSA 2048.
– Указать имя CA — уникальное, латиницей, не совпадающее с именем сервера.
– Установить срок действия корневого сертификата (часто 10–20 лет).
– Определить пути для базы данных и журналов.
После завершения установки система создаст сертификат CA и запустит службу сертификации.
3. Настройка расширений AIA и CDP
Через свойства CA нужно указать адреса публикации:
– CDP (CRL Distribution Point) — путь, где клиенты смогут скачать CRL (обычно HTTP или LDAP).
– AIA (Authority Information Access) — путь, где доступен сертификат CA.
Пример настройки можно сделать в консоли Certification Authority → свойства → вкладка Extensions.
4. Настройка шаблонов сертификатов
Для автоматизации выдачи сертификатов нужно активировать и настроить шаблоны.
Консоль: certtmpl.msc
– Дублируй стандартный шаблон (например, User или Computer).
– В разделе Security выдай разрешения «Enroll» и «Autoenroll» нужным группам.
– Опубликуй шаблон через консоль Certification Authority → Certificate Templates → New → Certificate Template to Issue.
После этого можно включить автоэнролмент через GPO:
Computer Configuration → Windows Settings → Security Settings → Public Key Policies → Certificate Services Client – Auto-Enrollment.
5. Проверка и тестирование
– Проверить, что компьютеры домена автоматически получают сертификаты.
– Убедиться, что цепочка сертификатов строится корректно и CRL доступен.
– Проверить журналы событий (Event Viewer → Applications and Services Logs → ADCS).
– Проверить OCSP, если он используется.
Пример конфигурации через PowerShell
Если нужно установить AD CS и CA из консоли, можно использовать PowerShell:
Add-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools
Install-AdcsCertificationAuthority -CAType EnterpriseRootCa -CACommonName "CorpRootCA" -KeyLength 2048 -HashAlgorithm SHA256 -CryptoProviderName "RSA#Microsoft Software Key Storage Provider"
Для подчинённой CA аналогично, но с параметром -CAType EnterpriseSubordinateCa и последующей установкой сертификата от корневой.
Обслуживание и безопасность
– Делай регулярные резервные копии базы данных CA и приватных ключей.
– Не меняй имя сервера после установки CA — это нарушит цепочку доверия.
– Настрой расписание публикации CRL и дельта-CRL, чтобы клиенты всегда имели актуальные данные.
– Минимизируй права администраторов CA.
– При необходимости используй отдельный сервер OCSP для ускоренной проверки статуса сертификатов.
– В случае компрометации ключа CA необходимо немедленно отозвать сертификаты и перевыпустить цепочку.
Продление и отзыв сертификатов
Продление (renewal) CA выполняется до истечения срока действия, при необходимости с новой ключевой парой.
Отзыв (revocation) используется при компрометации или ошибках. После отзыва сертификат попадает в CRL, который должен быть опубликован.
OCSP может использоваться для ускоренной проверки статуса без загрузки полного CRL.
Пример развертывания двухуровневой PKI
1. Создай офлайн-сервер (не в домене) для корневой CA.
2. Установи роль Standalone Root CA, сгенерируй сертификат.
3. На сервере в домене установи Enterprise Subordinate CA.
4. Сформируй запрос на сертификат и подпиши его на корневом сервере.
5. Установи подписанный сертификат на подчинённую CA.
6. Настрой шаблоны, CRL и автоэнролмент.
7. Проверь доступность CRL и AIA для всех клиентов.
8. Выключи и храни офлайн-CA в защищённом месте.
Распространённые ошибки и советы
– Переименование сервера после установки CA приводит к поломке цепочки доверия.
– Изменения путей CDP и AIA после выпуска сертификатов не применяются к уже выданным.
– Не используй устаревшие алгоритмы (SHA-1, MD5).
– Проверяй даты публикации CRL — просроченные списки приводят к ошибкам доверия.
– Для повышения отказоустойчивости можно использовать несколько подчинённых CA.
Active Directory Certificate Services — мощный инструмент для построения корпоративной инфраструктуры PKI.
При правильном планировании и настройке он обеспечивает безопасную аутентификацию, шифрование и управление сертификатами в доменной среде.
Используй двухуровневую схему с офлайн-корневой CA, автоматизируй выдачу сертификатов через шаблоны и GPO, и обязательно обеспечь резервное копирование и аудит.
Так вы получите надёжную и предсказуемую систему сертификации, полностью интегрированную с Active Directory и современными протоколами безопасности.
