Skip to main content

Microsoft AD CS

Issue from your Active Directory Certificate Services CA via the CES/CEP web services (MS-XCEP policy + MS-WSTEP enrollment). Templates, NTLM/Kerberos auth, and mutual-TLS to the enrollment endpoint.

CES/CEP vs WSTEP​

AD CS exposes its web enrollment as two web-service endpoints, and CertAutoPilot uses both:

  • CEP (MS-XCEP — Certificate Enrollment Policy) returns the list of templates the caller may enrol. CertAutoPilot calls this on Sync.
  • CES (MS-WSTEP — Certificate Enrollment Service) accepts the CSR and returns the issued certificate. "WSTEP" is simply the protocol this CES endpoint speaks — it is not a separate URL.

So there is no separate "WSTEP" field: you supply a CEP Endpoint URL (for template discovery) and a CES Endpoint URL (for enrolment). Both are required — CertAutoPilot cannot run CES-only without a CEP endpoint for templates.

Typical URLs (the <Auth> suffix must match the auth mode you pick — UsernamePassword, Kerberos, or Certificate):

CEP: https://<ca-host>/ADPolicyProvider_CEP_<Auth>/service.svc
CES: https://<ca-host>/<CA-name>_CES_<Auth>/service.svc

Find the exact virtual-directory names in IIS Manager on the CA host (the *_CEP_* and *_CES_* applications under the enrollment site).

Prerequisites​

  • An AD CS server with the CES/CEP (Certificate Enrollment Web Services) roles installed.
  • A service account in AD with permission to Read and Enroll the templates you want to use.
  • Network reachability from the worker to the enrollment endpoint (typically port 443 on the CA host or an IIS frontend).

Create the profile​

  1. Settings → CA Providers → New → Microsoft AD CS.
  2. CEP Endpoint URL — the policy service (e.g. https://<ca-host>/ADPolicyProvider_CEP_UsernamePassword/service.svc).
  3. CES Endpoint URL — the enrollment service (e.g. https://<ca-host>/<CA-name>_CES_UsernamePassword/service.svc). Its _<Auth>_ suffix must match the CEP URL's and your chosen auth mode.
  4. Authentication — Username/password (NTLM), Kerberos, or upload a client certificate for mutual-TLS.
  5. Optional: TLS trust — if your CA chain isn't system-trusted, paste the issuing root.
  6. Save. CertAutoPilot calls CEP, lists the available templates, and stores the binding.

Authentication modes​

ModeUse when
Username/password (NTLM)The most common. Pin to a service account with templated permissions.
Client certificate (mTLS)Highest assurance. Issue the CertAutoPilot worker its own AD CS cert and use it to authenticate to the policy/enrollment endpoint.
KerberosAvailable when the worker host is domain-joined; usually only useful in pure-Windows clusters.

Templates​

When issuing, the operator picks one of the templates returned by CEP. Common templates: WebServer, Computer, EnrollmentAgent. The template controls subject format, key usages, and validity period — CertAutoPilot honours those constraints and rejects mismatched CSR fields client-side before sending to the CA.

CertAutoPilot fetches the list via a live CEP GetPolicies call on every Sync — it caches nothing and applies no limit, so it shows exactly what the CA's policy endpoint returns. If a newly added template doesn't appear after a re-sync, the cause is on the AD CS side — see New template doesn't appear after Sync.

Renewal​

Renewal works the same as issuance — submit a new CSR against the same template. CertAutoPilot keeps the same logical certificate identity in the UI; the underlying X.509 changes, history is preserved.

Troubleshooting​

Policy fetch returns 401​

Either credentials are wrong or NTLM/Kerberos is disabled on the IIS authentication settings of the policy site. Test with curl --ntlm -u DOMAIN\user:pass <url> from the worker host.

New template doesn't appear after Sync​

CertAutoPilot returns exactly what CEP GetPolicies gives it, so a missing template means the CA's policy endpoint isn't returning it. Duplicating a template in the Certificate Templates Console (certtmpl.msc) only creates the AD object — it is not offered for enrollment until all three of the following are true. Work through them in order, then re-Sync:

  1. Publish it to the CA. certsrv.msc → your CA → Certificate Templates → right-click → New → Certificate Template to Issue → select the template. (Duplicating ≠ publishing — this is the most common miss.)

  2. Grant Enroll to the service account. Template Properties → Security → add the account CertAutoPilot authenticates as → allow Enroll (or Autoenroll). CEP only returns templates the caller can enrol.

  3. Refresh the CEP policy cache. The policy web service caches its template set in memory, so a fresh template can lag even after steps 1–2. Recycle just the CEP/CES application pool on the CA's IIS frontend (least disruptive):

    Restart-WebAppPool -Name "<CEP/CES app pool>"   # e.g. WSEnrollmentPolicyServer

    iisreset also works but bounces the whole IIS instance. Neither touches the CA engine, issued certificates, or CRL publishing — only the enrollment web front-end blips for a few seconds. If the domain has multiple DCs, also allow AD replication of the new template object (repadmin /syncall).

After steps 1–3, click Sync again — the new template appears. To see exactly what CEP returned, enable backend debug logging and look for the CEP GetPolicies raw response entry.

TLS handshake fails​

The IIS frontend uses an internal CA your worker doesn't trust. Paste the issuing root into the profile's TLS trust field.

See also​