Extended key usage (EKU) - Uwe Gradenegger

The "Application Policies" certificate extension

The purposes for which a digital certificate may be used are controlled via the certificate extensions "Key Usage" and "Extended Key Usage".

In the "Extended Key Usage" certificate extension, the extended key uses for which the certificate may be used.

However, there is another certificate extension called "Application Policies" for certificates issued by a Microsoft Certification Authority, which also contains a list very similar to the Extended Key Usages extension.

Basics: Configuration file for the certification authority (capolicy.inf)

The capolicy.inf contains basic settings that can or should be specified before installing a certificate authority. In simple terms, it can be said that no certificate authority should be installed without it.

Details of the event with ID 53 of the source Microsoft-Windows-CertificationAuthority

Event Source:	Microsoft-Windows-CertificationAuthority
Event ID:	53 (0x35)
Event log:	Application
Event type:	Warning
Symbolic Name:	MSG_DN_CERT_DENIED_WITH_INFO
Event text (English):	Active Directory Certificate Services denied request %1 because %2. The request was for %3. Additional information: %4
Event text (German):	The request %1 was rejected because %2. The request was for %3. More information: %4

Restrict extended key usage (EKU) for imported root certification authority certificates

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 limited to these Extended Key Usages. The smart card logon extended key usage would then only be present in the certification authority certificate of the certification authority that actually issues such certificates.

Frequently Used Extended Key Usages and Issuance Policies

The following is a list of commonly used extended key usage and issuance policies that are used repeatedly in practice to restrict certificate authority certificates.

Basics: Restricting Extended Key Usage (EKU) in Certification Authority Certificates

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.

Domain controller does not check extended key usage on smart card login

Anyone who wants to use the smartcard logon function in their company would be well advised to ensure that their certification authority has the strongest possible security hardening. This includes some essential measures:

Removing all unnecessary certification authority certificates from the NTAuthCertificates object in Active Directory: Each certification authority located in this store is authorized to issue smartcard logon certificates in Active Directory for the complete forest.
Use qualified subordinationRestricting the certification authority certificates so that they are only trusted for the extended key usages actually issued. In the event of a compromise of the certification authority, the damage is then limited to these extended key usages. The "Smart Card Logon" Extended Key Usage would then only be present in the certification authority certificate of the certification authority that actually issues such certificates.

What is interesting about these thoughts, however, is that the domain controllers do not check the extended key usages at all when logging in via smartcard.

Active Directory forest compromised by EDITF_ATTRIBUTESUBJECTALTNAME2 flag

In net circulate unfortunately much at many Instructions (also the big players are not excluded from this, not even Microsoft itself or the Grand Master Komar), which fatally recommends that the EDITF_ATTRIBUTESUBJECTALTNAME2 flag should be set on the certification authority - supposedly to be able to issue Subject Alternative Name (SAN) extension certificates for manually submitted certificate requests.

Unfortunately, this approach is not only unnecessary, it also has some unpleasant side effects, which in the worst case can help an attacker to take over the entire Active Directory forest.

What requirements must be met on the infrastructure side for smartcard logins to be possible?

In order for a smart card login to be successful, some requirements must be met in the Active Directory environment: