Hello, everyone! Today I’m starting a new community whitepaper publication on certificate autoenrollment in Windows 10 and Windows Server 2016. This is a deeply reworked version of the whitepaper published 15 years ago by David B. Cross: Certificate Autoenrollment in Windows XP. Certificate enrollment and autoenrollment was significantly changed since original whitepaper publication. Unfortunately, no efforts were made by Microsoft or community to update the topic. So I put some efforts in exploring the subject and writing a brand-new whitepaper-style document that will cover and reflect all recent changes in certificate autoenrollment subject.

This whitepaper is a structured compilation of a large number of Microsoft official documents and articles from TechNet and MSDN sites. Full reference document list and full-featured printable PDF version will be provided in the last post of this series.

Whitepaper uses the following structure:

  • Certificate enrollment architecture
  • Certificate autoenrollment architecture
  • The autoenrollment process and task sequence
  • Autoenrollment configuration
  • Certificate autoenrollment in action
  • Advanced features
  • Troubleshooting

First post of the series will cover only general questions and certificate enrollment architecture. It is important to understand how certificate enrollment works in modern Windows operating systems, because autoenrollment heavily relies on this architecture. So, let’s start!

Windows Server 2016 logo


Provides a technical reference and planning guide for PKI administrators who wish to utilize automatic certificate deployment on Windows-based clients and servers.

This article is intended for IT managers and system administrators. It provides a technical walkthrough of the certificate autoenrollment feature, along with an in-depth explanation of how this feature works and key troubleshooting information.

Applies to

This whitepaper is written against Windows 10 and Windows Server 2016 Windows Operating Systems. The following operating systems are applicable too if not specified otherwise:

  • Windows 7
  • Windows Server 2008 R2
  • Windows 8
  • Windows Server 2012
  • Windows 8.1
  • Windows Server 2012 R2

About this guide

This document provides an in-depth description of certificate autoenrollment feature integrated in Windows 10 and Windows Server 2016 operating systems.

Target audience

  • Administrators or IT operations engineers responsible for implementing and managing certificate services and certificate clients.
  • Administrators or IT operations engineers responsible for the day-to-day management and troubleshooting of networks, servers, client computers, operating systems, or applications.
  • IT operations managers accountable for network and server management.
  • IT architects responsible for computer management and security throughout an organization.

Certificate Autoenrollment Overview

Many systems and protocols they implement require digital certificates to operate. Those systems usually do not specify how their certificates are obtained. As long as a valid certificate for enrollment is available the server will use that certificate. Certificates have a certain lifetime and will eventually face expiration. Obtaining or renewing certificates is a burden on the server administrator. Computer certificate autoenrollment takes this burden away from the server administrator by automating certificate enrollment and renewal for server certificates.

Certificate autoenrollment was first introduced in Windows 2000 and greatly enhanced over the time by adding new features and usage scenarios. Windows 10 and Windows Server 2016 support the capability to automatically enroll users and computers for certificates including TPM and smart card-based certificates.

Using the autoenrollment feature, organizations can manage the certificate lifecycle for users and computers, which includes but not limited to:

  • Certificate enrollment and automatic renewal
  • Pending request retrieval
  • Local certificate store management
  • Superseding of certificates

    · Multiple signature requirements

Certificate autoenrollment is based on the combination of Group Policy settings and version 2 (or higher) certificate templates. This combination allows the Windows client to enroll users when they log on to their domain, or a machine when it boots, and keeps them periodically updated between these events.

Automatic enrollment of user certificates provides a quick and simple way to issue certificates to users and to enable public key infrastructure (PKI) applications, such as smart card logon, Encrypting File System (EFS), Secure Sockets Layer (SSL), Secure/Multipurpose Internet Mail Extension (S/MIME), and others. User autoenrollment minimizes the high cost of normal PKI deployments and reduces the total cost of ownership (TCO) for a PKI implementation when Windows clients are configured to use Active Directory.

Certificate autoenrollment evolution

The following table outlines the most important features added to autoenrollment feature over the time. This table will help administrators to identify notable features supported by particular operating system family.

Operating system

Key Features

Windows 2000 Professional

Windows 2000 Server

  • Automatic Certificate Request (ACR) introduced. ACR supports only unmanaged (version 1) computer certificate templates. No user certificate templates supported

Windows XP Professional

Windows Server 2003

  • Managed certificate template (version 2) support
  • Computer and user certificate autoenrollment based on version 2 templates

Windows Vista Business

Windows Server 2008

  • Brand new Cryptography Next Generation (CNG) cryptographic stack and rich CertEnroll application programming interfaces
  • Version 3 certificate templates that support CNG cryptography
  • Private key access control list (ACL) management with certificate template and autoenrollment
  • Autoenrollment timing changed from GPO update to system tasks in Task Scheduler

Windows 7 Professional

Windows Server 2008 R2

  • Active Directory Certificate Services Web Services (ADCS-WS) and WSTEP enrollment stack introduced
  • Workgroup environment support for certificate enrollment and autoenrollment
  • Cross-forest certificate enrollment support
  • Short-lived certificate support without writing them to CA database

Windows 8 Pro

Windows Server 2012

  • Version 4 certificate templates with key-based renewal
  • Renewal with same key (key pair reuse)
  • Desired issuance policies can be provided in the request
  • Additional certificate stores can be updated by autoenrollment
  • Automatic certificate renewal by including subject in the request from renewal certificate. Allows to automatically renew certificate when certificate template requires subject information in the request

Windows 8.1 Pro

Windows Server 2012 R2

  • Version 4 certificate templates with key attestation and TPM support
  • Automatic SSL certificate re-bind in IIS when certificate automatically renewed using autoenrollment

Windows 10 Pro

Windows Server 2016

  • Certificate transparency (CT) support


The autoenrollment feature has several infrastructure requirements. These include:

  • Windows Server 2008 R2 (or higher) Active Directory schema and Group Policy updates;
  • Windows Server 2008 R2 (or higher) domain controllers;
  • Windows 7 (or newer) or Windows Server 2008 R2 (or newer) clients;
  • Windows Server 2008 R2 (or higher) running as an Enterprise CA.

Additional requirements are applied to support autoenrollment feature on clients that are not joined to Active Directory domain:

  • Windows Server 2008 R2 (or higher) or [MS-XCEP] compatible server running as Certificate Enrollment Policy service;
  • Windows Server 2008 R2 (or higher) or [MS-WSTEP] compatible server running as Certificate Enrollment Server service.

The Certificate Enrollment Architecture

In order to understand automatic certificate enrollment, it is required to understand certificate enrollment in general as described in this section. At the very abstract level and as illustrated in the following diagram, the administrator enters a policy as a machine-readable certificate enrollment policy (CEP) stored in a policy server.

The CEP is made available from the policy server to certificate enrollment clients, which consume this CEP to determine which certificates the client is supposed to have and which issuers are available to provide those certificates. Clients then create certificate requests and submit them to issuers that issue certificates back to the clients.

Certificate enrollment architecture
Figure 1: Certificate enrollment architecture

Microsoft Windows 10 and Windows Server 2016 support two enrollment protocol stacks.

The first stack, named WCCE, was originally introduced in Windows 2000 and uses Windows Client Certificate Enrollment Protocol [MS-WCCE] for certificate requests. It uses the LDAP to obtain a CEP from a domain controller (DC). Finally, the CEP is expressed via certificate template structures specified in [MS-CRTD] and certification authority (CA) information. This stack is supported by all Windows operating systems starting with Windows 2000 and is supported by all modern Windows operating systems, including Windows 10 and Windows Server 2016. The following figure illustrates the enrollment process using WCCE stack:

Certificate requests using WCCE enrollment stack
Figure 2: Certificate requests using WCCE enrollment stack

Figure 2 outlines the WCCE enrollment architecture, where domain controller acts as policy server and client uses LDAP to retrieve enrollment policy from domain controller. Client then uses this policy to determine available certificate templates and certification authorities. Certificate enrollment client uses this information to determine which certificates should be requested and/or renewed. WCCE stack uses RPC/DCOM to communicate with CA server. Although, WCCE stack is pretty simple and requires minimum administrative efforts, its simplicity leads to a number of major limitations:

  • The computer can be a member of only single Active Directory domain at a time, thus only single WCCE enrollment policy can be configured on a client;
  • The certificate issuer (CA server) must be accessible to client via RPC/DCOM protocol;
  • WCCE stack is not available on workgroup computers.

With Windows 7 and Windows Server 2008 R2, a new certificate enrollment stack called XCEP was introduced. This stack does not necessary use Active Directory to retrieve CEPs and certificate templates and do not communicate with Certificate Issuer by using RPC/DCOM transport protocol. Instead, Windows client communicates with CEPs and Certificate Issuer by using [MS-XCEP] and [MS-WSTEP] protocols respectively. These protocols use HTTP/SOAP underlying transport:

Certificate requests using XCEP certificate enrollment stack
Figure 3: Certificate requests using XCEP certificate enrollment stack

Figure 3 outlines the XCEP enrollment architecture, where XCEP server acts as policy server and client uses HTTP/SOAP to retrieve enrollment policy from policy server by using [MS-XCEP] protocol. Client then uses this policy information to determine available certificate templates and certificate issuer endpoints. XCEP stack uses HTTP/SOAP to communicate with certificate issuers by using [MS-WSTEP] protocol.

Microsoft implements XCEP component in ADCS Certificate Enrollment Policy Service (CEP) and WSTEP in ADCS Certificate Enrollment Service (CES) server roles. More details on ADCS Web Services: Certificate Enrollment Web Services in Active Directory Certificate Services

As it is shown, there are no dependencies on Active Directory environment, thus XCEP enrollment stack leverages limitations of WCCE stack and allows the use of autoenrollment feature for workgroup computers (which are not parts of Active Directory domain). In addition, client computer can be configured with multiple enrollment policies, thus allowing to receive certificates from different certificate providers (WSTEP Server).

Computers starting with Windows 7 and Windows Server 2008 R2 can use both protocol stacks to enroll for certificates based on the same company policy. This process is shown in Figure 4:

Certificate enrollment requests using WCCE and XCEP certificate enrollment stacks
Figure 4: Certificate enrollment requests using WCCE and XCEP certificate enrollment stacks

A client computer starts by discovering a policy server. With WCCE enrollment stack, the policy server is always a domain controller. For the use of ADCS Web Services (ADCS-WS), the web service address has to be configured out of band (for example, manually or by Group Policy).

Certificate enrollment clients can use Group Policy to obtain policy server endpoints that were configured by the administrator in the enterprise. Clients can also use a local configuration store that contains policy server end points specific to a particular client. The following figure illustrates this concept.

Certificate enrollment using Group Policy
Figure 5: Certificate enrollment using Group Policy

Figure 5 shows the enrollment process in Active Directory domain with use of XCEP stack. XCEP server endpoints are configured by an administrator on domain controller through Group Policy. Client computer retrieves enrollment policies and XCEP server endpoints from domain controller.

Non-domain computers cannot use domain controllers to retrieve enrollment policies and XCEP server endpoints. Instead, they must be configured on client computer manually:

Certificate enrollment using local configuration
Figure 6: Certificate enrollment using local configuration

Computer administrator manually configures local configuration with enrollment policy and XCEP server endpoints. This can be done by using various ways, including local Group Policy, Certificates MMC snap-in, certutil.exe tool. The following diagram shows an example of one possible deployment:

Domain member client requesting certificate enrollment through a Group Policy deployment
Figure 7: Domain member client requesting certificate enrollment through a Group Policy deployment

XCEP server endpoints are normally obtained by client through Group Policy. Computer administrator may provide client-specific endpoints manually. Autoenrollment feature will use all endpoints available in the local configuration. XCEP endpoint configuration is outside the scope of this whitepaper.

Considering that any client can be configured to work with multiple CEPs where each CEP may have multiple policy server end points, can define multiple certificate templates, and are used by multiple issuers, it is clear that enrolling for certificates manually can be a difficult task. The job of autoenrollment is to traverse all of the CEPs and enroll for certificates as needed.

Share this article:


veit berwig

Hi Vadims,

we want to harden the smime-capabilities of a smime-certificate in an autoenrollment-process for a standard user in a MS-PKI environment. As a POC i had successfully created a test-certificate under "OpenSSL/XCA" with an extended ASN.1-encoded block of hardened smime-capablities (in direction to SMIME 4.0 with AES-GCM modes and ChaChaPoly1305 OIDs). This block was loaded into "XCA" for certificate-generation.

Now my question...

Where and how do i have to create or alter a new or existing cert-template in a MS-PKI environment in order to harden a new crypto-cascade into the smime-capabilities without RC2, RC4, 3DES, etc. ? For example the document [MS-CRTD] from "winprotocoldoc.blob.core.windows.net" does only mention the flag "CT_FLAG_INCLUDE_SYMMETRIC_ALGORITHMS" in a bit-field with a reference to the RFC 4262, but not if to encode or how to encode and where to alter/put the data in order to get an auto-enrollment-template with new "smime 4.0 like" hardened smime-capabilities (AD ?):


# smimeCapabilities=DER:30:81:86:  +-- length in byte (134 byte dec./(0x86))
#                    + ---------------- length in byte (0d: 13byte / 0f: 15byte / 0b: 11byte)
#                     |
# 12 Byte :30:0b:06:09:60:86:48:01:65:03:04:01:2e (2.16.840. aes256-GCM)
# 12 Byte :30:0b:06:09:60:86:48:01:65:03:04:01:1a (2.16.840. aes192-GCM)
# 12 Byte :30:0b:06:09:60:86:48:01:65:03:04:01:06 (2.16.840. aes128-GCM)
# 12 Byte :30:0b:06:09:60:86:48:01:65:03:04:01:2a (2.16.840. aes256-CBC)
# 12 Byte :30:0b:06:09:60:86:48:01:65:03:04:01:16 (2.16.840. aes192-CBC)
# 12 Byte :30:0b:06:09:60:86:48:01:65:03:04:01:02 (2.16.840. aes128-CBC)
# 14 Byte :30:0d:06:0b:2a:86:48:86:f7:0d:01:09:10:03:12 (1.2.840.113549. AEADChaCha20Poly1305)
# 12 Byte :30:0b:06:09:60:86:48:01:65:03:04:02:03 (2.16.840.  SHA2-512)
# 12 Byte :30:0b:06:09:60:86:48:01:65:03:04:02:02 (2.16.840.  SHA2-384)
# 12 Byte :30:0b:06:09:60:86:48:01:65:03:04:02:01 (2.16.840.  SHA2-256)
# 12 Byte :30:0b:06:09:60:86:48:01:65:03:04:02:04 (2.16.840.  SHA2-224)

Best regards ...

Vadims Podāns

I don't think there is such way. SMIME capabilities are generated by a client and depends on supported algorithms on this particular client. You may need to write your own policy module for ADCS in order to insert custom certificate extension.


This is great! Thank you, Vadims, for you contribution, your effort!

Bojan Zivkovic

Hi Vadim,

Can you help me out with cross-forest certificate enrollment (forests without a trust) with emphasis on auto-enrollment using Certificate Enrollment Policy Web Service/Certificate Enrollment Web Service? If full auto-enrollment (without any manual work) is not doable then we have to persuade InfoSec team to allow us two-way forest trust with selective authentication (in that case services above won't be needed obviously).

If you have time and patience I will send you technical details of what we want to accomplish. Complete guide on this is hard to find so any help from you would be highly appreciated. As we all know PKI is complex enough itself and this should be advanced PKI.

Thank you in advance.

Vadims Podāns

@Bojan, sorry, I'm not offering consulting services on my site. I suggest to ask your question on appropriate public forum (for example Windows Server Security Q&A).


Hello Vadim - 

I understand you don't do consulting on your site.  As for your excellent documentation available here, have you produced any documents on cross-forest auto-enrollent where there is a 2-way trust between the forest holding the enterprise CA and the client's forest?


Vadims Podāns

> have you produced any documents on cross-forest auto-enrollent where there is a 2-way trust between the forest holding the enterprise CA and the client's forest?

there is no need for such documentation. Cross-forest autoenrollment makes clients to think that CAs are located in their own forest. And autoenrollment is no exception and works in same way like CAs are located in home forest. 

Post your comment:

Please, solve this little equation and enter result below. Captcha