CES and CEP Web Enrollment: When and How to Use Them

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.

Quick Answer: What Are CES and CEP in AD CS?

CEP (Certificate Enrollment Policy Web Service) publishes enrollment policy over HTTPS using the MS-XCEP protocol. CES (Certificate Enrollment Web Service) processes certificate requests over HTTPS using the MS-WSTEP protocol, then connects to the issuing CA over DCOM. Together they extend AD CS enrollment to cloud workloads, DMZ servers, and workgroup systems that cannot reach the CA or Active Directory directly.

Key Takeaways

• CEP (MS-XCEP) and CES (MS-WSTEP) extend AD CS certificate enrollment over HTTPS to systems that cannot use traditional Group Policy autoenrollment. They are the correct solution for cloud workloads, DMZ and perimeter-network servers, workgroup systems, partner-managed devices, and cross-forest scenarios where direct CA or Active Directory connectivity is not available.
• The most common cause of CES enrollment failure is missing or incorrectly configured Kerberos constrained delegation on the CES service account. The service account must be delegated to the HOST service on the issuing CA computer account. Missing this delegation produces Event ID 86 on the CES server and silent enrollment failure for clients.
• CEP caches policy information. A newly published certificate template may not appear to enrollment clients immediately after publication. Restarting the CEP application pool forces a policy refresh. This is a frequent source of confusion during initial deployment and after template changes.
• The DigiCert Trust Pulse Survey (July 2025) found that 45 percent of enterprises experienced certificate-related downtime in the prior year. Systems that cannot automatically enroll or renew certificates are one of the primary sources of that downtime. CEP and CES address the enrollment gap for systems outside the traditional autoenrollment perimeter.
• CES and CEP support the post-quantum ML-DSA certificate algorithms added to AD CS on Windows Server 2025 in May 2026. Microsoft has outlined plans to extend ML-DSA support to CES, CEP, and other AD CS role services in future updates, making a correctly designed CES/CEP deployment part of the forward-compatible PKI architecture for post-quantum migration.

Who Should Care About CES and CEP Web Enrollment

CES and CEP are AD CS operations topics, but their security and compliance consequences reach every team that depends on certificates being issued, renewed, and tracked for systems outside the traditional autoenrollment perimeter.

Role	Why It Matters	Action Item
PKI Admins	Own the technical deployment: installing the CES and CEP role services, configuring the CES service account with Kerberos constrained delegation, binding the TLS certificate to the IIS endpoint, configuring template ACLs, and validating end-to-end enrollment; the most common deployment failure (missing constrained delegation) is invisible until a client attempts enrollment and gets a silent failure	Follow the deployment checklist: configure constrained delegation before installing CES; bind a CA-trusted TLS certificate to the enrollment IIS site before exposing it to clients; test enrollment end-to-end using certreq from a representative client before declaring the deployment operational; add all CES-enrolled certificates to CertSecure Manager inventory with expiry monitoring
Security Architects	Own the design decisions: authentication model selection (Kerberos for domain-joined clients, username/password or client certificate for non-domain-joined), network segmentation (whether CES should be in a DMZ with firewall rules limiting DCOM access to the internal CA), and FIPS 140-3 controls for the endpoint private keys; CES is a sensitive PKI component that can submit requests to the CA on behalf of any client that authenticates to it	Design the authentication model for each enrollment population before deploying; specify whether CES should be in a DMZ or on the internal network; require FIPS 140-3 Level 2 or higher HSM-backed key storage for the TLS certificate private key on the enrollment endpoint; include CES and CEP in the cryptographic inventory using CBOM Secure; plan CES/CEP for post-quantum ML-DSA compatibility through PQC Readiness assessment
Platform and Cloud Teams	Own publishing the CEP URL to non-domain-joined systems and integrating CES enrollment into cloud workload provisioning pipelines; cloud workloads in Azure, AWS, or co-location facilities need certificate enrollment through CES because Group Policy autoenrollment does not reach them; a cloud provisioning pipeline that does not integrate CES enrollment produces workloads that either operate without certificates or request them through ad hoc manual processes outside the managed inventory	Integrate CES enrollment into cloud workload provisioning pipelines; configure the CEP URL in the workload configuration management system; confirm firewall rules allow HTTPS access from cloud workloads to the CES endpoint on port 443; test enrollment from a representative cloud workload before production rollout; include cloud-workload certificate expiry in platform observability alerting
Compliance Teams	Must demonstrate that certificates issued through CES are logged and that the enrollment activity is auditable; NIST SP 800-53 Rev. 5 SC-17 requires PKI certificate issuance and management to be governed; certificates issued through CES to systems outside the traditional autoenrollment perimeter are frequently not included in compliance evidence because they are not visible to monitoring tools that cover only domain-joined systems	Confirm CES enrollment event logs and issuing CA audit logs are forwarded to SIEM; include CES-enrolled certificate populations in the quarterly certificate compliance evidence package; confirm that template ACL configuration is documented and reviewed quarterly; verify that CES-issued certificates appear in the CLM platform inventory alongside domain-joined certificates
CISOs	A CES deployment that issues certificates to cloud workloads and DMZ servers without CLM coverage creates invisible certificate populations that expire without renewal alerts; the DigiCert Trust Pulse Survey (July 2025) found that 45 percent of enterprises experienced certificate-related downtime and 56.6 percent rank certificate expiration among their top three concerns; CES and CEP extend the enrollment perimeter but also extend the certificate estate that must be governed and monitored	Require that any CES deployment includes CLM platform coverage for all issued certificates before go-live; mandate that CES service account delegation and template ACLs are reviewed quarterly as a PKI health control; evaluate PKI as a Service for organizations that need managed web enrollment without building and operating the CES/CEP infrastructure internally

CES and CEP Deployment Readiness Checklist: Prerequisite, Configuration, Validation, Common Error, and Owner

Use this checklist before and after deployment to confirm each prerequisite is met, the configuration step is complete, and the validation check passes. Common errors are listed so they can be diagnosed quickly rather than after a production enrollment failure.

Prerequisite / Step	Configuration	Validation Check	Common Error if Missing	Owner
IIS installed on the CES/CEP server	Install IIS and the Certificate Enrollment Policy Web Service and Certificate Enrollment Web Service role services via Server Manager or: Install-WindowsFeature ADCS-Enroll-Web-Pol, ADCS-Enroll-Web-Svc	Confirm the CES and CEP application pools exist in IIS Manager and are in Started state	Role installation failure if IIS is not present; application pool creation fails silently during role setup	PKI Admin
TLS certificate trusted by all enrollment clients bound to the IIS enrollment endpoint	Obtain a TLS certificate from the enterprise CA or a trusted public CA; bind it to the HTTPS 443 binding on the CES/CEP IIS site in IIS Manager; confirm the full chain (root and any intermediates) is in the certificate store	From an enrollment client, browse to the CEP HTTPS URL and confirm no certificate warning appears; verify the TLS chain using: certutil -verify -urlfetch [cert-file]	TLS handshake failure at the enrollment endpoint; clients receive certificate errors and the enrollment attempt fails before reaching the CES service; clients that self-signed or use a non-trusted CA will produce the same result	PKI Admin
CES service account created with Kerberos constrained delegation to the issuing CA	Create a dedicated domain service account for CES; in Active Directory Users and Computers, open the service account, select Delegation tab, choose Trust this user for delegation to specified services only (Kerberos only), add the issuing CA computer account HOST service; run setspn -S http/[CES-server-FQDN] [service-account] to register the SPN	From the CES server, run klist to confirm a Kerberos ticket is obtained for the issuing CA; test enrollment from a domain-joined client and confirm Event ID 6 (success) on the CES server	Event ID 86 on the CES server: The enrollment service cannot reach the certification authority; HTTP 500 from the CES endpoint; enrollment fails silently for the client	PKI Admin
Enroll (and Autoenroll) ACLs set on all templates accessible through CES	In the Certificate Templates console, open each template that CES will serve; on the Security tab, add the CES service account (or its enrollment security group) with Enroll permission; add Autoenroll for autoenrollment scenarios	From an enrollment client using the CES service account credentials, request a certificate for each template and confirm the request succeeds; check the issuing CA audit log for issuance events	HTTP 403 Forbidden on enrollment attempt; Event ID 80 on the CES server indicating access denied on the template; client receives a request denied error with no certificate issued	PKI Admin
CEP URL published to enrollment clients	For domain-joined clients: configure via Group Policy at Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client – Certificate Enrollment Policy; add the CEP HTTPS URL with the appropriate authentication type; for non-domain-joined clients: configure the CEP URL manually using certlm.msc or via MDM/configuration management	On an enrollment client, run: certutil -enrollmentpolicyserver to confirm the CEP URL is configured; request a certificate through the Certificates MMC snap-in and confirm the templates from the CES-hosted policy appear	Templates not visible to the client; enrollment policy not found error when the client attempts enrollment; clients fall back to direct LDAP policy if available, bypassing CES entirely	PKI Admin + Platform Team
DCOM ports open between CES server and issuing CA	Confirm network firewall rules allow TCP 135 (RPC endpoint mapper) and high-range dynamic TCP ports (49152-65535 by default, or a configured restricted range) from the CES server to the issuing CA server; alternatively configure a restricted DCOM port range on the CA and open only that range	From the CES server, run: portqry -n [CA-server] -e 135 to confirm the RPC endpoint mapper is reachable; test enrollment and confirm no DCOM connectivity errors in the CES event log	Event ID 86 on CES: cannot contact the CA; DCOM errors in the System event log on the CES server; enrollment failures that disappear after temporarily disabling the firewall (confirming firewall is the cause)	PKI Admin + Platform Team
CES-enrolled certificates added to CLM platform inventory	Configure CertSecure Manager to discover certificates from the issuing CA that were enrolled through CES; set renewal alerts for CES-issued certificates at 90, 60, and 30 days before expiry; confirm renewal workflows apply to CES-issued certificate populations	In CertSecure Manager, confirm all certificates issued through CES appear in the inventory with correct expiry dates, issuing CA, and owner metadata; confirm renewal alerts are active for certificates approaching expiry	CES-issued certificates not visible in CLM inventory; expiry events for cloud workloads and DMZ servers not detected until services fail; no renewal workflow in place for certificates that cannot use Group Policy autoenrollment	PKI Admin

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. For organizations building a complete cryptographic inventory that includes CES-enrolled device and workload certificates alongside TLS and other certificate types, CBOM Secure provides the cross-environment machine identity discovery that makes unified visibility possible.

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. For organizations building post-quantum readiness into their PKI architecture, PQC Readiness assessment services and the PQC Center of Excellence help organizations plan how ML-DSA algorithm adoption affects CES, CEP, and the broader AD CS deployment, so the PKI built today is forward-compatible with the post-quantum certificate infrastructure required tomorrow.

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.

Frequently Asked Questions

What is the main takeaway from CES and CEP Web Enrollment: When and How to Use Them?

CEP and CES extend Microsoft AD CS certificate enrollment over HTTPS to systems that cannot use traditional LDAP and RPC/DCOM-based autoenrollment. CEP (MS-XCEP) publishes enrollment policy. CES (MS-WSTEP) processes certificate requests and communicates with the issuing CA over DCOM on the client’s behalf. They enable enrollment for cloud workloads, DMZ servers, workgroup systems, and cross-forest scenarios without exposing the CA directly. The most common deployment failure is missing Kerberos constrained delegation on the CES service account, which produces Event ID 86 on the CES server.

Why does CES and CEP web enrollment matter for enterprise PKI teams?

As organizations expand into cloud and hybrid environments, systems outside the corporate network cannot reach AD CS using the LDAP, RPC, and DCOM protocols that domain-based enrollment relies on. CEP and CES provide a standards-based HTTPS enrollment path for these systems without requiring changes to the CA hierarchy. The DigiCert Trust Pulse Survey (July 2025) found that 45 percent of enterprises experienced certificate-related downtime in the prior year; systems that cannot automatically enroll or renew certificates are one of the primary sources of that downtime. CES and CEP also support the ML-DSA post-quantum certificate algorithms added to AD CS on Windows Server 2025 in May 2026.

What risks increase if CES and CEP deployment is handled incorrectly?

Three risk categories increase: enrollment failures (a misconfigured service account delegation, incorrect template ACLs, or an untrusted TLS certificate on the IIS endpoint causes silent enrollment failure with no certificate issued); security gaps (CES submits requests to the CA on behalf of clients; over-privileged service accounts or unrestricted template access allow unauthorized certificate requests to succeed without detection); and operational blind spots (without CLM coverage, expiry events for CES-enrolled cloud workloads and DMZ systems are invisible to the renewal monitoring that covers domain-joined systems).

Which teams should own CES and CEP deployment and governance?

PKI admins own the technical deployment: constrained delegation, TLS endpoint certificate, template ACLs, and end-to-end enrollment validation. Security architects own design decisions: authentication model, network segmentation, and FIPS 140-3 controls. Platform and cloud teams own publishing the CEP URL to non-domain-joined systems and integrating CES enrollment into cloud workload provisioning pipelines. Compliance teams own evidence that CES enrollment activity is logged and auditable. CISOs own the governance mandate that CES deployments include CLM platform coverage for all issued certificates.

How does CES and CEP web enrollment connect to certificate lifecycle management?

CEP and CES extend AD CS enrollment to systems that would otherwise fall outside the certificate lifecycle management perimeter. Without them, cloud workloads and DMZ servers request certificates through manual or ad hoc processes that produce certificates outside the managed inventory. CertSecure Manager provides the certificate discovery, inventory, and renewal monitoring layer that covers CES-enrolled certificates alongside domain-joined certificates, ensuring expiry alerts and renewal workflows apply to the full certificate estate.

How should organizations measure success in a CES and CEP deployment?

Key metrics: enrollment success rate (percentage of certificate requests submitted through CES that result in an issued certificate, target: zero unexplained enrollment failures); service account delegation validation (Kerberos constrained delegation on the CES service account confirmed correct, verified quarterly); template ACL compliance (all templates accessible through CES carry only the approved enrollment permissions, verified quarterly); TLS endpoint certificate expiry (the TLS certificate bound to the CES and CEP IIS endpoint has an active renewal alert and has not expired); and CLM inventory coverage (all CES-issued certificates appear in CertSecure Manager with expiry monitoring and renewal workflows active).

What should be audited or monitored regularly for CES and CEP?

Monitor continuously: CES and CEP IIS endpoint availability and TLS certificate validity; CES enrollment event logs for errors (Event ID 86 is the primary enrollment failure indicator); and issuing CA audit logs for enrollment events submitted through CES. Audit quarterly: verify Kerberos constrained delegation on the CES service account has not been changed; confirm template ACLs on all templates accessible through CES match the approved configuration; review CEP policy cache freshness; and confirm all CES-enrolled certificates appear in the CLM platform inventory with active expiry monitoring.

How does CES and CEP web enrollment affect cloud, hybrid, or multi-CA PKI environments?

In cloud and hybrid environments, CES and CEP are the primary mechanism for extending AD CS enrollment to workloads that cannot reach the CA or Active Directory directly. Cloud workloads in Azure, AWS, or co-location facilities need HTTPS enrollment through CES via a firewall rule on port 443 without exposing the CA to the internet. In multi-CA environments, each issuing CA requires its own CES instance with its own service account delegation and template ACL configuration. Cross-forest scenarios use username/password or client certificate authentication because Kerberos across forest boundaries requires additional trust configuration. CBOM Secure provides the cross-environment machine identity discovery needed for unified visibility over all CES-enrolled certificate populations.

What prerequisites are required before deploying CES and CEP?

Prerequisites: Windows Server 2008 R2 or later with AD CS installed and an issuing CA operational; IIS installed on the server hosting the CES and CEP endpoints; a valid TLS certificate trusted by all enrollment clients bound to the IIS endpoint (self-signed certificates cause enrollment failures on clients that do not trust the issuing chain); a dedicated service account for CES with Kerberos constrained delegation to the HOST service on the issuing CA computer account; Enroll ACLs on each certificate template that CES will process; network connectivity from the CES server to the issuing CA over DCOM (TCP 135 plus high-range dynamic ports); and for non-domain-joined or cross-forest clients, username/password or client certificate authentication configured on the CEP and CES endpoints.

What common errors should administrators watch for when deploying CES and CEP?

The most frequent errors: Event ID 86 on the CES server (CES service account cannot contact the issuing CA; verify Kerberos constrained delegation and DCOM connectivity on TCP 135 and high-range dynamic ports); HTTP 403 Forbidden on enrollment (client identity does not have Enroll permission on the requested template; verify template ACLs); newly published templates not visible to clients (CEP caches policy; restart the CEP application pool to force a policy refresh); TLS handshake failure at the enrollment endpoint (client does not trust the TLS certificate chain on the IIS endpoint; verify the root CA is in the client’s Trusted Root Certification Authorities store); and authentication failure for non-domain-joined clients (verify that username/password or client certificate authentication is enabled on the CEP and CES IIS application pools for the target client population).