This is a third part of the Certificate Autoenrollment in Windows Server 2016 whitepaper. Other parts:

• Certificate Autoenrollment in Windows Server 2016 (part 1)
• Certificate Autoenrollment in Windows Server 2016 (part 2)
• Certificate Autoenrollment in Windows Server 2016 (part 3)

Configuring Advanced Features

This section discusses templates that require certificate manager approval, self-registration authority, and how to supersede a certificate template.

Requiring certificate manager approval

A specific certificate template can require that a certificate manager (CA officer) approve the request prior to the CA actually signing and issuing the certificate. This advanced security feature works in conjunction with autoenrollment and is enabled on the Issuance Requirements tab of a given certificate template (Figure 25). This setting overrides any pending setting on the CA itself.

This is a third part of the Certificate Autoenrollment in Windows Server 2016 whitepaper. Other parts:

• Certificate Autoenrollment in Windows Server 2016 (part 1)
• Certificate Autoenrollment in Windows Server 2016 (part 2)

Configuring Autoenrollment

Autoenrollment configuration in general consist of three steps: configure autoenrollment policy, prepare certificate templates and prepare certificate issuers. Each configuration step is described in next sections.

Configuring autoenrollment policy

The recommended way to configure autoenrollment policy is to use Group Policy feature. Group policy feature is available in both, domain and workgroups environments. This section provides information about autoenrollment configuration using Group Policy editor. It is recommended to turn on autoenrollment policy in both, user and computer configuration.

This is a second part of the Certificate Autoenrollment in Windows Server 2016 whitepaper. Other parts:

• Certificate Autoenrollment in Windows Server 2016 (part 1)

Certificate Autoenrollment Architecture

This section discusses the autoenrollment architecture, an analysis of the components of the autoenrollment process, and working with certificate authority interfaces.

Autoenrollment internal components

Autoenrollment consist of several components installed on each computer. Depending on environment (Active Directory or workgroup) some components may present or not present. The following diagram outlines autoenrollment components and their high-level interactions in both environments:

The meaning of each component is provided in next sections.

Group Policy client

This component is not available in workgroup environments.

Client module that is responsible for Group Policy retrieval and processing from domain controller, policy storage and policy maintenance on a local computer. Group Policy client updates local configuration with certificate enrollment policy (CEP) information.

Local configuration

System Registry storage that contains information about certificate enrollment policies (CEP). This information is then used to populate configuration for: Enrollment Policies, AE Options and Certificate Issuers components. Local configuration is stored in System Registry in HKLM and HKCU registry hives:

SOFTWARE\Policies\Microsoft\Cryptography\AutoEnrollment\

Enrollment Policies

Contains a collection of CEPs. In Active Directory environment, a LDAP domain policy is added by default. XCEP policies must be configured by an administrator in Group Policy on domain controllers (available only in Active Directory) and/or using local configuration tools. Each policy contains the following notable properties:

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 rewritten 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!

This article provides descriptional information about enterprise Certification Authority signing by commercial Certification Authority (sometimes, external root is referred as "common root").

What is Certification Authority Root Signing?

Consider the following scenario: You work for an organization that requires many digital certificates. You want to ensure that these certificates are trusted by other organizations, such as external partners and customers. For example, you might want to use a code signing certificate for an application or a digital signature certificate for signing a document or email.

If you setup your own public key infrastructure (PKI), also known as a private PKI, the certificates you issue will only be trusted internally. For example, you can publish the root certification authority certificate into your Active Directory Domain Service (AD DS) and quickly have your organization's computers trusting certificates issued by your PKI. However, external organizations, such as your customers and partners, would not (by default) trust the certificates issued by your PKI. This means they would see a validity or trust error messages, if they viewed or tried to validate a certificate issued by your PKI.

If instead, you subordinate your PKI to one of the commercial PKI root certificates that are trusted by Microsoft Windows installations, you do not have the same problem. By default, Microsoft Windows applications install a set of predefined root CA certificates (well known commercial root CAs), which certificates are trusted on any Windows installation by default. For example, if you access https://login.live.com/ web site, no additional actions are required from a user. This is because SSL certificate is issued by a trusted CA.

Contrarily, if a remote user tries to access a web site that utilizes SSL certificate from a private PKI, the user receives an error message indicating certificate trust issues. When a user application (like Internet Explorer) does not specifically trust a PKI, an error message is presented each time that private PKI's certificate is presented to the user.

To overcome such an issue, you may decide to implement a PKI that utilizes the trust of a well-known and trusted PKI. This allows your organization to issue certificates that can be trusted and recognized worldwide.