Request extension processing in Active Directory Certification Authority

Hello S-1-1-0, Crypt32 is on air!

Today I want to explain how ADCS Certification Authority processes extensions from incoming requests and certificate templates.

Every X.509 V3 certificate contains certificate extensions to include extra information about certificate owner, issuer, intended usages, limitations/constraints. CA utilize multiple sources to generate extension list to be included in signed certificate, such as incoming request and CA internal configuration. Microsoft CA can use Certificate Templates as additional source of extension content to include.

At a very minimum a PKCS#10 certificate request contains only signed public key. Even subject information is not necessary if subject can be inferred in external way. For example, request is passed through authentication process and CA has access to authentication data that would imply requester or certificate subject. In this case, CA is responsible to use any available source in order to build the authorized extension list.

Certificate request may contain a desired list of extensions. If configuration allows, CA may include requested extension unmodified, modify/override it or completely reject particular extension. And CA may include its own extensions regardless they were requested. Common extensions CAs put in signed certificates are CRL Distribution Points, Authority Information Access and Authority Key Identifier. Clients cannot override them. This is how Microsoft Standalone CA behaves: it has a list of mandatory extensions to include in every certificate and add extensions from incoming request if particular extension is allowed. Microsoft Enterprise CA in addition uses certificate templates with extension configuration and which is included in issued certificate. We can outline certificate extension content source used by Microsoft CAs:

• Standalone CA: internal configuration, incoming request
• Enterprise CA: internal configuration, incoming request, certificate template

It is evident that extension content may come into a conflict when different sources define same extension with different content. CA is in charge to resolve these conflicts. Internal extension configuration for Microsoft CA is stored in Policy Module.

Certificate Extension configuration in Policy Module

When CA processes incoming request, it is passed through policy module where request is processed.

Policy module has three extension configuration entries that store an array of extension object identifiers:

• EnableRequestExtensionList – stores allowed extensions for any type of certificate request;
• EnableEnrolleeRequestExtensionList – stores allowed extensions for offline requests;
• DisableExtensionList – stores disallowed extensions for any type of certificate request.

What these configuration entries mean:

EnableRequestExtensionList

Contains a list of certificate extensions that are always processed and included in issued certificate when requested by requester, certificate template or CA internal configuration.

By default, the following extensions are explicitly enabled:

1.2.840.113549.1.9.15 SMIME Capabilities
1.3.6.1.4.1.311.21.1  CA Version
1.3.6.1.4.1.311.21.2  Previous CA Certificate Hash
2.5.29.15             Key Usage

This list MUST NEVER include Subject Alternative Name extension.

Enabled request extension list is managed with certutil as follows:

certutil -setreg policy\EnableRequestExtensionList +{Extension OID}; adds new extension to the list
certutil -setreg policy\EnableRequestExtensionList -{Extension OID}; removes new extension to the list

EnableEnrolleeRequestExtensionList

Contains a list of certificate extensions that are processed and included in issued certificate against offline requests. Offline requests are requests where certificate subject is built from request. All requests on Standalone CA are offline requests, because Standalone CA always builds subject from incoming request. For Enterprise CA, offline requests are requests against certificate template where subject is supplied in request. If subject is built from Active Directory, then request is treated “online” and this list of extensions is not processed. This means that no extension from this list will be passed to issued certificate even if requested in “online” request.

By default, the following extensions are explicitly enabled for offline requests:

1.3.6.1.4.1.311.10.9.1 Cross-Certificate Distribution Points
1.3.6.1.4.1.311.20.2   Certificate Template Name (Certificate Type)
1.3.6.1.4.1.311.21.7   Certificate Template Information
1.3.6.1.4.1.311.21.10  Application Policies
1.3.6.1.4.1.311.21.11  Application Policy Mappings
1.3.6.1.4.1.311.21.12  Application Policy Constraints
2.5.29.17              Subject Alternative Name
2.5.29.30              Name Constraints
2.5.29.32              Certificate Policies
2.5.29.33              Policy Mappings
2.5.29.36              Policy Constraints
2.5.29.37              Enhanced Key Usage

This list SHOULD ALWAYS include Subject Alternative Name extension.

“Offline” request extension list is managed with certutil as follows:

certutil -setreg policy\EnableEnrolleeRequestExtensionList +{Extension OID}; adds new extension to the list
certutil -setreg policy\EnableEnrolleeRequestExtensionList -{Extension OID}; removes new extension to the list

DisableExtensionList

Contains a list of certificate extensions that are ultimately excluded from signed certificate even if allowed and required by external source. In processing sequence, this list is processed last and has highest priority when deciding whether to By default, this list is empty, which means that no extensions are explicitly disabled.

Disabled extension list is managed with certutil as follows:

certutil -setreg policy\DisableExtensionList +{Extension OID}; adds new extension to the list
certutil -setreg policy\DisableExtensionList -{Extension OID}; removes new extension to the list

Processing Sequence

When request is submitted to CA, it does several things with extensions:

1. Creates an empty final list of extensions;
2. Adds extensions defined in certificate template (Enterprise CA), such as Application Policies (EKU), Key Usage, Template Information, Certificate Policies to the final list. Origin property is set to Policy, Enabled property is set to True;
3. Adds extensions included in request to the final list. Extensions are taken from both, authenticated and unauthenticated request attributes. If extension value from request conflicts with existing in the final list extension, it is not added. That is, template extension value takes precedence over request extensions. Origin property is set to Request for authenticated extension and Policy for unauthenticated extensions. Enabled property is set to False;
4. Gets a list of extensions defined in policy module, such as CRL Distribution Points and Authority Information Access, Authority Key Identifier. Origin property is set to Server, Enabled property is set to True;
5. Passes final list of extensions to processing module which modifies Enabled property for each extension.

In step 3, there are couple of conditional checks:

1. If SAN extension passed as unauthenticated attribute (not part of original request and added dynamically during request submission by the requester), it must be explicitly allowed by policy module configuration. If policy module do not allow SAN as request attribute, it is not added in the final list (i.e. ignored).

2. If extension value is EMPTY and CA is configured to allow volatile (non-persistent requests), extension is not added in the final list regardless of extension origin.

The following diagram outlines the processing rules for steps 1-4:

Fig. 1. Request extension list building

And the following diagram outlines step 5, extension list processing and Enabled flag manipulation:

Fig. 2. Certificate extension list building

And only extensions with Enabled=True are eventually added to signed certificate.