Active Directory Certificate Services (ADCS) is one of the most widely deployed Public Key Infrastructure (PKI) solutions in the enterprise world. While most organizations interact with ADCS through the Windows UI or PowerShell, the protocol layer underneath Microsoft’s published Open Specifications is where the real technical story lives. Understanding these protocols is critical for architects, security engineers, developers building PKI-integrated tools, and security professionals assessing vulnerabilities in certificate infrastructure.
This guide provides a comprehensive, practitioner-focused breakdown of every major ADCS Open Protocol specification, how they relate to one another, and what each one means for your PKI security posture.
What are Microsoft Open Specifications?
In the year 2008, Microsoft launched the Open Specifications program, a publicly accessible documentation library containing detailed technical specifications for Windows protocols and extensions. The goal was to enable third-party developers to build clients and servers that are fully interoperable with Microsoft’s products.
The Open Specifications library contains hundreds of documents covering Windows Protocols, Microsoft Office extensions, and more. For ADCS specifically, these documents represent the most authoritative and actively maintained technical reference available, in many cases superseding older TechNet content that was deprecated during Microsoft’s transition to a unified docs portal around 2015-2016.
The ADCS Open Protocol Landscape
The MS-CERSOD document (Certificate Services Protocols Overview) serves as the master index for all ADCS-related protocol specifications. It organizes ADCS functionality into two distinct groups:
- Certificate Enrollment Protocols: How clients request, receive, and renew certificates
- CA Administration Protocols: How administrators manage and operate the CA
Certificate Enrollment Protocols
1. MS-WCCE -Windows Client Certificate Enrollment Protocol
MS-WCCE is the foundational ADCS enrollment protocol and the one most deeply embedded in domain-joined Windows environments. It defines a set of DCOM (Distributed Component Object Model) interfaces that allow a client to communicate directly with a Certification Authority to:
- Request new X.509 certificates
- Renew existing certificates
- Retrieve CA properties and capabilities
- Obtain revocation status information
Core Architecture
MS-WCCE is built on two successive DCOM interfaces: ICertRequestD and ICertRequestD2. These interfaces expose a simple request-response model. The client submits a certificate request (in PKCS #10, CMC, or PKCS #7 format) and the CA responds with either a signed certificate or a detailed disposition explaining why the request was denied or placed in pending status.
Transport
MS-WCCE uses RPC/DCOM over TCP. This means it requires network connectivity to the CA on RPC dynamic ports and is inherently tied to Active Directory domain membership. The policy server in an MS-WCCE enrollment scenario is always a domain controller.
Security Relevance
Because MS-WCCE leverages DCOM and Active Directory, it is the attack surface for several well-known Enterprise Security Certificate (ESC) privilege escalation techniques. Misconfigurations in certificate templates (template ACLs, EKU settings, enrollment agent permissions) can allow an attacker to abuse the MS-WCCE flow to obtain certificates for highly privileged accounts.
2. MS-ICPR -ICertPassage Remote Protocol
MS-ICPR is closely related to MS-WCCE and also uses DCOM/RPC. It exposes the ICertPassage interface, a simpler, lower-level interface used for direct certificate request submission to a CA without the richer enrollment intelligence built into MS-WCCE.
MS-ICPR is primarily used in programmatic certificate request scenarios, and it surfaces as a distinct DCOM endpoint on the CA. It is also relevant in certificate relay attack scenarios (such as ESC8 and related techniques) because it provides an authenticated channel to request certificates.
3. MS-XCEP -X.509 Certificate Enrollment Policy Protocol
MS-XCEP is the protocol that powers the Certificate Enrollment Policy Web Service (CEP) role in ADCS. It enables clients to retrieve certificate enrollment policy information over HTTP/HTTPS using SOAP-based messaging -without requiring direct DCOM connectivity to the CA.
How it Works
The client sends a GetPolicies request to the CEP endpoint. The server responds with a GetPoliciesResponse containing: a collection of certificate enrollment policy objects describing available certificate templates, a list of certificate issuers (CES servers) the client should contact for each template, and the authentication method to use for each issuer (Kerberos, username/password, or certificate).
Authentication Options
- Kerberos (for domain-joined devices)
- Username/Password (for non-domain devices authenticating with domain credentials)
- Retrieve CA properties and capabilities
4. MS-WSTEP -Web Services Trust Enrollment Protocol
Where MS-XCEP handles policy discovery, MS-WSTEP handles the actual certificate issuance. It powers the Certificate Enrollment Web Service (CES) role in ADCS. Together, MS-XCEP and MS-WSTEP form the web-services-based enrollment stack that complements, and in many scenarios replaces, the RPC/DCOM stack used by MS-WCCE.
Protocol Characteristics
- Based on WS-Trust (a WS-* security standard), extended with Microsoft-specific capabilities
- Communicates over HTTPS using SOAP messages
- Supports certificate requests in PKCS #10 and CMC format
- Enables end-to-end encrypted certificate enrollment without RPC port exposure
Common Deployment Scenarios
| Scenario | Protocol Used | Transport | Role Service |
|---|---|---|---|
| Domain-joined Windows client (on-prem) | MS-WCCE or MS-XCEP + MS-WSTEP | RPC/DCOM or HTTPS | CA / CES |
| Non-domain device with domain credentials | MS-XCEP + MS-WSTEP | HTTPS/SOAP | CEP + CES |
| Certificate renewal over the internet | MS-XCEP + MS-WSTEP (cert-based auth) | HTTPS/SOAP | CEP + CES |
| Network device enrollment (NDES) | SCEP over HTTP/HTTPS | HTTP/HTTPS | NDES |
| Browser-based enrollment | CAWE (CA Web Enrollment) | HTTPS | CA Web Enrollment |
Security Note
The web-services stack (MS-XCEP + MS-WSTEP) is commonly deployed facing the internet or DMZ segments. Proper authentication hardening, TLS configuration, and network segmentation are critical. ESC8-style relay attacks can also target HTTP-based CES endpoints if they are not configured to require HTTPS and Extended Protection for Authentication (EPA).
5. MS-CAESO – Certificate Autoenrollment Protocol (Archived)
MS-CAESO was the original protocol governing certificate autoenrollment in Windows environments -the automatic enrollment and renewal of certificates for domain users and computers based on Group Policy. This specification has been archived, as its core functionality has been folded into the MS-WCCE and MS-XCEP/MS-WSTEP specifications.
Understanding MS-CAESO is still valuable for organizations running older Windows environments or auditing legacy PKI configurations.
Certificate Template and Policy Specifications
6. MS-CRTD – Certificate Templates Description
Certificate templates are the heart of enterprise ADCS deployments. They define what certificates can be issued, to whom, under what conditions, and with what key usage extensions. MS-CRTD specifies the exact structure, attributes, and encoding of certificate template objects as they are stored in Active Directory.
What MS-CRTD Covers
- The schema of certificate template objects in Active Directory (object class, attribute names, OIDs)
- The encoding of Extended Key Usage (EKU) policies within templates
- Issuance policies, subject name settings, enrollment permissions, and security descriptors
- Version 1 vs Version 2 vs Version 3 template schema differences
- The relationship between template attributes and the resulting certificate fields
Why This Matters for Security
Understanding MS-CRTD is foundational for auditing certificate template misconfigurations -the root cause of most ADCS-related privilege escalation attacks (ESC1 through ESC15). The recently disclosed ESC15 vulnerability (CVE-2024-49019) specifically involved exploitation of Version 1 schema template behavior, underscoring why deep knowledge of MS-CRTD is a security prerequisite.
CA Administration Protocols
7. MS-CSRA -Certificate Services Remote Administration Protocol
MS-CSRA defines the DCOM interfaces used to remotely administer a Certification Authority. It is the protocol behind the Certification Authority MMC snap-in, the certutil.exe tool, and programmatic CA administration through Windows APIs.
Administrative Operations Covered
- Starting and stopping the CA service
- Viewing, approving, denying, and revoking pending certificate requests
- Managing the certificate revocation list (CRL) and CRL distribution points (CDPs)
- Configuring CA properties (key algorithms, CRL schedules, audit settings)
- Backing up and restoring the CA database
- Querying the CA database for issued, pending, failed, and revoked certificates
MS-CSRA exposes several COM interfaces, including ICertAdmin, ICertAdmin2, ICertView, ICertView2, and IEnumCERTVIEWROW. Remote CA administration via MS-CSRA requires membership in the CA Administrator or Certificate Manager roles. Misconfigured CA role assignments represent a significant privilege escalation risk.
8. MS-OCSPA -Online Responder Administration Protocol
The Online Certificate Status Protocol (OCSP) responder is a key component of modern PKI infrastructure. Rather than requiring clients to download and parse large CRL files, OCSP enables real-time certificate revocation checking with a simple request-response mechanism.
MS-OCSPA defines the DCOM interfaces used to administer the Microsoft OCSP responder (the Online Responder role service in ADCS), including configuring OCSP revocation providers, managing OCSP signing certificates and their automatic renewal, monitoring OCSP responder health and cache state, and configuring refresh intervals for revocation data.
Operational Best Practices
- OCSP responders should be configured with dedicated, short-lived signing certificates (not the CA certificate itself)
- OCSP stapling should be enabled on web servers to reduce OCSP traffic and improve performance
- Multiple OCSP responders behind a load balancer improve availability and eliminate single points of failure
ADCS Enrollment Beyond Open Specs: NDES/SCEP and Modern Protocols
While the Microsoft Open Specifications cover the native Windows enrollment protocols, ADCS also supports enrollment via Simple Certificate Enrollment Protocol (SCEP) through the Network Device Enrollment Service (NDES) role.
NDES and SCEP
The SCEP enables network devices – routers, switches, VPN gateways, IoT devices – that cannot participate in a Windows domain to request certificates from an ADCS CA. NDES acts as a Registration Authority between the device and the CA, validating enrollment requests using a challenge password mechanism. SCEP is defined by an IETF standard (RFC 8894) and is widely supported by network device vendors and MDM platforms.
What ADCS Does Not Natively Support
ACME (RFC 8555): ADCS does not natively implement the ACME protocol. ACME is the standard used by Let’s Encrypt and increasingly required for modern DevOps and cloud-native environments. Third-party solutions can bridge ADCS to ACME-compliant clients.
EST (RFC 7030): Not natively supported in ADCS; EST is a more modern alternative to SCEP for constrained devices and is increasingly deployed alongside IoT PKI programs.
REST/JSON API: ADCS exposes no native REST API. Interaction is through DCOM, SOAP, or the CryptoAPI/CertEnroll COM interfaces.
Security Implications of ADCS Open Protocols
Knowledge of the ADCS protocol layer has become a security prerequisite, not just a developer concern. ESC vulnerabilities have entered mainstream security awareness, with ESC1, ESC2, ESC3, ESC6, ESC8, and ESC15 documented and weaponized. The table below maps each vulnerability to its protocol layer.
| Vulenrability | Protocol Layer | Root Cause | Notes |
|---|---|---|---|
| ESC1 | MS-WCCE + MS-CRTD | Template allows requester to supply arbitrary Subject Name | High-impact; widely exploited |
| ESC2 | MS-WCCE + MS-CRTD | Template has Any Purpose EKU or no EKU restriction | Broad certificate abuse potential |
| ESC3 | MS-WCCE + MS-CRTD | Enrollment agent abuse via Certificate Request Agent EKU | Two-stage attack chain |
| ESC6 | MS-WCCE | EDITF_ATTRIBUTESUBJECTALTNAME2 flag enabled on CA | CA-level flag, not template-level |
| ESC8 | MS-WSTEP / HTTP CES | NTLM relay to HTTP-based CES endpoint | Relay attack; requires HTTP (not HTTPS) |
| ESC15 | MS-CRTD (V1 templates) | Arbitrary application policy injection in V1 schema templates | CVE-2024-49019; patch required |
Practical Guidance: Using Open Specifications in Your PKI Program
For PKI Architects
- Use MS-CERSOD as the authoritative reference for designing enrollment architectures, especially in hybrid cloud or internet-facing scenarios
- Use MS-XCEP + MS-WSTEP to design enrollment flows for non-domain devices, cloud workloads, and remote users
- Reference MS-CRTD when designing new certificate templates to ensure attribute settings match your intended security policy
For Security Engineers
- Map your ADCS configuration against MS-CRTD to identify template attribute misconfigurations that correspond to ESC conditions
- Review CA role assignments against MS-CSRA to ensure the CA administration surface is minimally exposed
- Ensure all CES endpoints (MS-WSTEP) require HTTPS and Extended Protection for Authentication (EPA) to prevent relay attacks
For Developers
- Implement custom enrollment clients using the DCOM interfaces defined in MS-WCCE and MS-ICPR for domain environments
- Use MS-XCEP + MS-WSTEP SOAP interfaces for cross-platform or web-based enrollment applications
- Reference MS-CSRA for building CA monitoring, auditing, or lifecycle management tooling
For Compliance and Audit Teams
- The Open Specifications provide protocol-level evidence for compliance attestations (FIPS, Common Criteria, FedRAMP) regarding how certificates are issued and managed
- Use MS-CSRA capabilities to build automated certificate inventory and lifecycle monitoring -critical for audit readiness
How Encryption Consulting Can Help
Encryption Consulting specializes in PKI strategy, ADCS architecture, and certificate lifecycle management for enterprise and government organizations. Whether you are deploying ADCS for the first time, modernizing a legacy PKI, assessing your certificate infrastructure for ESC vulnerabilities, or integrating ADCS with modern DevOps tooling, our team brings deep protocol-level expertise to every engagement.
- PKI Health Assessments: Protocol-level audits of your ADCS environment against Microsoft Open Specifications and security hardening benchmarks
- ADCS Architecture Design: Enrollment stack design (MS-WCCE, MS-XCEP/MS-WSTEP, NDES/SCEP), CA hierarchy planning, and certificate template governance
- Certificate Lifecycle Management: Automated discovery, monitoring, and renewal of certificates across your enterprise
- Security Hardening: Remediation of ESC misconfigurations, CA role hardening, and CRL/OCSP infrastructure optimization
Conclusion
The Microsoft Open Specifications for ADCS are far more than developer reference material. They are the definitive technical foundation for understanding how certificates are requested, issued, administered, and revoked across your enterprise. As the ESC vulnerability landscape has made clear, gaps in protocol-level knowledge translate directly into exploitable security weaknesses.
Whether you are designing a new enrollment architecture, hardening an existing CA deployment, building PKI-integrated tooling, or conducting a security assessment, fluency with MS-WCCE, MS-XCEP, MS-WSTEP, MS-CRTD, MS-CSRA, and their peers is no longer optional. A well-governed ADCS environment is not just a matter of correct configuration. It requires a deep understanding of the protocols that govern every interaction between clients, CAs, and the certificates they issue. Investing in that knowledge today is the most reliable way to stay ahead of tomorrow’s certificate infrastructure threats.
