Manual application for a domain controller certificate

There are cases where you cannot or do not want to obtain domain controller certificates from a certification authority in your own Active Directory forest.

In this case, the use of certificate templates is not possible, and one must manually create a Certificate Signing Request (CSR).

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.

Preliminary work

Before applying for certificates for the domain controllers, the following requirements should be met:

The participants in the Active Directory must trust the certification authority hierarchy. If the domain controller certificates are issued by a third-party certification authority, the root certification authority certificate must be made known to all participants. This can be done, for example, via group policy, which is described in the article "Distribute Trusted Root Certification Authorities via Group Policy" is described in more detail.
In order to check the revocation status of the certificates, it must be ensured that they can be resolved (Domain Name System) as well as downloaded (routing, proxy, firewall rules) by all participants.
If the domain controllers are to process smartcard logins, the certification authority certificate of the certification authority that issues the domain controller certificates must be entered in the NTAuthCertificates object in the Active Directory forest.

Inventory for the manual creation of a certificate request

First, the content of the certificate request must be determined. One of the standard certificate templates for domain controllers can serve as a reference point for this. In the following example, we will use the latest standard template, called "Kerberos Authentication", which should preferably be used as a starting point for domain controller certificate templates.

In the "Request Handling" tab, you can see that the movement of the certificate template is set to "Signature and Encryption", which means that the key usage extension of the certificate will contain "Key Encipherment" and "Digital Signature", i.e. the hexadecimal value A0. This must already be taken into account during key creation on the requesting domain controller.

In the "Cryptography" tab, the key algorithm, the key length and the Cryptographic Service Provider (CSP) are relevant for us. The Kerberos Authentication template still uses "legacy" providers, i.e. CSPs that only support RSA. The key length should be set to at least 2072 bits and the "Microsoft RSA SChannel Cryptographic Provider" is used.

In the "Subject Name" tab we see that the Subject is empty and a Subject Alternative Name is selected in the form of a DNS name.

Domain controllers have two special features:

In the certificate template, which is stored as LDAP object in the Active Directory, a flag is set, which cannot be configured in the graphical user interface (CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS), and which leads to the fact that also the domain name, once as fully qualified domain name (FQDN) and once as NETBIOS name is written into the Subject Alternative Name.
According to RFC2818, the subject of an SSL certificate may be empty, since the subject alternative name extension should preferably be used to determine the identity. Unfortunately, this is not implemented in all applications (including Microsoft Network Policy Server), so it is advisable to also fill the subject as a fallback option.

In the "Extensions" tab we see that the following values are set as Extended Key Usage (Application Policies):

KDC Authentication (Object Identifier: 1.3.6.1.5.2.3.5)
Smart Card Logon (Object Identifier: 1.3.6.1.4.1.311.20.2.2)
Server Authentication (Object Identifier: 1.3.6.1.5.7.3.1)
Client Authentication (Object Identifier: 1.3.6.1.5.7.3.2)

Microsoft uses the term "Enhanced Key Usage", the correct name according to RFC 5280 is "Extended Key Usage"..

The Extended Key Usages "Smart Card Logon" and "KDC Authentication" allow the domain controller to perform logon with smart cards. For security reasons, these should not be entered in the issued certificates if no smart card logon and no Windows Hello for Business (which relies on smart card logon) are used.

Create Certificate Template for Manual Request of Domain Controller Certificates

If the certificate request is to be answered by an Active Directory integrated certification authority, a corresponding certificate template must be defined for this authority. The procedure for this is described in the article "Create a certificate template for manually requesting domain controller certificates" described.

Creating the certificate request with on-board tools (certutil)

It is also possible to create the certificate request completely with existing on-board tools.

Create information file for manual certificate request

From all this information, an information file (.inf) can now be created for the certificate request. Below is an example that should generate a certificate request analogous to the Kerberos Authentication certificate template:

The information file must be saved with UTF-8 encoding. If the encoding is different, the certificate request creation will fail (see article "Creation of a manual certificate request fails with error message "Expected INF file section name 0xe0000000".„).

[Version]
Signature="$Windows NT$"

[Strings]
; Adapt the following three variables to the environment
SERVER_FQDN = "DC01.intra.adcslabor.co.uk".
DOMAIN_FQDN = "intra.adcslabor.de"
DOMAIN_NETBIOS_NAME = "INTRA"

; Do not edit the following strings
;----------------------------------------------------------------

szOID_SUBJECT_ALT_NAME2 = "2.5.29.17"
szOID_ENHANCED_KEY_USAGE = "2.5.29.37"
szOID_PKIX_KP_SERVER_AUTH = "1.3.6.1.5.7.3.1"
szOID_PKIX_KP_CLIENT_AUTH = "1.3.6.1.5.5.7.3.2"
szOID_KP_SMARTCARD_LOGON = "1.3.6.1.4.1.311.20.2.2"
szOID_KP_KDC_AUTH = "1.3.6.1.5.2.3.5"

[NewRequest]
Subject = "CN=%SERVER_FQDN%"
Exportable = FALSE
MachineKeySet = True
KeyLength = 3072
KeyUsage = 0xA0 ; Digital Signature, Key Encipherment
ProviderName = "Microsoft Software Key Storage Provider".

[Extensions]
%szOID_SUBJECT_ALT_NAME2% = "{text}dns=%SERVER_FQDN%&dns=%DOMAIN_FQDN%&dns=%DOMAIN_NETBIOS_NAME%"
%szOID_ENHANCED_KEY_USAGE% = "{text}%szOID_KP_KDC_AUTH%,%szOID_KP_SMARTCARD_LOGON%,%szOID_PKIX_KP_SERVER_AUTH%,%szOID_PKIX_KP_CLIENT_AUTH%"

The file must then be saved as a text file with the .inf file extension.

The file must be encoded with ANSI. Some tools like Notepad++ or Visual Studio Code encode in UTF-8 format by default.

For background information on each option, see the following articles:

Generating the key pair and the certificate request

Now a key pair and a certificate request can be generated using this information file. The creation is done on the domain controller as an administrator via command line with the following command:

certreq.exe -new {information file}.inf {certificate request}.req

The certificate request now generated can be viewed if desired with the following command line command:

certutil -dump {certificate request}.req

Creating the certificate request with Windows PowerShell

The PSCertificateEnrollment PowerShell module can be accessed via the PowerShell Gallery obtained and then loaded.

Install-Module -Name PSCertificateEnrollment

Import-Module -Name PSCertificateEnrollment

To create the certificate request, Windows PowerShell must be started as an administrator, since the key pair for a domain controller should usually be created in the system context.

The following command generates a certificate request for a domain controller certificate for the server "dc01.intra.adcslabor.de", which uses a 3072-bit RSA key.

New-CertificateRequest `
-MachineContext `
-KeyLength 3072 `
-Subject "CN=dc01.intra.adcslabor.de" `
-Dns "dc01.intra.adcslabor.de", "intra.adcslabor.de", "INTRA" `
-EnhancedKeyUsage KDCAuthentication,ServerAuthentication,ClientAuthentication,SmartcardLogon

Sending the certificate request to the certification authority

Sending a certificate request to a certification authority and collecting the issued certificate is described in the article "Send a manually created certificate request to a certification authority" described.

Installation of the issued certificate

The certificate can now be copied to the domain controller. It must now be installed in the certificate store and associated with the private key.

Installation via Windows PowerShell

The PSCertificateEnrollment PowerShell module can be used to install the certificate with the following command:

Install-IssuedCertificate `
-MachineContext `
-Path {Certificate}

Installation via certutil

With on-board means (certutil) the certificate can be installed with the following command line command:

certreq -accept {certificate}

Function test

Whether the domain controller is now using the certificate can be checked with the following command line command:

certutil -dcinfo

If (e.g. for reasons of the Safety hardening) the "Smartcard Logon" Extended Key Usage does not occur in the domain controller certificate, this command will output the error code "CRYPT_E_NOT_FOUND"..

Likewise, a (unfortunately not very detailed) entry is written to the event log.