Hello, S-1-1-0!

Today I’m going to talk about interesting subject about Enhanced Key Usage constraints in CA certificates. This question is inspired by a thread on Security StackExchange: Root CA with Extended Key Usage fields. I put a brief answer in that thread, but still feel it is incomplete. In this blog post I will try to explain the subject in more details. Let’s start!

Extended Key Usage definition

What is Extended Key Usage or simply EKU (Microsoft calls it Enhanced Key Usage, but they both share the same abbreviation)? RFC 5280 §4.2.1.12 says:

This extension indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension.

The meaning is quite clear. How it is processed (should be processed). Few paragraphs below (same section in RFC):

In general, this extension will appear only in end entity certificates.

<…>

If the extension is present, then the certificate MUST only be used for one of the purposes indicated. If multiple purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present. Certificate using applications MAY require that the extended key usage extension be present and that a particular purpose be indicated in order for the certificate to be acceptable to that application.

This part is clear too: applications verify if particular OID is presented in EKU extension or not. If OID is presented, validation continues, otherwise validation fails. RFC makes no assumptions about constraining EKU on CA level to restrict CA on issuing certificates only to a specified usages subset. Since CA certificate is not directly used as end entity certificate, EKU in CA certificate makes little sense. In theory. In practice, it is not very flexible in a number of scenarios and there are cases when such constraint is necessary. For example, company manages multiple CAs where each CA is dedicated to specific purposes. another scenario is cross-certification (qualified subordination) where such constraint is a must in order to reduce chances of mississuance and detect if misissuance occurred.

This blog post finishes a Certificate Autoenrollment in Windows Server 2016 blog post series. Here is a list of posts in the series:

• Certificate Autoenrollment in Windows Server 2016 (part 1)

First part makes introduction to certificate autoenrollment and describes certificate enrollment architecture in Windows 10 and Windows Server 2016.

• Certificate Autoenrollment in Windows Server 2016 (part 2)

Second part explains certificate autoenrollment architecture, its components and detailed processing rules.

• Certificate Autoenrollment in Windows Server 2016 (part 3)

Third part provides a step-by-step guide on configuring and utilizing certificate autoenrollment feature.

• Certificate Autoenrollment in Windows Server 2016 (part 4)

References

The last part provides information about advanced certificate autoenrollment features, scenarios and troubleshooting guide. Next section contains a list of reference documents used to write this whitepaper:

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: