30 октября 2026, 08:45Виталий Лещенко

Windows Server для самых маленьких. Часть 25: Ставим удостоверяющий центр AD CS

Все части серии «Windows Server для самых маленьких»

Коротко

Ставится двухуровневая иерархия: автономный корневой центр вне домена, который включают раз в год, и enterprise-центр, выпускающий рабочие сертификаты по шаблонам из каталога. Корень публикуется в CN=Public Key Services, и все члены домена начинают доверять цепочке. Политика автозачисления (AEPolicy = 7) раздаёт компьютерам сертификаты без участия администратора, а контроллеры получают сертификат по шаблону Domain Controller и без неё — и на них начинает работать LDAPS. Главные опасности — истёкший CRL, который ломает проверку отзыва, опубликованные шаблоны с именем из запроса (ESC1) и веб-зачисление по HTTP с NTLM (ESC8).

Как устроены сертификаты X.509, цепочки доверия, удостоверяющие центры и TLS, разобрано в части 23 сетевой серии; здесь это не повторяется. Коротко: сертификат связывает открытый ключ с именем и подписан удостоверяющим центром (УЦ, CA), а клиент доверяет ему, если цепочка подписей доходит до корневого центра из его списка доверенных и ни один сертификат в ней не отозван. Эта часть — о том, зачем домену свой удостоверяющий центр, как он встраивается в каталог и почему сертификат компьютеру в домене выдаётся без единого действия администратора.

Публичный удостоверяющий центр выдаст сертификат на www.example.com, но не на dc1.corp.example.com: это имя не разрешается из интернета, и подтвердить владение им нельзя (часть 4). Он не выдаст сертификат пользователю для входа по смарт-карте, компьютеру для подключения к Wi-Fi по 802.1X, контроллеру домена для LDAPS — тысячи сертификатов с коротким сроком, которые нужно выпускать и продлевать автоматически. Для этого в Windows Server есть роль Active Directory Certificate Services (AD CS): удостоверяющий центр, который знает каталог, берёт имена и права из него и выдаёт сертификаты тем, кому положено, по правилам, которые называются шаблонами.

Команды на серверах центров выполняются в их консоли, в Windows PowerShell 5.1: модули ADCSDeployment и ADCSAdministration работают с центром на том же сервере и в PowerShell 7 приходят только через слой совместимости. Остальное — с рабочей станции ws1 в PowerShell 7 (часть 15).

Иерархия

Рекомендуемая схема — двухуровневая:

 ┌───────────────────────────────────────────────────────────────┐
 │  Example Corp Root CA              автономный, НЕ в домене,   │
 │  ca-root (выключен)                 включается раз в год      │
 │  срок 20 лет, ключ 4096             выдаёт: сертификаты       │
 │                                     подчинённых ЦС и свой CRL │
 └──────────────────────────┬────────────────────────────────────┘
                            │ подписывает
 ┌──────────────────────────▼────────────────────────────────────┐
 │  Example Corp Issuing CA 1         enterprise, член домена,   │
 │  ca1.corp.example.com               интегрирован с каталогом  │
 │  срок 10 лет, ключ 4096             выдаёт: все рабочие       │
 │                                     сертификаты по шаблонам   │
 └───────────────────────────────────────────────────────────────┘
                            ▼
      контроллеры, серверы, рабочие станции, пользователи, NPS, веб

Корневой центр — автономный (standalone): не в домене, без интеграции с каталогом, с одной задачей — подписать сертификат выпускающего центра и раз в год выпускать список отзыва (CRL, certificate revocation list — подписанный центром список серийных номеров отозванных сертификатов со сроком действия). Всё остальное время он выключен: виртуальная машина без сети, и его ключ физически недоступен. Компрометация корня означает переделку всей PKI с нуля; компрометация выпускающего — отзыв его сертификата корнем и установку нового выпускающего.

Выпускающий центр — enterprise: член домена, читает шаблоны из каталога, проверяет права запрашивающего по каталогу, публикует в каталог свой сертификат и список отзыва. Он работает постоянно и выдаёт всё.

Одноуровневый enterprise root — допустимый вариант для лаборатории и для организации, которая осознанно принимает риск корневого ключа на работающем сервере; такой центр встретится в «Смотрим руками». Три уровня (с промежуточным центром политик) — для организаций, которым нужны разные политики выпуска под разными ветвями. Для серии — два.

Что PKI хранит в каталоге

Контейнер CN=Public Key Services,CN=Services,CN=Configuration — из экскурсии в части 5:

PS C:\> Get-ADObject -SearchBase 'CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=example,DC=com' -Filter * -SearchScope OneLevel | Select-Object Name, ObjectClass

Name                      ObjectClass
----                      -----------
AIA                       container
CDP                       container
Certificate Templates     container
Certification Authorities container
Enrollment Services       container
KRA                       container
NTAuthCertificates        certificationAuthority
OID                       msPKI-Enterprise-Oid

Контейнер	Что	Следствие
Certification Authorities	сертификаты корневых центров, которым доверяет лес	каждый член домена копирует их в хранилище корневых сертификатов предприятия, и они видны в `Cert:\LocalMachine\Root`
AIA	сертификаты промежуточных центров	попадают в хранилище промежуточных центров предприятия (`Cert:\LocalMachine\CA`) — цепочка строится без скачивания
Enrollment Services	объекты `pKIEnrollmentService` — enterprise-центры: имя, DNS-имя сервера и список опубликованных шаблонов	клиенты находят, куда отправлять запрос
Certificate Templates	объекты `pKICertificateTemplate` — шаблоны	клиенты читают, что им можно запросить и по каким правилам
NTAuthCertificates	один объект со списком сертификатов центров, которым разрешено выпускать сертификаты для входа	контроллер принимает сертификат при входе по смарт-карте, только если выпускающий ЦС здесь
CDP	по контейнеру на сервер центра, в нём объект `cRLDistributionPoint` с CRL и разностным CRL	клиенты могут проверять отзыв через LDAP
KRA, OID	агенты восстановления ключей и OID шаблонов и политик выпуска, созданных в лесу	—

Хранилища предприятия на клиенте заполняет компонент Certificate Services Client при каждом обновлении групповой политики — независимо от того, включено ли автозачисление, о котором ниже. Из этой таблицы следует главное свойство enterprise-центра: как только он установлен, все члены домена доверяют ему, а он получает право выдавать сертификаты для аутентификации в домене. Это удобство и это риск, к которому вернёмся в конце.

Корневой центр

Сервер ca-root: Windows Server, рабочая группа, без сети после установки. Перед установкой роли — файл C:\Windows\CAPolicy.inf, который задаёт параметры корневого сертификата:

[Version]
Signature="$Windows NT$"

[Certsrv_Server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
CRLPeriod=Weeks
CRLPeriodUnits=52
CRLDeltaPeriodUnits=0
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=0

[AuthorityInformationAccess]

[CRLDistributionPoint]

Пустые секции [AuthorityInformationAccess] и [CRLDistributionPoint] убирают из корневого сертификата расширения AIA (где взять сертификат издателя) и CDP (где взять CRL): корень самоподписан, издателя выше нет, а отзыв корневого сертификата Windows не проверяет. Без этих секций в корень попали бы адреса по умолчанию. Renewal* действуют только при продлении сертификата корня (срок первого задаёт установка), CRLDeltaPeriodUnits=0 — корню разностный CRL не нужен. LoadDefaultTemplates=0 действует только при установке enterprise-центра — не публиковать шаблоны по умолчанию, чтобы центр ничего не выдавал, пока шаблоны не включены осознанно; у автономного шаблонов нет, на выпускающем этот параметр понадобится.

PS C:\> Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools
PS C:\> Install-AdcsCertificationAuthority -CAType StandaloneRootCA -CACommonName 'Example Corp Root CA' -KeyLength 4096 -HashAlgorithmName SHA256 -CryptoProviderName 'RSA#Microsoft Software Key Storage Provider' -ValidityPeriod Years -ValidityPeriodUnits 20 -Force

После установки — параметры, которые корень будет вписывать в выдаваемые сертификаты (то есть в сертификат выпускающего центра): где искать его CRL и его собственный сертификат. Это должны быть адреса, доступные всем клиентам всегда, — HTTP на внутреннем веб-сервере, которым может быть и сам выпускающий центр (HTTPS в CDP и AIA не поддерживается):

PS C:\> certutil -setreg CA\CRLPublicationURLs "1:C:\Windows\System32\CertSrv\CertEnroll\%3%8.crl\n2:http://pki.corp.example.com/pki/%3%8.crl"
PS C:\> certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\System32\CertSrv\CertEnroll\%1_%3%4.crt\n2:http://pki.corp.example.com/pki/%1_%3%4.crt"
PS C:\> certutil -setreg CA\CRLPeriodUnits 52
PS C:\> certutil -setreg CA\CRLPeriod "Weeks"
PS C:\> certutil -setreg CA\CRLOverlapUnits 4
PS C:\> certutil -setreg CA\CRLOverlapPeriod "Weeks"
PS C:\> certutil -setreg CA\ValidityPeriodUnits 10
PS C:\> certutil -setreg CA\ValidityPeriod "Years"
PS C:\> Restart-Service CertSvc
PS C:\> certutil -crl

Значение — список строк через \n, число перед двоеточием — сумма флагов: 1 — публиковать файл по этому пути, 2 — вписывать URL в выдаваемые сертификаты (в CDP для списка отзыва, в AIA для сертификата центра); на выпускающем понадобятся ещё 4 — вписывать адрес разностного CRL в базовый, 64 — публиковать по этому пути и разностный CRL, 32 — адрес OCSP в AIA. Переменные: %1 — DNS-имя сервера, %3 — имя центра, %4 — суффикс номера сертификата центра после продления, %8 — суффикс номера CRL после продления ключа, %9 — суффикс + разностного CRL. Срок CRL в год с запасом (overlap) в четыре недели — ровно под режим «включать раз в год». Обратите внимание на имя значения: запас — CRLOverlapUnits, без Period в середине, а certutil -setreg с опечаткой в имени молча создаст новое значение, которое центр не читает. ValidityPeriod 10 — предельный срок сертификатов, которые корень выдаёт выпускающим.

Корневой сертификат из C:\Windows\System32\CertSrv\CertEnroll\ нужно забрать с сервера и опубликовать в каталоге с машины домена, под Enterprise Admins:

PS C:\> certutil -dspublish -f 'ca-root_Example Corp Root CA.crt' RootCA

Команда кладёт сертификат в Certification Authorities и AIA, и с этого момента каждый член домена при следующем обновлении политики доверяет корню. Сертификат и CRL корня — в папку pki на веб-сервере (её создадим на выпускающем центре): в CDP только HTTP-адрес, и класть CRL корня в каталог (certutil -dspublish с файлом .crl) не обязательно. Корень выключается.

Выпускающий центр

Сервер ca1.corp.example.com, член домена, с тем же CAPolicy.inf, но без секций AIA и CDP (у подчинённого центра эти расширения задаёт настройка корня) и с LoadDefaultTemplates=0. Веб-сервер для CRL удобно поднять здесь же, и CRL с сертификатом корня должны лежать в нём до установки центра: без доступного CRL корня проверка цепочки при установке сертификата ca1 не пройдёт.

PS C:\> Install-WindowsFeature ADCS-Cert-Authority, Web-Server -IncludeManagementTools
PS C:\> New-Item C:\inetpub\pki -ItemType Directory
PS C:\> New-WebVirtualDirectory -Site 'Default Web Site' -Name pki -PhysicalPath C:\inetpub\pki
PS C:\> Set-WebConfigurationProperty -PSPath 'IIS:\Sites\Default Web Site\pki' -Filter system.webServer/security/requestFiltering -Name allowDoubleEscaping -Value $true
PS C:\> Copy-Item 'C:\Transfer\ca-root_Example Corp Root CA.crt', 'C:\Transfer\Example Corp Root CA.crl' C:\inetpub\pki\

allowDoubleEscaping нужен из-за знака + в именах разностных CRL: фильтр запросов IIS по умолчанию отвергает его в пути. Имя pki в DNS — с рабочей станции:

PS C:\> Add-DnsServerResourceRecordCName -ComputerName dc2 -ZoneName corp.example.com -Name pki -HostNameAlias ca1.corp.example.com

Установка enterprise-центра пишет в раздел конфигурации, поэтому выполняется под Enterprise Admins. Подчинённый центр не может подписать себя сам: установка создаёт запрос на сертификат, который нужно отнести корню, и предупреждает, что установка не завершена:

PS C:\> Install-AdcsCertificationAuthority -CAType EnterpriseSubordinateCA -CACommonName 'Example Corp Issuing CA 1' -KeyLength 4096 -HashAlgorithmName SHA256 -CryptoProviderName 'RSA#Microsoft Software Key Storage Provider' -OutputCertRequestFile C:\Transfer\ca1.req -Force

На включённом на час корне:

PS C:\> certreq -submit -config 'ca-root\Example Corp Root CA' C:\Transfer\ca1.req C:\Transfer\ca1.cer
PS C:\> certutil -resubmit 2
PS C:\> certreq -retrieve -config 'ca-root\Example Corp Root CA' 2 C:\Transfer\ca1.cer

Автономный центр без шаблонов по умолчанию не выдаёт ничего сам: certreq -submit сообщит номер запроса (здесь 2) и то, что запрос ожидает решения. certutil -resubmit 2 одобряет ожидающий запрос, certreq -retrieve забирает сертификат. Файл — обратно на ca1:

PS C:\> certutil -installcert C:\Transfer\ca1.cer
PS C:\> Start-Service CertSvc
PS C:\> certutil -setreg CA\CRLPeriodUnits 1;  certutil -setreg CA\CRLPeriod "Weeks"
PS C:\> certutil -setreg CA\CRLDeltaPeriodUnits 1;  certutil -setreg CA\CRLDeltaPeriod "Days"
PS C:\> certutil -setreg CA\ValidityPeriodUnits 2;  certutil -setreg CA\ValidityPeriod "Years"
PS C:\> certutil -setreg CA\AuditFilter 127
PS C:\> auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable
PS C:\> Get-CACrlDistributionPoint | Where-Object Uri -like 'http*' | Remove-CACrlDistributionPoint -Force
PS C:\> Add-CACrlDistributionPoint -Uri 'http://pki.corp.example.com/pki/%3%8%9.crl' -AddToCertificateCdp -AddToFreshestCrl -Force
PS C:\> Add-CACrlDistributionPoint -Uri 'C:\inetpub\pki\%3%8%9.crl' -PublishToServer -PublishDeltaToServer -Force
PS C:\> Add-CAAuthorityInformationAccess -Uri 'http://pki.corp.example.com/pki/%1_%3%4.crt' -AddToCertificateAia -Force
PS C:\> Restart-Service CertSvc
PS C:\> certutil -crl
PS C:\> Copy-Item 'C:\Windows\System32\CertSrv\CertEnroll\ca1.corp.example.com_Example Corp Issuing CA 1.crt' C:\inetpub\pki\

Модуль ADCSAdministration даёт командлеты для CDP и AIA вместо certutil -setreg с флагами: -AddToCertificateCdp — флаг 2, -AddToFreshestCrl — 4, -PublishToServer и -PublishDeltaToServer — 1 и 64. LDAP-адрес по умолчанию (ldap:///CN=%7%8,CN=%2,CN=CDP,…) остаётся и тоже попадает в сертификаты; машинам вне домена он бесполезен, и его часто убирают, оставляя в CDP только HTTP. CRL на неделю с разностным на день: выпускающий центр работает постоянно и обновляет их сам. ValidityPeriod 2 — предел срока выдаваемых сертификатов: шаблон может дать меньше, но не больше. AuditFilter 127 — аудит всех операций центра в журнал Security, и только вместе с политикой аудита «Certification Services»: по умолчанию нет ни того, ни другого. Выпускающий центр сам публикует свой сертификат в AIA и NTAuthCertificates, а себя — в Enrollment Services, и с этого момента клиенты домена знают, где запрашивать.

Шаблоны

Шаблон — правила выпуска: для чего сертификат (EKU, extended key usage: Server Authentication, Client Authentication, Smart Card Logon, …), откуда брать имя субъекта и SAN (Subject Alternative Name — дополнительные имена: DNS-имена, UPN) — из каталога или из запроса, срок, алгоритм и длина ключа, экспортируемость ключа, нужно ли одобрение, и кто имеет право запросить (Enroll) и получить автоматически (Autoenroll). Шаблоны хранятся в каталоге, общие для всех центров леса; каждый enterprise-центр публикует у себя те, по которым выдаёт. Автономный центр шаблонов не знает вовсе.

Встроенных шаблонов три десятка с лишним — Computer, User, Web Server, Domain Controller, Domain Controller Authentication, Kerberos Authentication, Workstation Authentication, RAS and IAS Server, Smartcard Logon, Code Signing, OCSP Response Signing, — и правило работы с ними одно: встроенные не редактируют, а дублируют. У шаблонов версии 1 (Windows 2000) менять можно только права, версия 2 (Windows Server 2003) дала настраиваемые шаблоны и автозачисление, версия 3 (2008) — ключи CNG (Cryptography Next Generation, новый криптографический API Windows), версия 4 (2012) — продление тем же ключом и другие поздние параметры. Дубликат получает версию по вкладке совместимости: минимальные центр и клиент Windows Server 2003 — версия 2, 2008 — 3, 2012 и новее — 4; а ещё своё имя и свои параметры.

Редактирование шаблонов — единственное место этой серии, где без оснастки не обойтись: командлетов для свойств шаблона в поставке нет (есть сторонний модуль PSPKI), а правка объекта pKICertificateTemplate в каталоге напрямую требует знать формат десятка двоичных атрибутов. Оснастка certtmpl.msc: правый клик на Workstation Authentication → Duplicate Template; совместимость Windows Server 2016, имя Corp Computer, срок 1 год, продление за 6 недель (как у оригинала), Subject Name → Build from AD (DNS name и DNS в SAN), Security → Domain Computers: Read, Enroll, Autoenroll. Второй — дубликат Web Server с именем Corp Web Server, Subject Name → Supply in the request, Security → группа Web Admins: Enroll, и флажок «CA certificate manager approval» для контроля.

Что видно из PowerShell — объекты шаблонов. Вот встроенные, с которых делаются копии:

PS C:\> $pks = 'CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=example,DC=com'
PS C:\> Get-ADObject -SearchBase "CN=Certificate Templates,$pks" -Filter "Name -eq 'Machine' -or Name -eq 'Workstation' -or Name -eq 'WebServer' -or Name -eq 'DomainController' -or Name -eq 'DomainControllerAuthentication' -or Name -eq 'KerberosAuthentication'" -Properties displayName, msPKI-Template-Schema-Version, pKIExtendedKeyUsage, msPKI-Certificate-Name-Flag, msPKI-Enrollment-Flag |
    Format-Table displayName, @{n='Ver'; e={$_.'msPKI-Template-Schema-Version'}}, @{n='EKU'; e={$_.pKIExtendedKeyUsage -join ','}}, @{n='NameFlag'; e={'0x{0:X}' -f $_.'msPKI-Certificate-Name-Flag'}}, @{n='EnrollFlag'; e={'0x{0:X}' -f $_.'msPKI-Enrollment-Flag'}}

displayName                      Ver EKU                                                                        NameFlag   EnrollFlag
-----------                      --- ---                                                                        --------   ----------
Computer                           1 1.3.6.1.5.5.7.3.2,1.3.6.1.5.5.7.3.1                                        0x18000000 0x20
Web Server                         1 1.3.6.1.5.5.7.3.1                                                          0x1        0x0
Workstation Authentication         2 1.3.6.1.5.5.7.3.2                                                          0x8000000  0x20
Domain Controller                  1 1.3.6.1.5.5.7.3.2,1.3.6.1.5.5.7.3.1                                        0x19000000 0x29
Kerberos Authentication            2 1.3.6.1.5.5.7.3.2,1.3.6.1.5.5.7.3.1,1.3.6.1.4.1.311.20.2.2,1.3.6.1.5.2.3.5 0x8400000  0x20
Domain Controller Authentication   2 1.3.6.1.5.5.7.3.2,1.3.6.1.5.5.7.3.1,1.3.6.1.4.1.311.20.2.2                 0x8000000  0x20

Имя объекта (Machine, WebServer) — это имя шаблона, по которому его публикуют и запрашивают, displayName — то, что видно в оснастке. EKU: 1.3.6.1.5.5.7.3.1 — Server Authentication, .3.2 — Client Authentication, 1.3.6.1.4.1.311.20.2.2 — Smart Card Logon, 1.3.6.1.5.2.3.5 — KDC Authentication.

msPKI-Certificate-Name-Flag — откуда имя: 0x1 — из запроса (ENROLLEE_SUPPLIES_SUBJECT), 0x8000000 — DNS-имя из каталога в SAN, 0x10000000 — оно же в CN субъекта, 0x1000000 — objectGUID в SAN (у Domain Controller), 0x400000 — DNS-имя домена и NetBIOS-имя в SAN (у Kerberos Authentication). msPKI-Enrollment-Flag — как выпускать: 0x20 — разрешено автозачисление, 0x8 — публиковать выданный сертификат в каталог, в атрибут userCertificate владельца, 0x2 — каждый запрос ждёт одобрения менеджера, 0x1 — добавлять в сертификат расширение S/MIME. У Corp Computer будут 0x18000000 (DNS-имя и в CN, и в SAN) и 0x20, у Corp Web Server — 0x1 и 0x2. Эти два атрибута проверяют при аудите шаблонов, о чём ниже.

Опубликовать шаблоны на центре — на ca1:

PS C:\> Add-CATemplate -Name CorpComputer -Force
PS C:\> Add-CATemplate -Name CorpWebServer -Force
PS C:\> Add-CATemplate -Name DomainControllerAuthentication -Force
PS C:\> Add-CATemplate -Name KerberosAuthentication -Force
PS C:\> Get-CATemplate

Get-CATemplate выводит опубликованные шаблоны колонками Name и Oid; OID у шаблона свой в каждом лесу. Публикация — это атрибут certificateTemplates объекта центра в Enrollment Services, поэтому её видно и с любой машины домена через Get-ADObject.

Автозачисление

Теперь то, ради чего всё: каждый компьютер домена получает сертификат Corp Computer сам. Включается одной политикой — 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». В реестре клиента это одно значение AEPolicy = 7 (включено с обоими флажками), и из части 24 мы умеем задать его командой:

PS C:\> $gpo = New-GPO -Name 'PKI - Autoenrollment'
PS C:\> Set-GPRegistryValue -Guid $gpo.Id -Key 'HKLM\SOFTWARE\Policies\Microsoft\Cryptography\AutoEnrollment' -ValueName AEPolicy -Type DWord -Value 7
PS C:\> Set-GPRegistryValue -Guid $gpo.Id -Key 'HKCU\SOFTWARE\Policies\Microsoft\Cryptography\AutoEnrollment' -ValueName AEPolicy -Type DWord -Value 7
PS C:\> New-GPLink -Guid $gpo.Id -Target 'DC=corp,DC=example,DC=com' -LinkEnabled Yes

Ключ HKCU — та же политика для пользователей. Что происходит на клиенте при следующем обновлении политики (и затем каждые 8 часов):

 ws1                                 dc (LDAP)                      ca1 (DCOM)
  │                                      │                              │
  ├─ прочитать шаблоны ─────────────────►│  CN=Certificate Templates    │
  │◄─ список, права, параметры ──────────┤                              │
  │  отобрать те, где у меня Autoenroll  │                              │
  │  и нет действующего сертификата      │                              │
  ├─ прочитать Enrollment Services ─────►│  кто публикует Corp Computer │
  │◄─ ca1.corp.example.com ──────────────┤                              │
  │  сгенерировать ключ, собрать запрос  │                              │
  ├─ ICertRequest::Submit (RPC/DCOM) ──────────────────────────────────►│
  │                                      │   проверить права по ACL     │
  │                                      │   шаблона, взять имя из AD,  │
  │                                      │   подписать                  │
  │◄─ сертификат ───────────────────────────────────────────────────────┤
  │  положить в Cert:\LocalMachine\My    │                              │

Запрос идёт по RPC/DCOM (порт 135 и динамический, как у всего в части 3) с аутентификацией Kerberos: центр знает, кто запрашивает, и берёт имя из объекта компьютера, а не из запроса. За шесть недель до истечения (период продления шаблона) клиент запросит новый сертификат сам. Проверка и принудительный запуск:

PS C:\> Invoke-Command ws1 { certutil -pulse; Start-Sleep 5; Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, Issuer, NotAfter, @{n='Template'; e={ ($_.Extensions | Where-Object { $_.Oid.Value -in '1.3.6.1.4.1.311.21.7', '1.3.6.1.4.1.311.20.2' }).Format($false) -replace '^Template=([^(]+).*', '$1' }} }

certutil -pulse запускает автозачисление сейчас, а последняя колонка достаёт имя шаблона из сертификата. Таких расширений два: у шаблонов версии 1 — Certificate Template Name (1.3.6.1.4.1.311.20.2), где записано только имя (Machine), у версии 2 и новее — Certificate Template Information (1.3.6.1.4.1.311.21.7) вида Template=Corp Computer(<OID>), Major Version Number=100, Minor Version Number=…. Фильтр — по OID, а не по FriendlyName: имя расширения зависит от языка системы, а упрощённый синтаксис Where-Object Oid.FriendlyName -eq … вложенные свойства не разбирает и молча не находит ничего. На ws1 после этого — сертификат CN=ws1.corp.example.com от Example Corp Issuing CA 1 по шаблону Corp Computer.

Ручной запрос по шаблону, где имя задаёт запрашивающий, — модуль PKI:

PS C:\> Get-Certificate -Template CorpWebServer -DnsName web.corp.example.com, intranet.corp.example.com -SubjectName 'CN=web.corp.example.com' -CertStoreLocation Cert:\LocalMachine\My -Url ldap:
PS C:\> certutil -config 'ca1.corp.example.com\Example Corp Issuing CA 1' -resubmit 17     # одобрить на центре
PS C:\> Get-Certificate -Request (Get-ChildItem Cert:\LocalMachine\Request | Select-Object -Last 1)

-Url ldap: — найти центр через каталог. Шаблон требует одобрения, поэтому первый вызов вернёт статус Pending и оставит запрос в хранилище Request; после одобрения второй вызов заберёт сертификат. Для машин вне домена и за файрволом есть роли Certificate Enrollment Policy Web Service и Certificate Enrollment Web Service — те же шаги по HTTPS — и классический certreq -new с INF-файлом, -submit, -accept.

Контроллеры домена получают сертификат по встроенному шаблону Domain Controller (версия 1) даже без политики автозачисления — достаточно, чтобы шаблон был опубликован на enterprise-центре. Шаблоны версии 2 Domain Controller Authentication и Kerberos Authentication (у групп Domain Controllers и Enterprise Domain Controllers на них есть Autoenroll) приходят только с включённой политикой; первый из них заменяет (supersedes) Domain Controller. С сертификатом, где есть Server Authentication и DNS-имя контроллера, LDAPS на 636 (LDAP внутри TLS) начинает работать без настройки: контроллер находит сертификат в своём хранилище сам. А KDC получает возможность принимать PKINIT — вариант предварительной аутентификации Kerberos, в котором клиент доказывает личность подписью закрытым ключом своего сертификата вместо ключа из пароля, и KDC тоже подписывает ответ своим сертификатом с EKU KDC Authentication. На PKINIT держится вход по смарт-карте и Windows Hello for Business. WinRM HTTPS из части 14 берёт сертификат с Server Authentication от того же центра — по Web Server или его дубликату.

Отзыв

Сертификат отзывают, когда ключ скомпрометирован или сертификат больше не должен действовать (сотрудник ушёл, сервер списан):

PS C:\> certutil -config 'ca1.corp.example.com\Example Corp Issuing CA 1' -revoke 1a2b3c4d5e6f7081 1     # серийный номер, причина 1 = Key Compromise
PS C:\> certutil -crl                                                                                     # на ca1: опубликовать CRL сейчас, не ждать недели

Клиент узнаёт об отзыве одним из двух способов, адреса которых вписаны в сертификат: скачивает CRL по URL из CDP (и кеширует до истечения срока CRL; разностный CRL — короткий список отзывов после последнего базового, адрес которого записан в самом базовом) или спрашивает OCSP-респондер по URL из AIA про конкретный сертификат: OCSP (Online Certificate Status Protocol) — запрос по HTTP с серийным номером и подписанный ответ «действует», «отозван» или «неизвестен». Респондер — отдельная роль ADCS-Online-Cert: Install-WindowsFeature ADCS-Online-Cert; Install-AdcsOnlineResponder, конфигурация отзыва для каждого центра с сертификатом подписи по шаблону OCSP Response Signing (короткий, на пару недель, респондер продлевает его сам), и URL http://ocsp.corp.example.com/ocsp добавляется в AIA центра флагом -AddToCertificateOcsp. OCSP нужен там, где CRL велик или где важна скорость реакции на отзыв (смарт-карты, VPN); для домена среднего размера хватает CRL.

Самый важный факт об отзыве — истёкший CRL ломает проверку. Если выпускающий центр не опубликовал новый CRL (служба остановлена, диск полон, веб-сервер не отвечает), то по истечении срока старого каждый клиент при проверке любого сертификата этого центра получает «невозможно проверить отзыв». Строгие проверяющие — KDC при входе по сертификату, NPS при EAP-TLS — считают это отказом; другие приложения ведут себя по-разному, но рассчитывать на снисходительность нельзя. Поэтому срок CRL ставят с запасом. Даже без CRLOverlapUnits центр добавляет свой: у реального недельного CRL NextUpdate на 12 часов 10 минут позже времени следующей публикации, а ThisUpdate — на 10 минут раньше фактической, на расхождение часов (пример — в «Смотрим руками»). Публикацию проверяют мониторингом, а корневой центр включают по календарю до истечения его годового CRL, а не после первого звонка.

PS C:\> certutil -URL http://pki.corp.example.com/pki/Example%20Corp%20Issuing%20CA%201.crl     # окно проверки URL
PS C:\> certutil -verify -urlfetch C:\Temp\ws1.cer | Select-String 'Verified|Expired|Revocation'

certutil -URL открывает окно, где можно проверить адреса из сертификата по одному; -verify -urlfetch проходит всю цепочку и скачивает каждый CRL и ответ OCSP по-настоящему, мимо кеша.

Резервное копирование

Центр — это база выданных сертификатов, его ключ и сертификат, и параметры в реестре. Шаблоны живут в каталоге и копируются с состоянием системы контроллера (часть 20).

PS C:\> Backup-CARoleService -Path D:\CABackup -Password (Read-Host -AsSecureString 'PFX password')
PS C:\> reg export 'HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration' D:\CABackup\CertSvc.reg /y

Backup-CARoleService без ключей копирует и базу, и ключ: база — в подпапку Database, ключ с сертификатом центра — в файл .p12, защищённый паролем (-KeyOnly и -DatabaseOnly — по отдельности). Параметры центра — CDP, AIA, сроки, флаги — в базу не входят, поэтому рядом экспорт ветки реестра CertSvc\Configuration. Файл .p12 хранится отдельно от базы и там же, где пароль DSRM. Для корня копия делается после установки и после каждого включения, если он что-то выдал или отозвал. Восстановление — Restore-CARoleService -Path … -Password … на сервере с установленной ролью и тем же именем центра, затем импорт реестра.

Что ломает домен

В 2021 году вышла работа «Certified Pre-Owned» (SpecterOps) со списком типовых ошибок в настройке AD CS, пронумерованных ESC1–ESC8, — с тех пор список дополнялся, а Microsoft Defender for Identity проверяет часть из них под теми же номерами. Суть большинства — одна: сертификат с EKU для аутентификации (Client Authentication, Smart Card Logon, Any Purpose) от центра из NTAuthCertificates равен паролю того, чьё имя в нём написано. Если шаблон позволяет обычному пользователю получить такой сертификат с чужим именем, этот пользователь может войти администратором домена.

Ошибка	В чём	Проверка
ESC1	шаблон с EKU аутентификации, именем из запроса (`ENROLLEE_SUPPLIES_SUBJECT`), без одобрения, с Enroll для широкой группы	`msPKI-Certificate-Name-Flag` бит 0x1 вместе с EKU 1.3.6.1.5.5.7.3.2 и Enroll у Domain Users, Domain Computers или Authenticated Users
ESC2	шаблон с EKU Any Purpose (`2.5.29.37.0`) или без EKU, доступный широкой группе	EKU `2.5.29.37.0` или пустой
ESC3	шаблон агента запросов (Certificate Request Agent) без ограничений: его владелец запрашивает сертификаты от чужого имени	EKU `1.3.6.1.4.1.311.20.2.1` и Enroll у широкой группы
ESC4	права на правку шаблона у не-администраторов	ACL объектов в `Certificate Templates`
ESC5	права на объекты PKI в каталоге и на сам сервер центра	ACL `Public Key Services`, `NTAuthCertificates`, объекта компьютера центра
ESC6	флаг `EDITF_ATTRIBUTESUBJECTALTNAME2` на центре: SAN из запроса для любого шаблона	`certutil -getreg policy\EditFlags` — его там быть не должно
ESC7	права CA Administrator (Manage CA) или Certificate Manager у лишних	`certutil -getreg CA\Security`
ESC8	веб-зачисление (`certsrv`) или CES по HTTP с NTLM — ретрансляция NTLM	роль Web Enrollment не ставить; если стоит — только HTTPS с расширенной защитой (EPA, привязка NTLM к TLS-каналу)

Из поздних номеров полезно помнить ESC11 — интерфейс запросов RPC без обязательного шифрования (флаг IF_ENFORCEENCRYPTICERTREQUEST в CA\InterfaceFlags включён по умолчанию), и ESC15 (CVE-2024-49019) — шаблоны версии 1 с именем из запроса, например встроенный Web Server, в которых до обновлений ноября 2024 года можно было вписать в запрос любую политику применения.

С мая 2022 года enterprise-центры добавляют в сертификаты, выданные по шаблонам с именем из каталога, расширение с SID субъекта (1.3.6.1.4.1.311.25.2), а контроллеры сопоставляют сертификат с учётной записью строго — по этому SID или по явной привязке в altSecurityIdentities, а не по имени. С обновлений февраля 2025 года строгий режим включается по умолчанию, с сентября 2025-го вернуть режим совместимости нельзя. Сертификат по шаблону с именем из запроса такого расширения не получает, и войти с ним в чужую учётную запись по одному имени уже не выйдет. Но аудита шаблонов это не отменяет: сертификат с чужим DNS-именем по-прежнему позволяет выдать себя за чужой сервер в TLS, а права Enroll и Manage CA остаются путями к домену. И последнее: выпускающий центр — сервер уровня 0 из части 15, с теми же правилами доступа, что у контроллеров.

Смотрим руками

Вывод ниже снят в домене, где много лет работает одноуровневый enterprise root Example Corp CA на ca.corp.example.com с адресами CDP и AIA по умолчанию (http://<сервер>/CertEnroll/) и респондером OCSP. Механизмы те же; в двухуровневой схеме в хранилище корней лежал бы Example Corp Root CA, а выпускающий — в хранилище промежуточных.

Центр в каталоге — сервер и число опубликованных шаблонов:

PS C:\> $pks = 'CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=example,DC=com'
PS C:\> Get-ADObject -SearchBase "CN=Enrollment Services,$pks" -SearchScope OneLevel -Filter * -Properties dNSHostName, certificateTemplates | Select-Object Name, dNSHostName, @{n='Templates'; e={$_.certificateTemplates.Count}}

Name            dNSHostName         Templates
----            -----------         ---------
Example Corp CA ca.corp.example.com        18

Корень на рабочей станции пришёл из каталога, а не из GPO и не руками: certutil -enterprise показывает именно хранилище предприятия.

PS C:\> certutil -enterprise -store Root
Root "Trusted Root Certification Authorities"
================ Certificate 0 ================
Serial Number: …
Issuer: CN=Example Corp CA, DC=corp, DC=example, DC=com
 NotBefore: 02.03.2015 23:06
 NotAfter: 02.03.2035 23:16
Subject: CN=Example Corp CA, DC=corp, DC=example, DC=com
Certificate Template Name (Certificate Type): CA
CA Version: V0.0
Signature matches Public Key
Root Certificate: Subject matches Issuer
Template: CA, Root Certification Authority
Cert Hash(sha1): …
No key provider information
Cannot find the certificate and private key for decryption.
CertUtil: -store command completed successfully.

У enterprise-центра субъект — общее имя плюс DN домена. Тот же сертификат лежит в certutil -enterprise -store CA (одноуровневый центр публикует себя и в AIA), а в -store NTAuth их два: действующий и прежний, с истёкшим сроком, — старые сертификаты из NTAuthCertificates сами не уходят.

LDAPS на контроллере, который сам получил сертификат по шаблону Domain Controller:

PS C:\> $tcp = New-Object Net.Sockets.TcpClient('dc2.corp.example.com', 636)
PS C:\> $ssl = New-Object Net.Security.SslStream($tcp.GetStream()); $ssl.AuthenticateAsClient('dc2.corp.example.com')
PS C:\> $ssl.RemoteCertificate | Select-Object Subject, Issuer; $ssl.SslProtocol; $tcp.Close()

Subject                 Issuer
-------                 ------
CN=dc2.corp.example.com CN=Example Corp CA, DC=corp, DC=example, DC=com
Tls13

Проверка отзыва сертификата dc1, сохранённого в файл после такого же рукопожатия ([IO.File]::WriteAllBytes("$PWD\dc1-ldaps.cer", $ssl.RemoteCertificate.Export('Cert'))):

PS C:\> certutil -verify -urlfetch .\dc1-ldaps.cer | Select-String 'Verified|Expired|Revocation'

ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
ChainContext.dwRevocationFreshnessTime: 22 Hours, 12 Minutes, 24 Seconds
SimpleChain.dwRevocationFreshnessTime: 22 Hours, 12 Minutes, 24 Seconds
  Verified "Base CRL (0df9)" Time: 0 …
  Verified "Delta CRL (0df9)" Time: 0 …
  Verified "OCSP" Time: 0 …
Verified Issuance Policies: None
Verified Application Policies:
Leaf certificate revocation check passed

Базовый CRL номер 0df9, разностный к нему и ответ OCSP — все три источника доступны. Цепочка проверяется без корня (EXCLUDE_ROOT): отзыв корня не проверяют. Сроки самого CRL:

PS C:\> Invoke-WebRequest 'http://ca.corp.example.com/CertEnroll/Example%20Corp%20CA.crl' -OutFile .\base.crl
PS C:\> certutil -dump .\base.crl | Select-String 'ThisUpdate|NextUpdate|CRL Entries'

 ThisUpdate: 28.10.2026 17:36
 NextUpdate: 05.11.2026 5:56
CRL Entries: 0

Отозванных нет. Центр опубликовал этот CRL в 17:46 (расширение Next CRL Publish называет следующую публикацию — 4 ноября, 17:46): ThisUpdate сдвинут на 10 минут назад, а NextUpdate — через неделю плюс 12 часов 10 минут запаса, хотя CRLOverlapUnits на центре 0. У разностного CRL на сутки — те же 12 часов 10 минут.

Что центр выдал с начала сентября (формат даты в -restrict — как в региональных настройках сервера):

PS C:\> certutil -config 'ca.corp.example.com\Example Corp CA' -view -restrict "Disposition=20,NotBefore>=01.09.2026" -out "RequestID,RequesterName,CommonName,CertificateTemplate,NotAfter" csv
"Issued Request ID","Requester Name","Issued Common Name","Certificate Template","Certificate Expiration Date"
"449","CORP\CA$","ca.corp.example.com","1.3.6.1.4.1.311.21.8.… OCSP Response Signing","18.09.2026 14:33"
"450","CORP\CA$","ca.corp.example.com","1.3.6.1.4.1.311.21.8.… OCSP Response Signing","30.09.2026 14:23"
"451","CORP\DC4$","dc4.corp.example.com","DomainController","22.09.2027 19:22"
"455","CORP\CA$","ca.corp.example.com","1.3.6.1.4.1.311.21.8.… OCSP Response Signing","12.10.2026 14:13"
"456","CORP\CA$","ca.corp.example.com","1.3.6.1.4.1.311.21.8.… OCSP Response Signing","24.10.2026 14:03"
"457","CORP\CA$","ca.corp.example.com","1.3.6.1.4.1.311.21.8.… OCSP Response Signing","05.11.2026 13:53"

Disposition=20 — выданные (21 — отозванные, 9 — ожидающие, 30 — ошибки, 31 — отклонённые). Шаблон версии 1 записан именем, у версии 2 и новее — OID и отображаемое имя через пробел. Респондер OCSP продлевает свой двухнедельный сертификат подписи каждые 12 дней, а dc4 в сентябре продлил годовой сертификат Domain Controller — без всякой политики автозачисления: её в этом домене нет.

Чем это оборачивается для обычных компьютеров, видно на рабочей станции, которой когда-то выдали сертификат Computer вручную:

PS C:\> Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, Issuer, NotAfter, @{n='Template'; e={ ($_.Extensions | Where-Object { $_.Oid.Value -in '1.3.6.1.4.1.311.21.7', '1.3.6.1.4.1.311.20.2' }).Format($false) -replace '^Template=([^(]+).*', '$1' }}

Subject                 Issuer                                          NotAfter            Template
-------                 ------                                          --------            --------
CN=ws1.corp.example.com CN=Example Corp CA, DC=corp, DC=example, DC=com 11.01.2026 22:17:24 Machine
CN=localhost            CN=localhost                                    15.12.2029 3:00:00
CN=web.corp.example.com CN=Example Corp CA, DC=corp, DC=example, DC=com 16.01.2027 20:07:51 Host

PS C:\> Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='Microsoft-Windows-CertificateServicesClient-AutoEnrollment'} -MaxEvents 3 | Select-Object TimeCreated, Id, LevelDisplayName

TimeCreated         Id LevelDisplayName
-----------         -- ----------------
29.10.2026 13:33:54 64 Warning
29.10.2026 5:33:58  64 Warning
29.10.2026 5:32:31  64 Warning

PS C:\> Get-WinEvent -LogName Microsoft-Windows-CertificateServicesClient-Lifecycle-System/Operational | Group-Object Id -NoElement

Count Name
----- ----
    2 1002
  348 1003
    6 1004
    3 1006
    3 1007

Машинный сертификат истёк в январе, и с тех пор клиент каждые 8 часов пишет предупреждение 64 «Certificate for local system with Thumbprint … is about to expire or already expired.», но не продлевает: продлевает только автозачисление. Журналы клиента: в Application провайдер …-CertificateServicesClient-AutoEnrollment пишет 64 (истекает или истёк), 6 (автозачисление не удалось) и 15 (нет связи с каталогом), а провайдер …-CertificateServicesClient-CertEnroll — 19 и 20 (получен и продлён), 13 и 16 (центр отказал в выдаче или продлении, с кодом ошибки), 11 (центр в лесу не найден), 46 (нет прав на шаблон). Номера у провайдеров пересекаются (64 у CertEnroll — успешная загрузка политики с сервера политик), поэтому фильтровать по ProviderName. Журнал Microsoft-Windows-CertificateServicesClient-Lifecycle-System/Operational ведёт сами сертификаты: 1006 — установлен новый, 1001 — заменён, 1003 — скоро истечёт, 1002 — истёк, 1004 — удалён, 1007 — экспортирован. На центре — журнал Security, события 4886 (получен запрос), 4887 (выдан), 4888 (отклонён), 4889 (отложен до одобрения), 4870 (отозван), 4876 и 4877 (резервная копия): с AuditFilter 127 и политикой аудита каждый сертификат оставляет пару 4886–4887 с именем запросившего.

Проверки центра на ESC6, ESC7 и ESC8 — на самом ca:

PS C:\> certutil -getreg policy\EditFlags
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\Example Corp CA\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EditFlags:

  EditFlags REG_DWORD = 11014e (1114446)
    EDITF_REQUESTEXTENSIONLIST -- 2
    EDITF_DISABLEEXTENSIONLIST -- 4
    EDITF_ADDOLDKEYUSAGE -- 8
    EDITF_BASICCONSTRAINTSCRITICAL -- 40 (64)
    EDITF_ENABLEAKIKEYID -- 100 (256)
    EDITF_ENABLEDEFAULTSMIME -- 10000 (65536)
    EDITF_ENABLECHASECLIENTDC -- 100000 (1048576)
CertUtil: -getreg command completed successfully.

PS C:\> certutil -getreg CA\Security
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\Example Corp CA\Security:

  Security REG_BINARY =
    Allow CA Administrator	BUILTIN\Administrators
    Allow Certificate Manager	BUILTIN\Administrators
    Allow CA Administrator	CORP\Domain Admins
    Allow Certificate Manager	CORP\Domain Admins
    Allow CA Administrator	CORP\Enterprise Admins
    Allow Certificate Manager	CORP\Enterprise Admins
    Allow Enroll	NT AUTHORITY\Authenticated Users

CertUtil: -getreg command completed successfully.

EDITF_ATTRIBUTESUBJECTALTNAME2 (0x40000) в списке нет, права центра — как после установки: управление у администраторов, у остальных только Enroll. А вот веб-зачисление на этом центре стоит, и по HTTP:

PS C:\> (Invoke-WebRequest http://ca.corp.example.com/certsrv/ -SkipHttpErrorCheck).Headers['WWW-Authenticate']
Negotiate
NTLM

Ответ 401 предлагает NTLM по HTTP — ровно ESC8: аутентификацию, перехваченную у любой машины, можно переслать сюда и получить сертификат от её имени. Лечится удалением роли ADCS-Web-Enrollment, если ею не пользуются, или HTTPS с EPA.

И проверка шаблонов на ESC1, которую стоит повесить на расписание: опубликованные шаблоны с именем из запроса, без одобрения и подписи агента, с EKU для входа (или без EKU, или Any Purpose) и с правом Enroll у кого-то, кроме администраторов:

PS C:\> Import-Module Microsoft.PowerShell.Security    # без него у nTSecurityDescriptor в PowerShell 7 пустой Access
PS C:\> $published = Get-ADObject -SearchBase "CN=Enrollment Services,$pks" -Filter * -Properties certificateTemplates | ForEach-Object certificateTemplates
PS C:\> Get-ADObject -SearchBase "CN=Certificate Templates,$pks" -Filter * -Properties displayName, msPKI-Certificate-Name-Flag, pKIExtendedKeyUsage, msPKI-Enrollment-Flag, msPKI-RA-Signature, nTSecurityDescriptor |
    Where-Object { $_.Name -in $published -and ($_.'msPKI-Certificate-Name-Flag' -band 1) -and -not ($_.'msPKI-Enrollment-Flag' -band 2) -and -not $_.'msPKI-RA-Signature' -and
                   (-not $_.pKIExtendedKeyUsage -or $_.pKIExtendedKeyUsage -match '^(1\.3\.6\.1\.5\.5\.7\.3\.2|1\.3\.6\.1\.4\.1\.311\.20\.2\.2|1\.3\.6\.1\.5\.2\.3\.4|2\.5\.29\.37\.0)$') } |
    ForEach-Object { $t = $_; $t.nTSecurityDescriptor.Access |
        Where-Object { $_.AccessControlType -eq 'Allow' -and $_.ObjectType -eq '0e10c968-78fb-11d2-90d4-00c04f79dc55' -and $_.IdentityReference -notmatch '\\(Domain|Enterprise) Admins$' } |
        Select-Object @{n='Template'; e={$t.displayName}}, IdentityReference }

Template     IdentityReference
--------     -----------------
Host         CORP\Domain Computers
Managed User CORP\Domain Users

0e10c968-… — расширенное право Enroll, 1.3.6.1.5.2.3.4 — PKINIT Client Authentication. Тонкость PowerShell 7: свойство Access у дескриптора безопасности добавляет модуль Microsoft.PowerShell.Security, и пока он не загружен (его подгружает, например, первый вызов Get-Acl), Access пуст — проверка молча не находит ничего. В Windows PowerShell 5.1 этой ловушки нет.

Два шаблона, которые кто-то сделал годы назад. Managed User — образцовая ESC1: любой пользователь домена получает сертификат с Client Authentication и любым именем, без одобрения. Host — то же для любой учётной записи компьютера, а создать компьютер в домене по умолчанию может любой пользователь (квота ms-DS-MachineAccountQuota — 10). Исправлять сегодня: снять публикацию (Remove-CATemplate), если шаблоном не пользуются, или перевести имя на «Build from AD», или включить одобрение. Встроенный Subordinate Certification Authority, опубликованный на этом центре, тоже подпадает под фильтр (без EKU, имя из запроса), но Enroll на нём только у администраторов, и его отсекает последнее условие. Corp Computer из нашей схемы сюда не попал бы — имя из каталога, Corp Web Server — из-за одобрения и EKU только для сервера.

Источники

Устройство и установка AD CS:

What is Active Directory Certificate Services — роль, типы центров, enterprise и standalone, связь с каталогом;
Prepare the CAPolicy.inf File — секции CAPolicy.inf, пустые [CRLDistributionPoint] и [AuthorityInformationAccess] для корня, LoadDefaultTemplates, Renewal*, отсутствие HTTPS в CDP и AIA;
Install-AdcsCertificationAuthority — установка корневого и подчинённого центров, -OutputCertRequestFile;
certutil — -setreg, -getreg, -dspublish, -installcert, -resubmit, -revoke, -crl, -verify -urlfetch, -view, -pulse, -store -enterprise;
certreq — -submit, -retrieve, -new, -accept;
Configure the CDP and AIA Extensions on CA1 — адреса CDP и AIA, флажки публикации и включения в сертификаты;
Add-CACrlDistributionPoint и Add-CAAuthorityInformationAccess — те же настройки из PowerShell, переменные в адресах, -AddToCertificateOcsp;
Configure CRL and Delta CRL Overlap Periods — CRLOverlapUnits и CRLOverlapPeriod, запас по умолчанию 10 % срока и не больше 12 часов;
Install-AdcsOnlineResponder — установка респондера OCSP;
Import third-party CAs into Enterprise NTAuth store — NTAuthCertificates и вход по сертификату.

Шаблоны и автозачисление:

Certificate template concepts — версии шаблонов, встроенные шаблоны и их версии, правка только копий;
msPKI-Template-Schema-Version, msPKI-Certificate-Name-Flag и msPKI-Enrollment-Flag — атрибуты шаблона и значения их битов (MS-CRTD);
Add-CATemplate и Get-CATemplate — публикация шаблонов на центре;
Configure Group Policy to Autoenroll and Deploy Certificates и Configure Certificate Auto-Enrollment for Network Policy Server — политика автозачисления и её флажки;
Get-Certificate — ручной запрос по шаблону, -Url ldap:, ожидающие запросы;
Enable LDAP over SSL — требования к сертификату контроллера для LDAPS.

Отзыв, резервное копирование и аудит:

RFC 5280 — X.509, CRL и разностный CRL, расширения CDP и AIA;
RFC 6960 — OCSP;
RFC 4556 — PKINIT;
Backup-CARoleService и Restore-CARoleService — копия базы и ключа центра;
Audit Certification Services — политика аудита и события 4868–4900.

Безопасность:

Certificates security posture assessment — ESC1, ESC2, ESC3, ESC4, ESC6, ESC7, ESC8, ESC11 и ESC15: что считается уязвимым и как исправлять;
KB5014754: Certificate-based authentication changes on Windows domain controllers — расширение с SID, строгое сопоставление и сроки его включения;
KB5005413: Mitigating NTLM Relay Attacks on AD CS — ESC8: HTTPS и EPA для веб-зачисления и CES.

У нас есть сертификаты у каждого компьютера и сервера. Следующий шаг — использовать их для того, для чего они лучше пароля: доказать, кто подключается к сети, прежде чем пустить его в неё.

Дальше — часть 26: NPS и RADIUS. Протокол RADIUS и его место между точкой доступа, коммутатором или VPN-шлюзом и каталогом; роль Network Policy Server, клиенты и общие секреты, политики запросов и сетевые политики и порядок их проверки; типы EAP — PEAP-MSCHAPv2 и EAP-TLS — и сертификат сервера от нашего центра; и как читать журнал NPS.