CEP/CES enrollment troubleshooting

Draw the two HTTPS conversations

Certificate Enrollment Policy Web Service (CEP) returns enrollment policy. Certificate Enrollment Web Service (CES) accepts requests and forwards them to an issuing CA. The CA still evaluates the request and issues the certificate. CA Web Enrollment (/certsrv) is a separate interactive website. Uploading a request there successfully doesn’t test a native client’s CEP/CES path. Microsoft’s service comparison.

Write down the actual path for one failed request:

Requester identity + user/machine context
    → configured CEP URL → returned policy and CA/enrollment URLs
    → selected CES URL → CES service identity → issuing CA
    → response installation → workload's store and private key

The external client can use HTTPS while CEP uses LDAP/LDAPS to AD and CES uses DCOM to the CA internally. Test each boundary from the component that makes the connection. A client-side TCP 443 test says nothing about the web service’s internal dependencies. CEP communication, CES request transport.

Preserve policy configuration and cache evidence

On a Windows requester with the PKIClient module, these read local configuration for the machine and current user separately:

Get-CertificateEnrollmentPolicyServer -Scope All -Context Machine |
    Format-List *
Get-CertificateEnrollmentPolicyServer -Scope All -Context User |
    Format-List *

Check the URL, authentication and policy identity against the intended design. -Scope All includes applied and locally configured entries, so find where an apparent duplicate came from before deleting it. The cmdlet reference defines context and scope.

These display enrollment policy cache entries in the respective contexts:

certutil -PolicyCache
certutil -user -PolicyCache

Save the cache metadata and selected policy before a refresh or deletion. The Certutil reference distinguishes display from delete; do not use a forced cache purge as the first diagnostic step.

Policy has an identity as well as a URL. MS-XCEP permits different CEP servers to share a policyID only when they return equivalent policy to the same requester. The response also carries a recommended update interval and a “policies not changed” indicator. An HTTP 200 response can therefore leave the client using existing policy. Check the returned identity/content and freshness; the right GPO URL doesn’t guarantee a newly retrieved template list. MS-XCEP response fields.

Inspect the endpoint the policy advertises

The URL used to obtain policy need not be the URL used to submit a request. For an enterprise CA, msPKI-Enrollment-Servers on its enrollment-service object holds enrollment endpoints and associated priority/authentication information. An obsolete hostname, wrong port or wrong authentication variant here can leave policy discovery working while submission fails. Attribute definition.

This queries one explicit DC’s publication view without changing it:

$dc = 'dc1.contoso.com'
$config = (Get-ADRootDSE -Server $dc).configurationNamingContext
$base = "CN=Enrollment Services,CN=Public Key Services,CN=Services,$config"
Get-ADObject -Server $dc -SearchBase $base `
    -LDAPFilter '(objectClass=pKIEnrollmentService)' `
    -Properties dNSHostName,certificateTemplates,msPKI-Enrollment-Servers |
    Select-Object Name,dNSHostName,certificateTemplates,
        msPKI-Enrollment-Servers

Keep the original multivalue strings and compare them with the deployed CES application’s URL and TLS binding before editing. In a forest-publication design, check the account forest’s copy too. Cross-forest publication checks.

Follow identity through the second hop

Capture the failing client account, HTTPS authentication type, IIS application-pool identity, target CA and request ID. Check the exact URL’s TLS hostname, certificate chain, Server Authentication EKU and usable server key. Inspect the issued server certificate rather than assuming that creating a certificate request also bound the response to HTTPS.

For a remote CA and initial enrollment, current Microsoft guidance requires delegation when CES uses Windows integrated or client-certificate authentication. The configured service identity determines whether delegation belongs on the web-server computer account or a domain user account. The documented Kerberos-only versus protocol-transition choice depends on the authentication method. Colocation, username/password and renewal-only modes have different requirements. Delegation conditions, service identity and constrained-delegation configuration.

For an HTTP 401, first check whether the client authenticated to CES. The failure may be on that first connection rather than CES-to-CA authorization. If the CA recorded a denied request, match its requester/template/error with the client. If it didn’t, keep the HTTP status/substatus and enrollment-provider error. An administrator’s browser session can use a different account, authentication package and certificate store from machine autoenrollment.

Test renewal without confusing it with first enrollment

A renewal-only CES rejects a new enrollment before it reaches the CA. Key-based renewal requires a valid existing credential and its usable key, with separate client policy and service configuration. Record whether a failure occurred before expiry, after expiry, or after profile/key loss. Those are different recovery cases. Renewal-only and key-based behavior.

For a pilot, test initial issuance, off-network renewal, certificate selection by the consuming application and an expired/missing-credential recovery path. Preserve the old/new thumbprints and public keys. Authentication with an existing key is distinct from choosing whether the replacement certificate reuses that key; follow the documented workflow for that enrollment design. Current renewal guidance.

Verify failover at the application level

Several responding IP addresses behind one name are not proof that enrollment can fail over. Test an unavailable CEP/CES application as well as an unreachable host, and record the endpoint the client tried next. Microsoft’s guidance favors multiple published service URIs and the native client’s retry logic; a load balancer must understand application health if it hides those endpoints behind one URI. Endpoint availability guidance.

The failover services need to return coherent policy, advertise reachable CAs and authorize the same workload. Check the second node’s CA connection as well as its TLS listener.

Protect Windows-authenticated enrollment endpoints

HTTPS protects transport but does not by itself prevent an attacker relaying NTLM authentication to a certificate-enrollment service. KB5005413 applies to CA Web Enrollment and CES: Microsoft recommends disabling HTTP and requiring Extended Protection for Authentication (EPA). For CES, the prescribed change includes its WCF extendedProtectionPolicy in addition to IIS settings; checking only the IIS checkbox is incomplete. AD CS relay mitigation.

Pilot the documented protection settings with the endpoint’s clients, authentication modes and any TLS-terminating proxy. Test allowed and rejected authentication, and plan for IIS restarts interrupting hosted services. If NTLM is restricted, check that the real client negotiates the intended alternative. Keep EPA in place while fixing that path. Template/CA authorization and strong certificate mapping still need their own checks.