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!

Abstract

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.

Dependencies

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.

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:

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:

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:

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.

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:

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:

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.