Manuelle Beantragung eines Domänencontroller-Zertifikats

Autor Uwe GradeneggerVeröffentlicht am Kategorien Active Directory, Zertifikat-BenutzungSchlagwörter , , , , , , ,

Es gibt Fälle, in welchen man Domain Controller Zertifikate nicht von einer Zertifizierungsstelle in der eigenen Active Directory Gesamtstruktur beziehen kann oder möchte.

In diesem Fall ist die Verwendung von Zertifikatvorlagen nicht möglich, und man muss manuell einen Zertifikatantrag (Certificate Signing Request, CSR erstellen).

Vorarbeiten

Bevor Zertifikate für die Domänencontroller beantragt werden, sollten folgende Voraussetzungen erfüllt sein:

  • Die Teilnehmer im Active Directory müssen der Zertifizierungsstellen-Hierarchie vertrauen. Werden die Domänencontroller-Zertifikate von einer fremden Zertifizierungsstelle ausgestellt, muss das Stammzertifizierungsstellen-Zertifikat allen Teilnehmern bekannt gemacht werden. Dies kann beispielsweise via Gruppenrichtlinie erfolgen, was im Artikel "Vertrauenswürdige Stammzertifizierungsstellen per Gruppenrichtlinie verteilen" näher beschrieben wird.
  • Damit der Sperrstatus der Zertifikate überprüft werden kann, muss sichergestellt sein, dass diese durch alle Teilnehmer aufgelöst (Domain Name System) sowie heruntergeladen werden können (Routing, Proxy, Firewallregeln).
  • Sofern die Domänencontroller Smartcard-Anmeldungen verarbeiten sollen, muss das Zertifizierungsstellen-Zertifikat der Zertifizierungssstelle, welche die Domänencontroller-Zertifikate ausstellt, in das NTAuthCertificates Objekt in der Active Directory Gesamtstruktur eingetragen werden.

Bestandsaufnahme für die manuelle Erstellung einer Zertifikatanforderung

Zunächst muss der Inhalt der Zertifikatantrags bestimmt werden. Als Anhaltspunkt hierfür kann eine der Standard-Zertifikatvorlagen für Domain Controller dienen. Im nachfolgenden Beispiel orientieren wir uns an der neuesten Standardvorlage, genannt "Kerberos Authentication", welche als Ausgangspunkt für Domänencontroller-Zertifikatvorlagen bevorzugt verwendet werden sollte.

Im Karteireiter "Request Handling" sieht man, dass der Zwerk der Zertifikatvorlage auf "Signature and Encryption" eingestellt ist, was dazu führt, dass die Key Usage Erweiterung des Zertifikats "Key Encipherment" und "Digital Signature", also den hexadezimalen Wert A0 beinhalten wird. Dies muss bereits bei der Schlüssel-Erstellung auf dem beantragenden Domänencontroller berücksichtigt werden.

Im Karteireiter "Cryptography" sind für uns der Schlüsselagorithmus, die Schlüssellänge und der Cryptographic Service Provider (CSP) von Relevanz. Die Kerberos Authentication Vorlage verwendet noch "Legacy"-Anbieter, also CSPs, welche lediglich RSA unterstützen. Die Schlüssellänge sollte auf mindestes 2072 Bit gesetzt werden, und es wird der "Microsoft RSA SChannel Cryptographic Provider" verwendet.

Im "Subject Name" Karteireiter sehen wir, dass das Subject leer ist und ein Subject Alternative Name in Form eines DNS-Namens gewählt wird.

Bei Domain Controllern gibt es zwei Besonderheiten:

  • In der Zertifikatvorlage, welche als LDAP Objekt im Active Directory abgespeichert ist, ist ein Flag gesetzt, welches nicht in der graphischen Benutzeroberfläche konfiguriert werden kann (CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS), und welches dazu führt, dass auch der Domänenname, einmal als vollqualifizierter Domänenname (FQDN) und einmal als NETBIOS-Name in den Subject Alternative Name geschrieben wird.
  • Nach RFC2818 darf das Subject eines SSL-Zertifikats leer sein, da bevorzugt die Subject Alternative Name Erweiterung zur Bestimmung der Identität verwendet werden soll. Leider ist dies nicht in allen Anwendungen (unter Anderem Microsoft Network Policy Server) implementiert, sodass es ratsam ist, als Fallback-Option auch noch das Subject zu befüllen.

Im Karteireiter "Extensions" sehen wir, dass als Extended Key Usage (Application Policies) folgende Werte gesetzt sind:

  • 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.5.7.3.1)
  • Client Authentication (Object Identifier: 1.3.6.1.5.5.7.3.2)

Microsoft verwendet den Terminus "Enhanced Key Usage", die korrekte Bezeichnung gemäß RFC 5280 ist allerdings "Extended Key Usage".

Die Extended Key Usages "Smart Card Logon" und "KDC Authentication" erlauben den Domänencontroller, Anmeldung mit Smartcards durchzuführen. Aus Sicherheitsgründen sollten diese nicht in die ausgestellten Zertifikate eingetragen werden, wenn keine Smartcard-Anmeldung und kein Windows Hello for Business (welches auf Smartcard-Anmeldung aufbaut) verwendet werden.

Zertifikatvorlage für manuelle Beantragung von Domänencontroller-Zertifikaten erstellen

Sofern die Zertifikatanforderung von einer Active Directory integrierten Zertifizierungsstelle beantwortet werden soll, muss für diese eine entsprechende Zertifikatvorlage definiert werden . Die Vorgegehensweise hierzu ist im Artikel "Eine Zertifikatvorlage für die manuelle Beantragung von Domänencontroller-Zertifikaten erstellen" beschrieben.

Erstellen des Zertifikatantrags mit Bordmitteln (certutil)

Es ist ebenfalls möglich, den Zertifikatantrag komplett mit vorhandenen Bordmitteln zu erstellen.

Informationsdatei für manuellen Zertifikatantrag erstellen

Aus all diesen Informationen kann nun eine Informationsdatei (.inf) für den Zertifikatantrag erstellt werden. Nachfolgend ein Beispiel, welches einen Zertifikatantrag analog zur Kerberos Authentication Zertifikatvorlage erzeugen sollte:

Die Informationsdatei muss mit UTF-8 Kodierung abgespeichert werden. Bei Abweichender Kodierung wird die Erstellung der Zertifikatanforderung fehlschlagen (siehe Artikel "Die Erstellung einer manuellen Zertifikatanforderung schlägt fehl mit Fehlermeldung "Expected INF file section name 0xe0000000"").

[Version] 
Signature="$Windows NT$"

[Strings]
; Die folgenden drei Variablen an die Umgebung anpassen
SERVER_FQDN = "DC01.intra.adcslabor.de"
DOMAIN_FQDN = "intra.adcslabor.de"
DOMAIN_NETBIOS_NAME = "INTRA"

; Nachfolgende Strings nicht bearbeiten
;----------------------------------------------------------------

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.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%"

Die Datei muss dann als Textdatei mit Dateiendung .inf abgespeichert werden.

Die Datei muss mit ANSI kodiert werden. Einige Tools wie Notepad++ oder Visual Studio Code kodieren per Standard im UTF-8 Format.

Für Hintergrundinformationen zu den einzelnen Optionen siehe folgende Artikel:

Erzeugen des Schlüsselpaars und des Zertifikatantrags

Nun kann anhand dieser Informationsdatei ein Schlüsselpaar und ein Zertifikatantrag erzeugt werden. Die Erstellung erfolgt auf dem Domänencontroller als Administrator per Kommandozeile mit nachfolgendem Befehl:

certreq.exe -new {Informationsdatei}.inf {Zertifikatantrag}.req

Der nun erzeugte Zertifikatantrag kann auf Wunsch eingesehen werden mit folgendem Kommandozeilenbefehl:

certutil -dump {Zertifikatantrag}.req

Erstellen des Zertifikatantrags mit Windows PowerShell

Das PSCertificateEnrollment PowerShell Modul kann über die PowerShell Gallery bezogen und anschließend geladen werden.

Install-Module -Name PSCertificateEnrollment
Import-Module -Name PSCertificateEnrollment

Für die Erstellung der Zertifikatanforderung muss die Windows PowerShell als Administrator gestartet werden, da das Schlüsselpaar für einen Domänencontroller üblicherweise im Systemkontext erzeugt werden soll.

Mit folgendem Befehl wird ein Zertifikatanforderung für ein Domänencontroller-Zertifikat für den Server "dc01.intra.adcslabor.de" erzeugt, welches einen 3072-Bit RSA Schlüssel verwendet.

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

Senden des Zertifikatantrags an die Zertifizierungsstelle

Das Senden einer Zertifikatanforderung an eine Zertifizierungsstelle und das Abholen des ausgestellten Zertifikats ist im Artikel "Eine manuell erstellte Zertifikatanforderung an eine Zertifizierungsstelle senden" beschrieben.

Installation des ausgestellten Zertifikats

Das Zertifikat kann nun auf den Domänencontroller kopiert werden. Es muss nun in den Zertifikatspeicher installiert und mit dem privaten Schlüssel verbunden werden.

Installation via Windows PowerShell

Mit dem PSCertificateEnrollment PowerShell Modul kann die Installation des Zertifikats mit folgendem Befehl erfolgen:

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

Installation via certutil

Mit Bordmitteln (certutil) kann das Zertifikat mit folgendem Kommandozeilenbefehl installiert werden:

certreq -accept {Zertifikat}

Funktionstest

Ob der Domänencontroller das Zertifikat nun nutzt, kann mit folgendem Kommandozeilenbefehl überprüft werden:

certutil -dcinfo

Wenn (z.B. aus Günden der Sicherheitshärtung) das "Smartcard Logon" Extended Key Usage nicht im Domänencontroller-Zertifikat vorkommt, wird dieser Befehl den Fehlercode "CRYPT_E_NOT_FOUND" ausgeben.

Ebenso wird ein (leider wenig detailreicher) Eintrag in das Ereignisprotokoll geschrieben.

Weiterführende Links:

Externe Quellen

de_DEDeutsch
en_USEnglish de_DEDeutsch