Certificate usage - Page 19

Attack vector on Active Directory directory service via smartcard logon mechanism

In simple terms, public key cryptography can be reduced to the assumption that the private part of each key pair is known only to its owner.

A certification authority is responsible for the correct identification of users, computers or resources. Its issued certificates are therefore granted a trust status because all participants assume that their private key is known only to it.

If an attacker succeeds in gaining knowledge of a certification authority's private key, or at least Perform signatures using the private key, the integrity of the certification authority is no longer guaranteed.

Basics: Restricting Extended Key Usage (EKU) in 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 (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.

What key lengths should be used for certificate authorities and certificates?

When planning a public key infrastructure, the question naturally arises as to which key lengths should be selected for certification authority and end certificates.

Generating a RFC 2818 compliant certificate request for SSL certificates

Google is a major player with the Chromium project and products based on it such as Google Chrome and Microsoft Edge have moved to implement the RFC 2818 and to no longer trust certificates that no longer fulfill the RFC.

For us, the following sentence is of great explosiveness:

If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead
https://tools.ietf.org/html/rfc2818

Configure Device Template for Network Device Enrollment Service (NDES)

By default, the Network Device Enrollment Service (NDES) requests certificates from the "IPsec (Offline Request)" template. This certificate template is from Windows 2000 times and cannot be edited. Therefore, it is recommended to change the default settings and use your own certificate templates that serve your personal requirements.

Enabling Secure Sockets Layer (SSL) for the Network Device Enrollment Service (NDES).

In the default configuration, the Network Device Enrollment Service (NDES) only accepts unencrypted connections via HTTP. It is recommended that at least the NDES administration web page be configured for HTTP over TLS (HTTPS) to make it difficult to capture network traffic. The following is a guide.

For a closer look at the need to use SSL, see the article "Should HTTPS be used for the Network Device Enrollment Service (NDES)?„.

Using custom Registration Authority (RA) certificate templates for the Network Device Enrollment Service (NDES).

The Network Device Enrollment Service (NDES) uses two certificate templates for its internal function to make it act as a Registration Authority (RA). These are published during role configuration of the NDES service on the configured certificate authority and certificates are requested:

CEP Encryption
Exchange Enrollment Agent (Offline Request)

These certificate templates are standard templates from the Windows 2000 world (version 1 templates), i.e. they cannot be edited. In addition, the Exchange Enrollment Agent (Offline Request) template is marked as a user template, i.e. during NDES role configuration the certificate is requested in the context of the installing user and then imported into the machine store. At the latest when the certificates are to be renewed after two years, things get complicated here.

It is therefore a good idea to use your own certificate templates for NDES. These can be adapted in terms of their key length, for example. The use of hardware security modules (HSM) is also possible in this way. Even automatic renewal can be configured.

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.

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:

Removing ADCS-specific extensions from certificates

When using Active Directory Certificates, it is noticeable that there are certain extensions in the certificates of the certification authorities and the certificates they issue that are not defined in the relevant RFCs and are specific to AD CS.

Firewall rules required for Active Directory Certificate Services

Implementing an Active Directory integrated certification authority often requires planning the firewall rules to be created on the network. The following is a list of the required firewall rules and any pitfalls.

Description of the EDITF_ADDOLDKEYUSAGE flag

When installing a subordinate certificate authority, you may encounter the following behavior:

One requests a Key Usage extension that is marked as critical, for example, or does not include DigitalSignature.
However, the certificate issued by the parent certificate authority includes DigitalSignature, and the Key Usage extension is marked as non-critical.
The parent certification authority is a standalone certification authority, i.e. without Active Directory integration.

Domain controller
Domain Controller Authentication
Kerberos Authentication

Below is a description of each template and a recommendation for configuring domain controller certificate templates.

Category: Certificate usage