CES and CEP are two Active Directory Certificate Services role services that let clients enroll for certificates over HTTPS instead of the traditional LDAP and RPC/DCOM path. The Certificate Enrollment Policy Web Service (CEP) tells a client what it can request, and the Certificate Enrollment Web Service (CES) submits the request to the certification authority on the client’s behalf. Together, they extend Microsoft PKI to systems that cannot reach the CA or Active Directory directly.
As organizations expand into cloud, hybrid, and remote environments, traditional certificate enrollment becomes harder to manage. Systems outside the corporate network often cannot reach Active Directory Certificate Services (AD CS) using the LDAP, RPC, and DCOM protocols that domain-based enrollment relies on.
The CEP and CES close that gap. Introduced with Windows Server 2008 R2, they enable certificate enrollment over HTTPS, so an organization can issue and renew certificates for systems that are not directly connected to the CA or to Active Directory. Knowing how these services work and when to use them is part of building a scalable and secure PKI.
It matters even more as PKI evolves: The May 2026 update to Windows Server 2025 added post-quantum (ML-DSA) certificate support to AD CS, and Microsoft has outlined plans to extend ML-DSA support to CES, CEP, and other AD CS role services in future updates as organizations begin adopting post-quantum certificates. This article explains web enrollment, what CEP and CES each do, the protocols behind them, when they are the right choice, and how to deploy them securely.
What is Web Enrollment
Web enrollment is the process of requesting and receiving certificates over HTTPS rather than through traditional domain-based mechanisms.
In a standard Active Directory environment, certificate autoenrollment relies on Group Policy, LDAP, and direct communication with the issuing CA. That works well for domain-joined systems, but it breaks down for cloud workloads, perimeter-network servers, workgroup devices, and other systems with limited connectivity to internal infrastructure. Web enrollment solves this by exposing enrollment through HTTPS.
Clients talk to web service endpoints instead of directly to the certification authority, which improves flexibility while preserving network segmentation. The two services that make this work are CEP and CES, each serving a distinct role in the enrollment process.
What is the CEP Web Service
CEP provides enrollment policy information to clients. Before requesting a certificate, a client needs to know which certificate templates are available, which certification authorities can issue them, and what enrollment requirements apply. In a traditional environment, that information comes from Active Directory over LDAP.
CEP publishes the same policy information over HTTPS using Microsoft’s MS-XCEP protocol, which lets a client discover its enrollment options without direct access to Active Directory. CEP supports several authentication methods, including Kerberos, username and password, and client certificate authentication. It also caches policy information, so a newly published template may not appear to enrollment clients immediately. With policy information in hand, the client is ready to submit a certificate request, and that is where CES takes over.
What is the Certificate Enrollment Web Service
CES performs the actual enrollment. After a client obtains policy information from CEP, the client submits its certificate request to CES over HTTPS using the MS-WSTEP protocol, Microsoft’s WS-Trust X.509v3 Token Enrollment Extensions that extend the WS-Trust 1.3 standard. CES then connects to the issuing CA, using DCOM, to complete enrollment on the client’s behalf, retrieves the issued certificate, and returns it to the requester.
When CES runs on a separate server from the CA, which is the typical deployment, its service account must be configured for Kerberos constrained delegation so it can submit requests on behalf of the client; missing this delegation is a frequent cause of enrollment failure.
This is what allows an issuing CA to stay protected inside an internal network segment while only the enrollment service is exposed to clients. CES also supports certificate renewal, pending request retrieval, and key-based renewal, where a client authenticates for renewal using its existing certificate. That makes it a complete enrollment service rather than a simple request proxy. The following table sets out the key differences between CEP and CES side by side.
CES and CEP Compared
| Feature | CEP | CES |
|---|---|---|
| Purpose | Provides enrollment policy information | Processes certificate requests |
| Protocol | MS-XCEP | MS-WSTEP |
| Connects to | Active Directory, to source policy it serves to clients | The certification authority, over DCOM |
| Client transport | HTTPS | HTTPS |
| Supports enrollment | No | Yes |
| Supports renewal | No | Yes |
| Authentication | Kerberos, username and password, client certificate | Kerberos, username and password, client certificate |
| Typical use case | Discovering available templates, CAs, and enrollment rules | Submitting and renewing certificate requests |
The simplest way to remember the difference is that CEP tells clients what they can request, while CES handles the request itself.
When Should You Use CES and CEP
CES and CEP are most useful when traditional domain-based autoenrollment is not practical. Common scenarios include cloud-hosted workloads, perimeter-network and DMZ servers, workgroup systems, partner-managed devices, cross-boundary or cross-forest deployments, and segmented networks where exposing the CA’s RPC and DCOM ports to clients is undesirable.
Organizations whose systems are entirely domain-joined, with reliable connectivity to Active Directory and the issuing CAs, can usually keep using standard Group Policy autoenrollment without deploying these services. The decision comes down to connectivity and trust boundaries, not certificate volume. Once the decision is made, it helps to know the common issues that arise when deploying these services so they can be avoided during planning.
Common Deployment Challenges
Most web enrollment problems occur in the CES or CEP layer rather than at the CA. The most frequent is insufficient permissions: the identity used by CES must hold the appropriate enrollment permissions, specifically the Enroll and Autoenroll ACLs, on each certificate template it is expected to process.
TLS configuration is another common cause of failure. If a client does not trust the certificate presented by the CES or CEP endpoint, the request fails before it ever reaches the CA. Authentication mismatches cause trouble too, since a non-domain-joined system cannot authenticate to an endpoint configured only for Kerberos.
A misconfigured Service Principal Name (SPN) or missing constrained delegation on the CES account, and an incorrect HTTPS binding or untrusted certificate chain on the IIS endpoint, are other frequent culprits. Administrators should also remember that CEP caches policy, which can delay the appearance of newly published templates. Addressing these challenges during planning also sets the foundation for the security controls that should accompany any CES and CEP deployment.
Security Considerations
Because CES submits requests to the CA on behalf of clients, it is a sensitive component of the PKI. Apply least-privilege principles to CES service accounts, restrict enrollment permissions to approved certificate templates, and enforce modern TLS configurations on every enrollment endpoint.
For high-assurance environments, protect the private keys behind the CES and CEP endpoint certificates with a FIPS 140-3 Level 2 or higher validated Hardware Security Module or equivalent hardware-backed key storage. FIPS 140-3 Level 3 is typically reserved for CA private keys. Enable comprehensive logging as well, so that certificate requests, issuance events, and enrollment activity can be forwarded to a SIEM for audit or investigation as needed.
How Encryption Consulting Can Help
Standing up CES and CEP is more than installing two role services. Enrollment workflows, authentication models, network segmentation, certificate templates, and security controls all have to fit the wider PKI architecture, and misconfiguration here quietly becomes a source of outages and audit gaps.
As a cryptography-focused practice, Encryption Consulting brings purpose-built PKI expertise that broad cybersecurity firms cannot replicate. Through its Enterprise PKI Services, EC assesses, designs, deploys, and secures Microsoft PKI environments, covering CA hierarchy design, template governance, certificate lifecycle automation, CA migrations, and web enrollment security reviews.
From assessment and design to CP and CPS documentation, EC keeps your PKI audit-ready and aligned with NIST, FIPS, eIDAS, and WebTrust, with root and subordinate CA keys protected by FIPS 140-3 Level 3 HSMs and key ceremonies documented for audit and recovery readiness.
Where certificate enrollment needs to scale beyond CES and CEP, CertSecure Manager, EC’s Microsoft-PKI-native certificate lifecycle management platform, automates certificate discovery, issuance, and renewal across the estate, closing the visibility and expiry gaps that cause outages. And as organizations prepare for post-quantum cryptography, EC’s PQC advisory and crypto-agility services help them migrate to ML-DSA-based certificates without re-architecting the PKI built today.
Certificate mismanagement and credential expiry are operational risks EC’s practitioners identify and remediate before they become incidents. Whether you are extending enrollment to cloud workloads or modernizing an existing AD CS deployment, EC delivers without disruption, so digital trust stays engineered rather than left to chance.
Conclusion
CES and CEP extend Microsoft PKI beyond traditional domain-based enrollment. CEP provides the enrollment policy information a client needs, while CES processes the certificate request and talks to the certification authority. Together they enable secure certificate enrollment over HTTPS without exposing the CA directly to clients.
For organizations supporting cloud workloads, remote systems, segmented networks, or cross-forest scenarios, CES and CEP remain practical tools for extending PKI securely. A sensible first step is to map which systems cannot use standard autoenrollment today and why, then design the CES and CEP deployment, its authentication model, and its template permissions around those specific trust boundaries before rolling it out.
