Tag: Extended Key Usage (EKU)

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

The "Extended Key Usage" certificate extension contains the extended key usages for which the certificate may be used.

However, certificates issued by a Microsoft certification authority contain another certificate extension called "Application Policies", which also contains a list very similar to the Extended Key Usages extension.

Continue reading "The "Application Policies" certificate extension"

The capolicy.inf contains basic settings that can or should be specified before installing a certification authority. Put simply, no certification authority should be installed without it.

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

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

A useful hardening measure for certification authorities is to restrict the certification authority certificates so that they are only trusted for the extended key usages (Extended Key Usage) 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.

Continue reading "Restrict Extended Key Usage (EKU) for imported root certification authority certificates"

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

Continue reading "Frequently Used Extended Key Usages and Issuance Policies"

A useful hardening measure for certification authorities is to restrict the certification authority certificates so that they are only trusted for the extended key usages (Extended Key Usage) that are actually issued.

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.

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

Anyone who wants to use the smart card logon feature 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 smart card logon certificates in Active Directory for the complete forest.
• Use qualified subordination : Restricting 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 on via smart card.

Continue reading "Domain controllers do not check Extended Key Usage on smart card logon"

Unfortunately, far too many instructions are circulating online (the big players are not exempt from this either, not even Microsoft itself or the grand master Komar ), which fatally recommend setting the EDITF_ATTRIBUTESUBJECTALTNAME2 flag on the certification authority - supposedly so that one would be able to issue certificates with a Subject Alternative Name (SAN) extension 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.

Continue reading "Active Directory forest compromised by EDITF_ATTRIBUTESUBJECTALTNAME2 flag"

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

Continue reading "What requirements must be met on the infrastructure side for smart card logons to be possible?"