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:

image

Fig. 1. Request extension list building

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

image

Fig. 2. Certificate extension list building

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

Vadims Podāns

About Vadims Podāns

Senior PKI Developer

8 Comments

  1. Avatar Ernest on February 4, 2021 at 1:01 am

    Hi Vadims, hope you are very well
    Great post 🙂

    From what you wrote above, I understand the following

    If the incoming request (CSR) has Subject (common name) for an Enterprise (AD joined) CA. Then from what you wrote above, I understand the issued certificate will include extensions listed in EnableEnrolleeRequestExtensionList ?

    Therefore I am just bit confused about the following wording

    “This means that no extension from this list will be passed to issued certificate even if requested in “online” request.”
    This suggested to me the extensions will not be included in the certificate, of perhaps I am just reading it wrong

    Please clarify

    Thanks very much

    • Vadims Podāns Vadims Podāns on February 4, 2021 at 1:07 am

      > If the incoming request (CSR) has Subject (common name) for an Enterprise (AD joined) CA
      this isn’t accurate. An “online” request is a request against Enterprise CA and template that builds subject from AD. In this case, EnableEnrolleeRequestExtensionList is not processed. And extensions allowed in this list are not passed to certificate. Does this make sense?

  2. Avatar Ernest on February 4, 2021 at 2:40 am

    Hi Vadims,
    Yes, makes sense thanks for the clarification

  3. Avatar Ernest on February 4, 2021 at 2:50 am

    Just the clarify why I asked the question, I have sent CSR to Enterprise CA where the Subject was in the CSR (for example CSR from a non-domain joined Linux or Windows host, etc.).

    So as you explain above when the Subject is included in the CSR (whether the CA is stand-alone or AD joined); in every case, this is considered an offline request, and the EnableEnrolleeRequestExtensionList will be processed. However, extensions could be removed if any matches found in DisableExtensionList.

    Thanks again for a great post

    • Vadims Podāns Vadims Podāns on February 4, 2021 at 2:59 am

      > in every case, this is considered an offline request
      no, it is an incorrect assumption. See my previous response. Request is considered “offline” only when CA is Standalone (in all cases) or CA is Enterprise and template builds subject from request. If template builds subject from AD, it is online request. The way how you generate or submit request doesn’t matter.

      > However, extensions could be removed if any matches found in DisableExtensionList
      that’s correct. DisabledExtensionList is processed last and can ultimately disable any extension even if it is enabled in other configurations.

  4. Avatar Ernest on February 4, 2021 at 3:32 am

    Thanks, Vadims,

    That is kind of what I meant (but explained it better)

    The Template object in AD, ‘Subject Name’ tab ‘Supply in Request’ meaning the CSR will contain the Subject and therefore EnableEnrolleeRequestExtensionList will be processed

    Thanks again (stay safe)
    Ernest

  5. Avatar Ernest on February 4, 2021 at 3:33 am

    I mean you explained it better 🙂

  6. Avatar Ernest on February 4, 2021 at 3:35 am

    I mean I meant to explain it better 🙂

Leave a Comment





This site uses Akismet to reduce spam. Learn how your comment data is processed.