Your Ultimate Guide to Understanding CEP and CES

If you manage a Windows Server Public Key Infrastructure (PKI) environment, certificate enrollment is one of the most operationally critical and most frequently broken processes in your infrastructure. When devices sit outside your domain network, traditional certificate enrollment through Active Directory simply doesn’t work. That is exactly the problem that Certificate Enrollment Policy Web Service (CEP) and Certificate Enrollment Web Service (CES) were designed to solve.

These two Active Directory Certificate Services (AD CS) role services work in tandem to enable secure, automated certificate enrollment for any device, whether it’s domain-joined, remotely connected, cloud-hybrid, or completely outside your internal network perimeter. Let’s break down each component and understand how the auto-enrollment process works using CEP and CES.

What Is Certificate Enrollment Policy Web Service (CEP)?

Certificate Enrollment Policy Web Service (CEP) is the AD CS role service responsible for delivering certificate enrollment policy to clients over a secure web interface. It acts as the policy distribution point of your PKI environment.

In a typical domain setup, a Windows computer that is joined to the domain automatically gets certificate-related information from Active Directory without any manual effort. It essentially “asks” Active Directory what certificates it is allowed to request, which certificate templates are available, and which Certification Authorities (CAs) it should use. Based on this information, the machine can then automatically request and install the certificate. All of this happens in the background, so from a user’s perspective, the process is invisible.

This traditional approach stops working in modern environments where systems cannot directly talk to Active Directory. For example,

• Remote workers connecting over the internet without a VPN
• Non-domain-joined devices that have no AD connectivity
• DMZ servers are isolated from the internal domain
• Cloud workloads in Azure, AWS, hybrid environments, or even partner/vendor systems
• Partner or vendor devices that need organizational certificates

Since they cannot query Active Directory, they cannot discover certificate templates or available CAs, which disrupts the normal auto-enrollment process. This is exactly where solutions like CEP and CES become important, as they provide a secure, web-based way for these external or isolated systems to still request and receive certificates.

CEP fixes this problem by making certificate enrollment policy available through a secure HTTPS web service instead of requiring direct access to Active Directory. This means an authorized client, even if it is outside the internal network or not joined to the domain, can still connect to CEP over the web and ask what certificates it is allowed to request, which templates are available, and which CA it should use. In simple terms, CEP acts like a secure online replacement for Active Directory’s policy lookup function, allowing remote or isolated systems to get the certificate enrollment information they need.

What Information Does CEP Deliver?

When a client connects to CEP, CEP sends back all the certificate enrollment rules and options that apply to that specific client. This includes:

• All certificate templates that the client is permitted to use
• Template-specific settings or restrictions, such as key usage or subject requirements
• The target Certification Authority that the client should direct requests to
• Enrollment policy configuration, including renewal thresholds and validity periods
• Authentication requirements the client must satisfy when submitting a request
• Policy metadata, including the unique enrollment policy identifier

Note: CEP only provides information about certificate enrollment policy; it tells the client what it is allowed to request and under what rules. It does not actually issue certificates, process enrollment requests, talk to the Certification Authority to submit a request, or store certificate data. In simple terms, CEP is only a policy guide; it informs the client but does not perform the actual certificate enrollment.

What Is Certificate Enrollment Web Service (CES)?

The Certificate Enrollment Web Service (CES) is the AD CS role service that handles the actual certificate enrollment and renewal transactions. It picks up exactly where CEP leaves off and acts as a secure, authenticated broker between the client and the backend Certification Authority.

Even after the client learns from CEP which certificate it is allowed to request, it still has to actually send that request somewhere so the certificate can be issued. In a normal internal domain setup, this is done by sending the request directly to the Certification Authority using DCOM/RPC, which works only when the client has direct network connectivity to the CA. That becomes a problem for remote users, internet-based devices, or isolated systems because they usually cannot reach the CA directly.

CES solves this by acting as a secure middle layer: the client sends the certificate request to CES over HTTPS, and CES then forwards it to the client’s internal CA. This means the client can still enroll for certificates without ever needing direct access to the CA itself.

Role of CES

• Accepts certificate enrollment and renewal requests from clients over HTTPS
• Authenticates the client before processing any request
• Forwards authenticated requests to the internal Certification Authority
• Returns CA responses – issued certificate, pending status, or denial – back to the client
• Handles certificate renewal, including key-based renewal for automated scenarios
• Maintains the full enrollment transaction from submission to response delivery

This design is important because it protects the internal Certification Authority from being exposed directly to outside systems. The CA does not need to have a public IP address or be reachable from the internet, which greatly reduces security risk. Instead, CES sits in front of the CA and acts as a secure gatekeeper. It checks authentication and authorization first, so only valid and approved requests are ever passed to the CA.

In this way, CES becomes a controlled entry point for certificate enrollment, while the CA stays safely hidden behind it. It also improves accountability, because both CES and the CA can log and audit activity separately, giving better visibility into who submitted a request and how it was processed.

Definitive Comparison Between CEP and CES

CEP tells the client what to request. CES helps the client actually request it.

Let’s understand the similarities and differences between CEP and CES.

CEP (Certificate Enrollment Policy Web Service)	CES (Certificate Enrollment Web Service)
Provides certificate enrollment policy to clients	Handles certificate enrollment and renewal requests
Tells the client what certificates it can request	Enables the client to actually submit the request
Does NOT communicate with the Certification Authority	Communicates with the Certification Authority
Does NOT issue certificates	Does NOT issue certificates (proxies to CA)
Returns templates, settings, and policy details	Processes and forwards certificate requests
Client-facing service	Client-facing service
Requires IIS	Requires IIS
Requires authentication	Requires authentication
Supports Kerberos and Username/Password authentication	Supports Kerberos, Username/Password, and Certificate authentication
Does NOT support certificate-based authentication	Supports certificate authentication (mainly for renewal)
Used to retrieve policy remotely	Used to perform enrollment remotely
Uses HTTPS (Port 443)	Uses HTTPS (Port 443)

Step-by-Step on How Certificate Auto-Enrollment Works

The following is the complete end-to-end workflow for certificate auto-enrollment using CEP and CES in an enterprise Active Directory environment.

Step 1- Client Initiates: Contacts CEP for Enrollment Policy

The workflow begins when a client, such as a Windows workstation, server, or remote device, determines it needs to enroll in a certificate or renew an expiring one. This trigger can come from:

• Group Policy auto-enrollment (scheduled certificate check)
• Manual enrollment initiated by a user or administrator
• Automated renewal triggered by the certificate approaching its expiry threshold
• First-time enrollment on a new device being provisioned

The client reaches out to the CEP endpoint over HTTPS to retrieve the enrollment policy. At this point, no certificate request has been made. The client is simply asking: “What am I allowed to request, and what rules apply?”

This step is critical for remote and non-domain-joined devices because they have no other mechanism for discovering available certificate templates and CA information.

Step 2- CEP Responds: Returns Applicable Policy Details

When a client contacts CEP, it analyzes who the client is and sends back the exact certificate enrollment policy that applies to it. This response includes:

• Complete list of certificate templates the client is authorized to use
• Template-specific settings, including key size requirements, validity period, renewal threshold, subject name configuration, and key usage flags
• Target Certification Authority information — the CA that the client should submit requests to
• Enrollment policy configuration — auto-enrollment behavior, renewal settings
• Policy ID — the unique identifier that ties the policy to its source

In simple terms, this response acts as a complete instruction manual that the client uses to build a valid and compliant certificate request.

Step 3- Builds the Certificate Request

Using the policy response from CEP, the client constructs the certificate request. This involves:

• Generating a cryptographic key pair — public and private key using the algorithm and key size specified in the template (RSA 2048, RSA 4096, or ECC)
• Building the Certificate Signing Request (CSR) in PKCS#10 format
• Selecting the certificate template that matches the client’s needs
• Populating the Subject field — typically the machine name, user UPN, or custom subject based on template configuration
• Adding Subject Alternative Names (SANs) — DNS names, IP addresses, or UPNs as required
• Applying template-defined extensions — Key Usage, Enhanced Key Usage, CDP, AIA

The client uses CEP’s policy response to ensure the request is perfectly aligned with what the CA will accept.

Step 4- Sends Request to CES

Once the certificate request is prepared, the client sends it to the CES endpoint over HTTPS. This request is in PKCS#10 format and includes the required authentication method, such as a Kerberos ticket, username/password, or a client certificate, depending on how CES is configured. At this point, CES takes over as the active processing layer. The client has done its part and now waits while CES handles authentication, forwards the request to the CA, and completes the enrollment process.

Step 5- Authenticates Client and Forwards to CA

This is the most security-critical step in the entire workflow. CES performs two operations sequentially:

Authentication: CES validates the client’s identity using the configured authentication method. For Kerberos, it validates the service ticket. For username/password, it validates the credentials against Active Directory. For certificate-based renewal, it validates the existing certificate. No request moves forward until authentication succeeds.

Forwarding: Once authentication succeeds, CES maps the authenticated identity to the appropriate CA and forwards the certificate request. CES uses its backend service account and CA communication configuration to relay the request securely to the internal CA, which the client has no direct path to.

Step 6- Processes the Certificate Request

When CES forwards the certificate request, the Certification Authority (CA) evaluates it on its own using its configured rules and policies, such as:

• Certificate template permissions — is this identity authorized to enroll for this template?
• Issuance requirements — does the request meet all required attributes?
• CA policy — are there any CA-level restrictions that apply?
• Manager approval settings — does this template require manual approval?

Based on these checks, the CA makes a decision: it issues the certificate if everything is valid, pends the request if manual approval is needed, or denies it if the requester is not authorized or the request does not meet the required criteria.

Step 7- Delivers CA Response to Client

After the Certification Authority makes a decision, CES sends that result back to the client over HTTPS. The results can be as follows:

• If the request is issued, CES returns the completed, signed certificate, typically in PKCS#7 format, so the client can install and use it.
• If the request is pending, CES sends back a Request ID along with a pending status, which allows the client to check again later for the final result.
• If the request is denied, CES returns the relevant error code and the reason for denial, so the client or administrator can understand why the certificate was not issued.

CES receives the CA’s decision and relays it back to the originating client over HTTPS:

• Issued: CES returns the full signed certificate in PKCS#7 format
• Pending: CES returns a RequestID and pending status so the client can poll for completion
• Denied: CES returns the error code and denial reason

Step 8- Client Receives and Installs Certificate

Once the certificate request is processed, the client gets the result. If the request is approved, the certificate is automatically installed in the correct Windows certificate store, Local Machine\Personal for computer certificates and Current User\Personal for user certificates, so it’s ready to use without manual steps. If the request is still pending (for example, waiting for approval), the system doesn’t stop there; the auto-enrollment process will keep checking CES at intervals until a final decision is made. If the request is denied, the failure is recorded in system logs, allowing administrators to review what went wrong and take action if needed.

Breakdown of Kerberos Authentication in CEP and CES

Kerberos is a secure, ticket-based authentication system used in Active Directory that allows users or machines to prove their identity without sending passwords over the network. It works through a trusted service called the Key Distribution Center (KDC), which runs on domain controllers.

The following are the steps on how Kerberos authentication works:

When a user logs into a domain-joined Windows machine, Kerberos authentication begins automatically in the background:

• The client sends an AS-REQ (Authentication Service Request) to the Key Distribution Center (KDC), which runs on the Domain Controller.
• The KDC verifies the client’s identity using the stored credential hash (for a user or machine account) in Active Directory.
• If the credentials are valid, the KDC issues a Ticket Granting Ticket (TGT).
• This TGT is encrypted using the KDC’s secret key, ensuring it cannot be forged or tampered with.
• The client stores the TGT securely in memory within LSASS (Local Security Authority Subsystem Service); it is never written to disk.

When the client needs to contact CEP or CES (for certificate enrollment or policy retrieval):

• The client sends a TGS-REQ (Ticket Granting Service Request) to the KDC.
• It includes its TGT and requests access to a specific service, identified by the Service Principal Name (SPN) of CEP or CES.
• The KDC looks up this SPN in Active Directory and identifies the associated service account running CEP/CES (typically an IIS app pool identity).
• The KDC generates a Service Ticket, which is encrypted using the service account’s secret key, meaning only that service can decrypt it.
• The Service Ticket is returned to the client and stored temporarily in memory.

When the client actually connects to CEP or CES:

• It sends the Service Ticket as part of the HTTPS request using the HTTP Negotiate/Kerberos Authorization header.
• IIS (hosting CEP/CES) receives the request and attempts to decrypt the ticket using the application pool service account credentials.
• Once decrypted, the ticket reveals:
  1. Client identity (username or machine account)
  2. Domain information
  3. Group memberships
  4. Session key for secure communication

• CEP/CES then validates the ticket:
  1. Ensures the ticket is authentic and untampered
  2. Checks the timestamp; it must be within the allowed 5-minute clock skew tolerance
  3. Verifies that the ticket is still valid (not expired)

Kerberos authentication is designed to be completely transparent for the end user; there are no prompts or manual inputs because authentication happens automatically in the background using the logged-in domain identity.

It works natively for all domain-joined Windows machines and users, where the machine account or user account in Active Directory acts as the authenticating identity. The tickets issued by Kerberos are time-bound, typically valid for around 10 hours (configurable via Group Policy), which balances security and usability.

However, Kerberos relies on strict conditions: the client and server clocks must be synchronized within a small window (usually 5 minutes), and the client must have network connectivity to a Domain Controller to obtain and renew tickets.

When to Use Kerberos?

Deploy Kerberos authentication for CEP and CES when:

• All enrolling clients are domain-joined Windows machines
• You are deploying Group Policy auto-enrollment for computer or user certificates
• Clients have reliable, low-latency connectivity to a Domain Controller
• The primary use case is machine certificate auto-enrollment
• Maximum security posture with zero credential exposure is required
• You want fully silent, zero-interaction certificate lifecycle management
• Your environment is a single forest or has well-established cross-forest Kerberos trusts
• You are deploying across an internal corporate network or an enforced split-tunnel VPN

Breakdown of Username/Password Authentication in CEP/CES

Username/password authentication in CEP and CES is used when the client cannot rely on Kerberos, usually because it is not domain-joined, is connecting from an external network, or does not have direct connectivity to a Domain Controller.

Tip: When Microsoft documentation refers to Username/Password authentication for Certificate Enrollment Policy Web Service (CEP) and Certificate Enrollment Web Service (CES), it is referring specifically to HTTP Basic Authentication, a standardized authentication scheme defined in RFC 7617, operating over an HTTPS transport layer.

In this model, the client manually provides a username and password, and these credentials are sent to the CEP or CES web service over HTTPS for validation. The service then checks those credentials against Active Directory to confirm the identity of the user before allowing access to enrollment policy or certificate enrollment functions.

Following is the step-by-step breakdown of how Username/ Password authentication works

• Client takes the username and password and Base64-encodes them in the format username: password
• Encoded credential is placed in the HTTP Basic Authorization header
• Entire request travels over HTTPS; TLS is the only protection for the credentials in transit. Critical point: Base64 is encoding, not encryption. Without HTTPS, the credentials are completely exposed
• CEP extracts and decodes the Authorization header. Passes the raw username and password to Active Directory for validation via LDAP bind
• AD checks:
  1. Is the account valid and active?
  2. Is the password correct?
  3. Is the account unlocked and not expired?
• If the username and password validation fail, CEP immediately rejects the request and returns an HTTP 401 Unauthorized response, meaning the client is not allowed to continue.
• If the authentication succeeds, CEP accepts the identity, evaluates what certificate enrollment policy applies to that user or machine, and then returns the enrollment policy details back to the client.
• When the client sends the certificate request (CSR) to CES, it must provide its credentials again because CES does not rely on or inherit the earlier authentication done by CEP
• CES performs its independent validation against Active Directory using the same username/password authentication process.
• Once the identity is confirmed, CES goes a step further and checks whether that user or machine has Enroll permission on the requested certificate template and whether the request itself matches the template requirements, such as the correct subject format or allowed cryptography.
• If any of these checks fail, CES rejects the request. If they pass, CES accepts the request and forwards it to the Certification Authority on the client’s behalf.

This method is more flexible for remote users, internet-based systems, partner devices, and non-domain-joined machines, but it is also less secure than Kerberos because it depends directly on passwords. Even though the credentials are protected in transit by TLS, the security still relies on strong password practices, secure endpoint handling, and careful IIS configuration. In simple terms, username/password authentication is the practical fallback for CEP/CES when Kerberos cannot be used, but it requires more caution because it introduces direct credential handling into the certificate enrollment process.

When to Use Username/Password?

Deploy Username/ Password authentication for CEP and CES when:

• Enrolling clients are not domain-joined — workgroup machines, contractor devices, IoT endpoints
• You need cross-forest or cross-organization enrollment without Kerberos trust
• Clients cannot reliably reach a Domain Controller at enrollment time
• You are supporting internet-facing enrollment for remote and mobile devices
• The deployment is a PKIaaS or managed PKI scenario serving externally managed clients
• You need to support non-Windows platforms requiring certificate enrollment
• Kerberos infrastructure is unavailable or impractical in the target environment

Certificate-Based Authentication: The Third Option for Renewal

Certificate-based authentication is the third authentication option available with CES, and it is mainly used for certificate renewal, not for first-time enrollment. In this method, the client does not authenticate with Kerberos or a username and password. Instead, it proves its identity by presenting its existing valid certificate to CES during the renewal request. CES then validates that certificate by checking whether it is trusted, whether it is still valid, whether it chains to a trusted CA, and whether it matches the identity that is attempting the renewal. If the certificate passes validation, CES accepts that certificate as proof of identity and allows the renewal request to continue.

This approach is useful because it avoids sending passwords and does not depend on the client having Kerberos connectivity to a Domain Controller. It is especially valuable for remote or non-domain-connected systems that already have a certificate and simply need to renew it. However, this method is generally limited to renewal scenarios because the client must already possess a valid certificate to authenticate in the first place. In simple terms, certificate-based authentication lets the existing certificate act as the client’s identity proof, making it a secure and efficient option for renewing certificates through CES.

Note: Auto-enrollment using CEP and CES works seamlessly when the PKI is deployed on-premises and fully integrated with Active Directory. However, when the PKI is delivered as a managed service, and the Certification Authority resides outside the organization’s network boundary, the question is: how can devices securely enroll for certificates from a CA that they cannot directly access?

Key Capabilities of the PKIaaS

• Seamless AD Integration: The Enrollment Gateway integrates with your existing Active Directory infrastructure. Your Group Policy auto-enrollment configuration points to the Gateway endpoint rather than an on-premises CES URL. Domain-joined machines continue to enroll using Kerberos authentication; nothing changes from the endpoint perspective.
• Support for Non-Domain and Remote Devices: The Enrollment Gateway supports username/password authentication for non-domain-joined devices, remote endpoints, cloud workloads, and any device that cannot use Kerberos. This gives you a single enrollment gateway that serves your entire device fleet, domain, and non-domain alike.
• Zero Exposure of CA Infrastructure: Because the Enrollment Gateway acts as the broker, your devices never communicate directly with the Encryption Consulting CA infrastructure. The CA remains completely protected behind the Gateway’s authentication and authorization layer. This is the same zero-exposure principle that makes CES architecturally secure, applied to a fully managed PKIaaS environment.
• Certificate Lifecycle Visibility: Every enrollment transaction through the Encryption Consulting Enrollment Gateway is logged, tracked, and fed into the certificate lifecycle management layer. You get visibility into every certificate issued, every renewal processed, and every enrollment failure, without running any of the infrastructure yourself.
• Scalability Without Capacity Planning: Whether you are enrolling certificates for 500 devices or 500,000 devices, the Enrollment Gateway scales to match demand without requiring your team to provision, size, or manage enrollment infrastructure.
• Compliance-Ready Audit Trail: Every enrollment transaction is logged with full auditability, requester identity, authentication method, template used, CA response, timestamp, and outcome. This supports PKI-related compliance requirements across frameworks, including SOC 2, ISO 27001, FedRAMP, HIPAA, and PCI DSS.

The Business Case: Build It Yourself vs EC PKIaaS with Enrollment Gateway

Consideration	DIY CEP/CES On-Premises	Encryption Consulting PKIaaS + Enrollment Gateway
Internal PKI Expertise Required	High, requires deep AD CS and PKI knowledge	Minimal expertise provided by Encryption Consulting
CA Infrastructure Management	Managed by the internal team	Fully managed by Encryption Consulting
HSM Management	Your hardware, your key ceremonies	Managed by Encryption Consulting
Certificate Template Maintenance	Manual and often overlooked	Managed and periodically reviewed
Auto-Enrollment for Remote Devices	Complex CEP/CES setup required	Built-in via Enrollment Gateway
Certificate Lifecycle Visibility	Manual tracking or third-party tools are needed	Included within the PKIaaS platform
Compliance Documentation	Created and maintained internally	Provided and maintained by Encryption Consulting
Scaling	Requires additional infrastructure investment	Elastic and scales automatically
Algorithm Migration (e.g., RSA to PQC)	Manual updates to templates and CA	Proactively managed
Single Point of Accountability	Distributed across IT teams	Centralized, owned by Encryption Consulting

How Encryption Consulting can Help?

With deep hands-on expertise across enterprise PKI design, HSM management, certificate lifecycle automation, and compliance frameworks, Encryption Consulting has built and managed PKI environments for organizations ranging from mid-market enterprises to large-scale regulated industries, including finance, healthcare, and government.

Here is where Encryption Consulting’s PKIaaS offering addresses the specific technical challenge. This is precisely the gap that the Encryption Consulting PKIaaS Enrollment Gateway fills.

The Encryption Consulting PKIaaS Enrollment Gateway is a purpose-built enrollment broker service that operates as the authenticated intermediary between your enrolled devices and the Encryption Consulting-managed CA infrastructure. Functionally, it performs the enrollment brokering role, accepting certificate requests from your devices, authenticating them, and forwarding them to the appropriate CA on your behalf.

Think of it as the enrollment translation layer between your existing Active Directory and Group Policy auto-enrollment infrastructure and the externally managed PKIaaS CA, without requiring you to replace or redesign any of your existing enrollment workflows.

For your devices and your IT team, enrollment works exactly the same way it always has. Domain-joined machines auto-enroll via Group Policy. Non-domain devices enroll using their configured method. Certificates appear in the right certificate stores automatically. Renewals happen silently before expiry.

Behind the scenes, the Enrollment Gateway handles all the complexity — routing requests to the correct Encryption Consulting-managed issuing CA, enforcing authentication and authorization policy, returning results to clients, and feeding telemetry back into the certificate lifecycle management platform.

Conclusion

CEP and CES are essential components of any modern enterprise PKI, not optional ones. Every organization today has devices operating outside the corporate network boundary, and without CEP and CES, certificate auto-enrollment simply cannot function for those systems.

In domain environments, Kerberos remains the gold standard for authentication, offering secure, seamless access without exposing credentials, supporting mutual authentication, machine identities, and full Group Policy-based auto-enrollment. For domain-joined devices, there is no practical or security-based reason to use an alternative. At the same time, username/password authentication plays a critical and valid role in scenarios where Kerberos cannot be used, such as non-domain devices, cross-forest access, PKIaaS environments, or internet-facing enrollment. The correct approach is not to avoid it, but to implement it securely with strong controls like dedicated low-privilege accounts, enforced TLS, web application firewall protection, and proper monitoring.

While setting up a CA may be straightforward, operating PKI at scale, handling lifecycle management, compliance, algorithm transitions, and seamless enrollment across all device types requires ongoing expertise that many organizations cannot justify maintaining. Encryption Consulting’s PKIaaS and Enrollment Gateway address this by delivering enterprise-grade PKI with minimal operational burden, ensuring that certificates renew automatically, systems remain highly available, and organizations do not need dedicated PKI specialists to keep everything running smoothly.