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.

Vendor-specific Implementation

Microsoft implementation of EKU validation deviates from RFC. CAPI2 implements two EKU validation modes:

1. Default: certificate usages are not validated. Applications are responsible for EKU validation in presented certificates.
2. Constrained: certificate is valid only to EKUs presented (or implicitly allowed) in every certificate in the chain, including leaf certificate. Roughly, the list of valid usages for particular certificate is an intersect of usages in each certificate in the chain. All interesting details are below.

Windows Certificate Viewer does not validate EKUs for certificate, but includes information about validation in constrained mode.

Observation

In this example we will evaluate my website’s SSL certificate. SSL certificate chain includes three certificates, leaf, intermediate CA and root CA:

Figure 1: leaf certificate’s chain

Leaf certificate is valid for Client and Server Authentication:

Figure 2: valid usages for leaf certificate in constrained mode

Last two rows indicate certificate policies. Switch to Details tab:

Figure 3: Explicit usages in leaf certificate

Everything is as expected. EKU specifies two usages, and General tab shows the same. Now, switch to issuer (DigiCert SHA2 Secure Server CA) certificate:

Figure 4: valid usages for intermediate CA certificate in constrained mode

General tab shows a small list of usages. Switch to Details tab:

Figure 5: extensions of intermediate CA certificate

Oooops. There is no EKU extension. Since CA certificate does not include EKU extension, we would expect that CA certificate is valid for all usages. Where the list of usages in General tab came from?

Microsoft Windows uses Windows Certificate Store to hold personal, globally trusted CA and other certificates. Because we cannot modify already signed certificates, certificate store provides a functionality to attach extended properties to installed certificates. Properties are not part of certificate, they are part of certificate store. Such properties include, Friendly Name, information about extended validation, private key location, Extended Key Usages and other properties.

The list of available certificate properties is defined in MSDN: CertSetCertificateContextProperty function

For example, Windows Certificate Store can set constraints on applicable EKU. The effect of these properties is the same as specific EKU would be presented in the certificate.

Open certificate store (certmgr.msc), expand Intermediate Certification Authorities (or Trusted Root Certification Authorities), right-click on CA certificate and select properties. In case of DigiCert CA certificate, the dialog will show the following:

Figure 6: EKU properties for intermediate CA certificate in Windows Certificate Store

We see a list of valid usages for this particular CA certificate. The radiobutton is set to “Enable all purposes for this certificate” option, but the list is limited only to 5 purposes. This means that restrictions are inherited from DigiCert root CA certificate:

Figure 7: EKU properties for root CA certificate in Windows Certificate Store

Now we see that root CA certificate is restricted (via certificate store properties) only to 5 usages. This means that any certificate under this root can be “valid” to these usages only. And we observe this behavior in intermediate CA certificate (figure 6). Certificates below the constrained root can reduce valid usages, but not extend. This behavior is very similar to a one in Certificate Policies extension validation: Certificate Policies extension – all you should know (part 1).

To summarize our observation: root CA certificate does not include EKU extension instead, it is constrained via certificate store extended properties and is constrained to five usages only (fig. 7). Intermediate CA certificate doesn’t include EKU extension and is not constrained via certificate store properties (fig. 6), so intermediate CA certificate inherits constraints from its parent. Leaf certificate includes EKU extension and includes two usages (fig. 2, 3). These usages match constraints inherited from issuer certificate. At this point, we can conclude that my web site SSL certificate is valid for usages specified in the EKU extension.

Testing Constraints

In this section, I will show different behaviors when validating certificate with EKU that contains invalid usages. We will modify EKU certificate store properties for DigiCert SHA2 Secure Server CA certificate. If you don’t like DigiCert, you can test this with any CA certificate.

1. Open Certificates MMC snap-in (certmgr.msc);
2. Expand Intermediate Certification Authorities node and expand Certificates subnode;
3. Locate certificate issued to DigiCert SHA2 Secure Server CA;
4. Right-click on certificate and select Properties.
5. Ensure that you see same dialog as in figure 6;
6. Switch radiobutton to “Enable only the following purposes” option and uncheck Client Authentication and Server Authentication usages.

The dialog should look like this:

Figure 8: modified EKU list for intermediate CA certificate

Save changes and open modified certificate (double-click on certificate). We will see difference between modified certificate and the one in fig. 4.

Figure 9: valid usages for intermediate CA certificate after modifications

Figure 9 no longer show Server and Client Authentication usages. Let’s take a look at SSL certificate:

Figure 10: valid usages for leaf certificate after modifications

We see that certificate is valid only to two weird OIDs which are certificate policy OIDs, not EKU usages. This means that this particular certificate is not valid for any usage. However, Windows Certificate Viewer doesn’t show any errors in presented certificate. Like I said in above, Windows Certificate Viewer doesn’t perform EKU validation (runs in default validation mode). Now we will pass this certificate through certificate chaining engine in default and constrained modes:

PS C:\Users\vPodans> $chain = New-Object Security.Cryptography.X509Certificates.X509Chain $false
PS C:\Users\vPodans> $chain.Build(".\Desktop\www.cer")
True
PS C:\Users\vPodans>

We passed certificate through certificate chaining engine in constrained EKU validation mode (where EKU’s are not validated) and X509Chain.Build method returned true, indicating that certificate is perfectly valid. Check again with certutil:

 

PS C:\Users\vPodans> certutil -user -verify .\Desktop\www.cer
Issuer:
    CN=DigiCert SHA2 Secure Server CA
    O=DigiCert Inc
    C=US
  Name Hash(sha1): 105fa67a80089db5279f35ce830b43889ea3c70d
  Name Hash(md5): c47fcd4b1a68730e777c053868355ab1
Subject:
    CN=www.sysadmins.lv
    OU=-
    O=Sysadmins LV IK
    L=Riga
    C=LV
  Name Hash(sha1): 7ba6c543fc452b9b91a73c65fc597e775058dcb1
<...>

Verified Issuance Policies:
    2.16.840.1.114412.1.1
    2.23.140.1.2.2
Verified Application Policies: None
Cert is an End Entity certificate
Leaf certificate revocation check passed
CertUtil: -verify command completed successfully.
PS C:\Users\vPodans>

I excluded non-interesting parts of certutil output. Generally speaking, certutil is fine with this certificate. Though, certutil mentioned that there are no valid application policies (or EKU). Now, configure certificate chaining engine with constrained EKU validation mode:

PS C:\Users\vPodans> $chain = New-Object Security.Cryptography.X509Certificates.X509Chain $false
PS C:\Users\vPodans> $chain.ChainPolicy.ApplicationPolicy.Add("Server authentication")
0
PS C:\Users\vPodans> $chain.Build(".\Desktop\www.cer")
False
PS C:\Users\vPodans> $chain.ChainStatus

          Status StatusInformation
          ------ -----------------
NotValidForUsage The certificate is not valid for the requested usage...


PS C:\Users\vPodans>

We asked CCE to validate certificate if it is valid for Server Authentication. And it is not, because Server Authentication EKU is not valid in *every* certificate in the chain. Take a look at certutil:

PS C:\Users\vPodans> certutil -user -verify .\Desktop\www.cer 1.3.6.1.5.5.7.3.1
Issuer:
    CN=DigiCert SHA2 Secure Server CA
    O=DigiCert Inc
    C=US
  Name Hash(sha1): 105fa67a80089db5279f35ce830b43889ea3c70d
  Name Hash(md5): c47fcd4b1a68730e777c053868355ab1
Subject:
    CN=www.sysadmins.lv
    OU=-
    O=Sysadmins LV IK
    L=Riga
    C=LV
<...>

The certificate is not valid for the requested usage. 0x800b0110 (-2146762480 CERT_E_WRONG_USAGE)
------------------------------------
CertUtil: -verify command FAILED: 0x800b0110 (-2146762480 CERT_E_WRONG_USAGE)
CertUtil: The certificate is not valid for the requested usage.
PS C:\Users\vPodans>

Certutil isn’t happy either. In fact, both commands (X509Chain and certutil) invoked CCE with the same configuration, so the result is consistent.

Ok, we’re done with our tests, so can revert back our changes in DigiCert CA certificate to inherit valid usages from its parent.

Conclusions

In this post we have explored Extended Key Usages extension processing and validation details in Microsoft Windows. Unlike other extensions like Name Constraints, EKU extension is not constrained by RFC. RFC makes certificate valid for usages it governs. If EKU is totally absent in certificate extension, then certificate is literally valid for all usages. This behavior is made to be compatible with X.509 Version 1 certificates, which are still in use and do not have any extensions at all.

This behavior is ok in some scenarios, but not sufficient in others, like cross-certification or qualified subordination, when issuer want’s to restrict issued certificates only to specified usages. Microsoft resolved this question by introducing two EKU validation modes: default (which is conformant with RFC) and constrainted, when valid usages for certificate are determined by entire chain. Web browsers (including Microsoft Interned Explorer and Microsoft Edge) always run in soft mode, when required usages are validated only in leaf certificate. However, applications may be configured to use constrained EKU validation mode and fail validation if at least one certificate in the chain is not valid for requested usage. Such configuration was demonstrated in this post when we asked certificate chaining engine to validate certificate against specific usage.

Depending on business and security needs, developers can use one or another EKU validation mode when using in Microsoft Windows. Constrained EKU validation mode may not be available on other platforms out of the box and will require extra code to implement constrained validation on these platforms.

---