A useful hardening measure for Certification Authorities is to restrict the Certification Authority certificates so that they are only used for the actually issued extended key usage (Extended Key Usage) becomes familiar.
In the event of a compromise of the certification authority, the damage is then (at least) limited to the defined extended key usages.
The Smart Card Logon Extended Key Usage, which is of interest for many attacks (in conjunction with the certification authority's membership in NTAuthCertificates) would then only be present in the certification authority certificate of the certification authority that actually issues such certificates.
Functionality and backgrounds
Do you know TameMyCerts? TameMyCerts is an add-on for the Microsoft certification authority (Active Directory Certificate Services). It extends the function of the certification authority and enables the Application of regulationsto realize the secure automation of certificate issuance. TameMyCerts is unique in the Microsoft ecosystem, has already proven itself in countless companies around the world and is available under a free license. It can downloaded via GitHub and can be used free of charge. Professional maintenance is also offered.
End entity certificates have an "Extended Key Usage" extension that defines the purposes for which the certificate may be used (e.g., Transport Layer Security (TLS)).
Microsoft uses the term "Enhanced Key Usage", the correct name according to RFC 5280 is "Extended Key Usage"..
The Extended Key Usage defines for which purposes the certificate may be used. In the Microsoft Windows certificate dialog, this is indicated in the example by "Ensures the Identity of a Remote Computer" is displayed and corresponds to the Extended Key Usage for "Server Authentication", which is typical for a web server certificate.
The "General" tab in the Windows certificate dialog shows the result of the certificate's policy check, not the actual content of the certificate. This can be viewed in the "Details" tab and may well differ.
In the default configuration, a certificate authority certificate is not restricted in terms of certificate types. The certificate lacks an "Extended Key Usage" extension, so the certificate can be used for all purposes. In the Microsoft Windows certificate dialog this is indicated by "All Application Policies" displayed.
A certification authority can be restricted in its usability by adding an "Extended Key Usage" extension. It can then only issue certificates for the defined EKUs.
Types of restrictions
This basic approach to technical constraint by the Certification Authority is known as qualified subordination or applying constraints.
| Component | Description |
|---|---|
| Path length restriction (Path Length Constraint) | This can be used to define how many hierarchy levels (i.e. subordinate Certification Authorities) may follow the Certification Authority in question. |
| Restrictions on extended key usage (Extended Key Usage Constraints) | This can be used to specify which extended key usages may be accepted in certificates issued by the certification authority. |
| Restrictions of the Issuance Policies | This allows you to specify for which certificate policies the Certification Authority may confirm their conformity in issued certificates. |
| Name restrictions (Name Constraints) | This can be used to define for which namespaces the certification authority may issue certificates. |
Restricting Extended Key Usages
The method of restricting extended key usages was first used by Microsoft under the name "nested EKU enforcement".
In addition Microsoft introduced another mechanism to restrict the scope in which a CA is trusted for, they did this by treating the Extended Key Usage (see section 4.2.1.13) extension as a means to delegate only certain issuance capabilities to a Certificate Authority
Least Privilege and Subordinate Certificate Authorities (Ryan Hurst)
It is therefore not part of RFC 5280. This simply indicates that the Extended Key Usage extension is only expected in end-entity certificates.
In general, this extension will appear only in end entity certificates.
RFC 5280
However, the feature goes beyond the requirements of RFC 5280 and (if the corresponding certificate extension is marked as non-critical) is also compatible with implementations that do not support it.
A popular security incident whose consequences could at least be reduced by this implementation was the "Flame" Incident. Here it came by one with a Hash Collision generated forged code signing certificate meant that malware could be signed with valid certificates. After all, the damage was limited to "only" this purpose (code signing).
The practice
Meanwhile, popular applications such as Mozilla Firefox and OpenSSL have adopted the behavior of the Microsoft implementation. Browsers which are used on Windows and which implement the CryptoAPI (Google Chrome, Microsot Edge and Internet Explorer) use the corresponding Windows system library and behave accordingly.
In practice, adaptation by third parties now goes even further: in the area of Internet PKI around browser and certification authority providers, use is now sometimes even demanded or at least recommended:
We encourage CAs to technically constrain all intermediate certificates. For a certificate to be considered technically constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying all extended key usages that the subordinate CA is authorized to issue certificates for.
Mozilla Root Store Policy
Generally Extended Key Usage will only appear within end entity certificates (as highlighted in RFC 5280 (4.2.1.12)), however, Subordinate CAs MAY include the extension to further protect relying parties until the use of the extension is consistent between Application Software Suppliers whose software is used by a substantial portion of Relying Parties worldwide.
CA/Browser (CAB) Forum V1.1.8
If present, this extension SHOULD be marked non-critical.
CA/Browser (CAB) Forum V1.1.8
For a Subordinate CA Certificate to be considered Technically Constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying all extended key usages that the Subordinate CA Certificate is authorized to issue certificates for. The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this extension.
CA/Browser (CAB) Forum V1.7.3
If the Subordinate CA Certificate includes the id-kp-serverAuth extended key usage, then the Subordinate CA Certificate MUST include the Name Constraints X.509v3 extension with constraints on dNSName, iPAddress and DirectoryName as follows:
A curiosity here is that Let's Encrypt does not adhere to its own Certificate Policy (which is based on the CAB Forum): Extended Key Usage restrictions are defined, but not the required associated Name restrictions (Note: how could it, after all, Let's Encrsypt basically wants to be able to serve all DNS namespaces).
If the Subordinate CA Certificate includes the id-kp-serverAuth extended key usage, then the Subordinate CA Certificate MUST include the Name Constraints X.509v3 extension with constraints on dNSName, iPAddress and DirectoryName [...]
Internet Security Research Group (ISRG) Certificate Policy, Version 2.2
Assessment for usability in practice
The use is possible without danger and also makes sense, but requires thorough planning, which should also include possible use cases for the coming years.
Such a construct can drastically reduce the damage caused by compromising a Certification Authority (in conjunction with further hardening measures), but on the other hand it also increases the complexity to be handled. Complexity, in turn, is the enemy of security, so the decision wants to be well-considered.
Implementation
Before a certification authority is put into operation, it is usually already defined which certificate types it will issue. This means that the corresponding extended key usages can be worked out from these.
By default, the Microsoft Certificate Authority will refuse to issue certificates with a different policy. Signatures that directly violate the Key Storage Provider be made, but would still be executed. Such a certificate should then be considered invalid.
However, this check is the responsibility of the respective application that processes the certificate, so that no generally valid statement can be made here. The restrictions are written to the certification authority certificate by the higher-level certification authority. They should therefore also be defined by the certificate authority.
In practice, however, for reasons of simplification, the extended key usages will be requested by the certification authority concerned and signed by the higher-level certification authority. To prepare the certificate request of a certification authority for the request of extended key usages, the file capolicy.inf in the system directory (usually C:\Windows) is extended by a corresponding passage.
[EnhancedKeyUsageExtension.] OID=1.3.6.1.5.5.7.3.2 ; Client Authentication OID=1.3.6.1.5.5.7.3.1 ; Server Authentication OID=1.3.6.1.5.5.7.3.9 ; OCSP Signing OID=1.3.6.1.4.1.311.21.5 ; Private Key Archival Critical=FALSE
For compatibility reasons, the "Extended Key Usage" extension should be configured as non-critical. Applications that do not interpret this extension would otherwise not understand the certificate authority certificate and abort certificate processing.
Below is a list of the most commonly used Extended Key Usages:
| OID | Description |
|---|---|
| 1.3.6.1.4.1.311.20.2.1 | Certificate Request Agent |
| 1.3.6.1.5.5.7.3.2 | Client Authentication |
| 1.3.6.1.5.5.7.3.3 | Code Signing |
| 1.3.6.1.4.1.311.10.3.13 | Lifetime Signing |
| 1.3.6.1.4.1.311.10.3.12 | Document Signing |
| 1.3.6.1.4.1.311.80.1 | Document Encryption |
| 1.3.6.1.4.1.311.10.3.4 | Encrypting file system |
| 1.3.6.1.4.1.311.10.3.4.1 | File Recovery |
| 1.3.6.1.5.5.7.3.5 | IP Security End System |
| 1.3.6.1.5.5.8.2.2 | IP Security IKE Intermediate |
| 1.3.6.1.5.5.7.3.6 | IP Security Tunnel Endpoint |
| 1.3.6.1.5.5.7.3.7 | IP Security User |
| 1.3.6.1.4.1.311.10.3.11 | Key Recovery |
| 1.3.6.1.5.2.3.5 | KDC Authentication |
| 1.3.6.1.4.1.311.10.3.1 | Microsoft Trust List Signing |
| 1.3.6.1.4.1.311.10.3.10 | Qualified Subordination |
| 1.3.6.1.4.1.311.10.3.9 | Root List Signer |
| 1.3.6.1.5.5.7.3.4 | Secure E-mail |
| 1.3.6.1.5.5.7.3.1 | Server Authentication |
| 1.3.6.1.4.1.311.20.2.2 | Smartcard Logon |
| 1.3.6.1.5.5.7.3.8 | Time Stamping according to RFC 3161 |
| 1.3.6.1.5.5.7.3.9 | OCSP Signing |
| 1.3.6.1.4.1.311.54.1.2 | Remote Desktop Authentication |
| 1.3.6.1.4.1.311.21.5 | Private Key Archival |
| 2.16.840.1.113741.1.2.3 | Intel Advanced Management Technology (AMT) Provisioning |
It may be advisable to include the following Extended Key Usages in the list:
- "OCSP Signing" (1.3.6.1..5.5.7.3.9) is required for OCSP signature certificates. Should the certification authority receive an OCSP entry in the Authority Information Access (AIA) extension, or could do so in the future, this EKU should be included, otherwise no OCSP signature certificates can be issued by this certification authority.
- "Private Key Archival" (1.3.6.1.4.1.311.21.5) is used by the Certification Authority Exchange ("CA Exchange") certificates of the certification authority are required. In addition to the actual task of archiving private keys, this certificate type is also requested by the Enterprise PKI (pkiview.msc) console. If this Extended Key Usage is missing in the certification authority certificate, no Certificate Authority Exchange (CA Exchange) certificates can be issued and the certificate authority will log a failed certificate request. Extended Key Usage should therefore always be included in the list.
- "Certificate Request Agent" (1.3.6.1.4.1.311.20.2.1) is used for Enroll on Behalf of (EOBO) operations, but also for the installation of a Network Device Registration Service (NDES) used. If the certification authority is to serve one of these cases now or even possibly later, this enhanced key usage should be included. When evaluating, it is essential to keep in mind that "modern" clients can potentially be used with Microsoft Intune be managed, which in turn will require one or more NDES instances.
The resulting certificate authority certificate will then have a corresponding "Extended Key Usage" extension.
The usable certificate types are then applied accordingly in the "General" tab of the certificate dialog.
A (potentially maliciously generated) certificate that does not comply with the configured policies can be detected by the application accordingly. In the case of a Windows application, a corresponding warning is displayed.
Once again, it must be pointed out that certificate checking is the responsibility of the application using it, and the results can vary greatly depending on the implementation. For example, all common browsers are very strict in this respect, whereas a domain controller does not care about the extended key usages in the certificate by default..
Related links:
- Domain controller does not check extended key usages on smart card login
- Attack vector via smartcard logon mechanism
- Basics: Name Constraints
- What requirements must be met on the infrastructure side for smartcard logins to be possible?
- Frequently Used Extended Key Usages and Issuance Policies
- Restrict extended key usage (EKU) for imported root certification authority certificates
- Editing the NTAuthCertificates object in Active Directory
- Basics: Name Constraints
- Basics: Cryptographic Service Provider (CSP) and Key Storage Provider (KSP)
- Basics: key algorithms, signature algorithms and signature hash algorithms
External sources
- RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (Internet Engineering Task Force)
- Constraining Extended Key Usages in Microsoft Windows (Vadims Podans)
- Root CA with Extended Key Usage fields (security.stackexchange.com)
- Understanding Constraints / Application Policy (Microsoft)
- Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, versions 1.7.3, 1.1.8 (CA/Browser Forum)
- Mozilla Root Store Policy (Mozilla)
- CA/Subordinate CA Checklist (Mozilla)
- Announcing Version 2.1 of Mozilla CA Certificate Policy (Mozilla)
- Internet Security Research Group (ISRG) Certificate Policy, Version 2.2 (Internet Security Research Group)
- Support enforcing nested EKU constraints, do so by default. (Mozilla Bugtracker)
- MSRC 2718704 and Nested EKU enforcement (Ryan Hurst, "Unmitigated Risk," former Microsoft employee and IETF representative for Microsoft).
English 
Deutsch
14 thoughts on “Grundlagen: Einschränken der erweiterten Schlüsselverwendung (Extended Key Usage, EKU) in Zertifizierungsstellen-Zertifikaten”
Comments are closed.