Active Directory

Сертификат отвечает на вопрос «кому доверять» для TLS, VPN, smart card logon, подписания и LDAPS. Следовательно, CA — control plane: возможность выпустить правдоподобный сертификат для привилегированной идентичности может иметь доменные последствия.

Проект начинают с use cases, владельцев, lifecycle и требований к revocation, а не с роли Windows Server. PKI входит в Tier 0 scope, требует разделения обязанностей, аудита и защищённого резервного копирования.

client trusts Root public key
 |
 v
 Issuing CA --> certificate --> service / user

certutil -config - -ping
certutil -CATemplates

Enterprise Root CA удобен в малой лаборатории: он интегрирован с AD, выдаёт всё сразу. Но постоянно online root key совмещает самый ценный trust anchor с доменной поверхностью атаки и ежедневной операционной нагрузкой.

Для production обычно предпочтительна иерархия offline root плюс online Enterprise issuing CA. Root включают редко, в контролируемой церемонии, только для подписи subordinate CA и собственной ротации.

bad: online Enterprise Root -> every certificate
good: OFFLINE ROOT -> Enterprise Issuing CA -> daily enrollment

certutil -ca.cert RootCA.cer
certutil -dump RootCA.cer

Offline Root подписывает сертификат issuing CA, а online Enterprise Subordinate обслуживает templates и autoenrollment домена. Разделение позволяет обновлять и восстанавливать issuing CA без ежедневного доступа к trust anchor.

До установки фиксируют CA names, validity periods, cryptographic algorithms, AIA/CDP URLs и публикацию root certificate. Эти параметры становятся частью выданных цепочек, поэтому их нельзя безболезненно «переименовать позже».

OFFLINE ROOT CA
 | signs
 v
ENTERPRISE ISSUING CA -- templates --> users, computers, services
 |--> CRL / AIA / OCSP endpoints

certutil -getreg CA\CRLPublicationURLs
certutil -getreg CA\CACertPublicationURLs

Template задаёт subject, SAN, EKU, криптографию, validity и ACL. Самая опасная ошибка — дать низкопривилегированной группе Enroll на шаблон, где subject supplied in request и присутствует Client Authentication либо Smart Card Logon. Такой шаблон может позволить запросить сертификат от имени другой личности.

Шаблоны именуют по use case, публикуют минимально и review-ят как код:

1. owner
2. изменение
3. тест
4. доказательство ACL

Template VPN-User:
 Enroll: GG_VPN_Users
 Subject: built from AD
 EKU: Client Authentication

not: Domain Users + supplied subject + powerful EKU

Get-CATemplate | Sort Name
certutil -v -template VPN-User

Autoenrollment выдаёт и продлевает сертификаты через GPO. Он нужен для компьютеров, LDAPS, Wi-Fi, VPN и масштабных пользовательских сценариев, но ошибка области применения быстро размножается на весь домен. Поэтому deployment начинают с pilot OU и security group.

Проверяют цепочку, subject/SAN, private key permissions, события enrollment, renewal и доступность revocation endpoints с реального клиентского сегмента.

GPO + template ACL -> pilot OU -> Enterprise CA
  |
  v
  LocalMachine\My certificate

gpupdate /force
certutil -pulse
Get-ChildItem Cert:\LocalMachine\My | Select Subject,NotAfter

Отозванный сертификат полезно отозвать только тогда, когда relying party может получить его статус. CDP публикует CRL, OCSP отвечает о конкретном serial number. URL должны быть доступны не только CA, но и VPN-клиенту, DMZ-сервису, устройству до domain logon и удалённой площадке.

Планируют сроки base CRL, delta CRL, overlap и мониторинг истечения. Проверка только с самого CA бессмысленна: она не моделирует маршрут клиента.

certificate --> AIA: issuer
 |----------> CDP: CRL URL
 `----------> OCSP responder -> good/revoked/unknown

certutil -verify -urlfetch certificate.cer
certutil -URL certificate.cer

LDAPS требует корректного server certificate на каждом DC: доверенная цепочка, Server Authentication и DNS names/SAN, которыми реально пользуются клиенты. VPN обычно использует Client Authentication для user или device. Smart card logon имеет особо строгие требования к mapping, enrollment, утере карты и доступности PKI.

Не создавайте универсальный template. Разные use cases имеют разные owners, EKU, сроки, revocation последствия и аудит. Разделение делает инцидент локальным и понятным.

LDAPS: client -> DC certificate (Server Auth)
VPN: client certificate -> gateway (Client Auth)
Smart card: user certificate -> DC/KDC validation

Get-ChildItem Cert:\LocalMachine\My |
 Where-Object {$_.EnhancedKeyUsageList.FriendlyName -contains 'Server Authentication'} |
 Select Subject,NotAfter

Защита CA private key определяет границу всей PKI. Root key хранится offline, доступен по церемонии и при необходимости защищён HSM. Issuing CA нуждается в ограниченном admin access, patch management, backup key/database/configuration и аудите issued/revoked certificates.

Разделяйте CA administrator, template administrator и audit reviewer, где позволяет масштаб. Один человек с полным доступом может незаметно изменить template, выпустить сертификат и скрыть следы.

Root key: offline / ceremony / custody
Issuing key: protected host / restricted admins
Templates: reviewed ACL / change log
Audit logs: independent monitoring

certutil -backupDB D:\CA-Backup
certutil -backupKey D:\CA-Backup

PKI ломается не только при атаке: истекают CA certificates, CRL, меняются DNS, URL, теряется key recovery procedure. Наблюдаемость включает expiry, publishing jobs, enrollment failures, template changes и резервные копии. Restore тестируют отдельно от установки backup job.

Перед продлением CA certificate выбирают, будет ли новый key. Решение влияет на цепочки и срок поддержки старых сертификатов; это планируемая миграция, а не задача последней недели validity.

monitor expiry -> renew plan -> pilot -> publish -> validate clients
 ^   |
 +----------------- audit / restore test --------+

certutil -crl
certutil -getreg CA\ValidityPeriod
Get-WinEvent -LogName Application -MaxEvents 100 | Select TimeCreated,ProviderName,Id