Demande manuelle de certificat de contrôleur de domaine

Auteur Uwe GradeneggerPublié le Catégories Active Directory, Utilisation du certificatÉtiquettes , , , , , , ,

Dans certains cas, il n'est pas possible ou souhaitable d'obtenir des certificats de contrôleur de domaine auprès d'une autorité de certification de sa propre structure globale Active Directory.

Dans ce cas, l'utilisation de modèles de certificats n'est pas possible et il faut créer manuellement une demande de certificat (Certificate Signing Request, CSR).

Connaissez-vous TameMyCerts? TameMyCerts est un add-on pour l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend la fonction de l'autorité de certification et permet de Application de la réglementationIl s'agit d'un logiciel de gestion des certificats qui permet d'automatiser l'émission de certificats en toute sécurité. TameMyCerts est unique dans l'écosystème Microsoft, a déjà fait ses preuves dans d'innombrables entreprises du monde entier et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement. Une maintenance professionnelle est également proposée.

Travaux préparatoires

Avant de demander des certificats pour les contrôleurs de domaine, les conditions suivantes doivent être remplies :

  • Les participants dans l'Active Directory doivent faire confiance à la hiérarchie des autorités de certification. Si les certificats de contrôleur de domaine sont délivrés par une autorité de certification étrangère, le certificat de l'autorité de certification racine doit être porté à la connaissance de tous les participants. Cela peut se faire par exemple via une stratégie de groupe, ce qui est décrit dans l'article "Distribuer les autorités de certification racines de confiance via une stratégie de groupe".
  • Pour que l'état de révocation des certificats puisse être vérifié, il faut s'assurer qu'ils puissent être résolus (système de noms de domaine) et téléchargés (routage, proxy, règles de pare-feu) par tous les participants.
  • Dans la mesure où les contrôleurs de domaine doivent traiter les inscriptions par carte à puce, le certificat de l'autorité de certification qui délivre les certificats des contrôleurs de domaine doit être enregistré dans l'objet NTAuthCertificates de l'arborescence globale d'Active Directory.

Inventaire pour la création manuelle d'une demande de certificat

Il convient tout d'abord de déterminer le contenu de la demande de certificat. L'un des modèles de certificat standard pour contrôleurs de domaine peut servir de point de repère. Dans l'exemple suivant, nous nous orientons vers le modèle standard le plus récent, appelé "Kerberos Authentication", qui devrait être utilisé de préférence comme point de départ pour les modèles de certificat de contrôleur de domaine.

Dans l'onglet "Request Handling", on peut voir que la division du modèle de certificat est réglée sur "Signature and Encryption", ce qui a pour conséquence que l'extension Key Usage du certificat contiendra "Key Encipherment" et "Digital Signature", c'est-à-dire la valeur hexadécimale A0. Cela doit déjà être pris en compte lors de la création de la clé sur le contrôleur de domaine qui en fait la demande.

Dans l'onglet "Cryptography", l'agorithme de la clé, la longueur de la clé et le fournisseur de services cryptographiques (CSP) sont importants pour nous. Le modèle d'authentification Kerberos utilise encore des fournisseurs "Legacy", c'est-à-dire des CSP qui ne supportent que RSA. La longueur de la clé doit être fixée à 2072 bits au minimum et le "Microsoft RSA SChannel Cryptographic Provider" est utilisé.

Dans l'onglet "Subject Name", nous voyons que le Subject est vide et qu'un Subject Alternative Name est choisi sous la forme d'un nom DNS.

Les contrôleurs de domaine présentent deux particularités :

  • Dans le modèle de certificat, qui est enregistré en tant qu'objet LDAP dans l'Active Directory, un drapeau est activé qui ne peut pas être configuré dans l'interface utilisateur graphique (CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS) et qui a pour conséquence que le nom de domaine est également écrit dans le Subject Alternative Name, une fois en tant que nom de domaine entièrement qualifié (FQDN) et une fois en tant que nom NETBIOS.
  • Selon la RFC2818, le Subject d'un certificat SSL peut être vide, car l'extension Subject Alternative Name doit être utilisée de préférence pour déterminer l'identité. Malheureusement, cela n'est pas implémenté dans toutes les applications (entre autres Microsoft Network Policy Server), de sorte qu'il est conseillé de remplir également le Subject comme option de repli.

Dans l'onglet "Extensions", nous voyons que les valeurs suivantes sont définies comme Extended Key Usage (Application Policies) :

  • Authentification KDC (identificateur d'objet : 1.3.6.1.5.2.3.5)
  • Connexion par carte à puce (identifiant d'objet : 1.3.6.1.4.1.311.20.2.2)
  • Authentification du serveur (identificateur d'objet : 1.3.6.1.5.5.7.3.1)
  • Authentification du client (identificateur d'objet : 1.3.6.1.5.5.7.3.2)

Microsoft utilise le terme "Enhanced Key Usage" (utilisation améliorée des clés), mais la désignation correcte selon le RFC 5280 est "Extended Key Usage"..

Les Extended Key Usages "Smart Card Logon" et "KDC Authentication" permettent aux contrôleurs de domaine d'effectuer des connexions par carte à puce. Pour des raisons de sécurité, ils ne doivent pas être inscrits dans les certificats émis si aucune connexion par carte à puce et aucun Windows Hello for Business (qui s'appuie sur la connexion par carte à puce) ne sont utilisés.

Créer un modèle de certificat pour la demande manuelle de certificats de contrôleur de domaine

Si la demande de certificat doit être traitée par une autorité de certification intégrée à Active Directory, il faut définir un modèle de certificat pour cette autorité. La procédure à suivre est décrite dans l'article "Créer un modèle de certificat pour la demande manuelle de certificats de contrôleur de domaine" décrit.

Création de la demande de certificat avec les moyens du bord (certutil)

Il est également possible de créer entièrement la demande de certificat avec les outils de bord existants.

Créer un fichier d'informations pour la demande manuelle de certificat

A partir de toutes ces informations, un fichier d'information (.inf) peut maintenant être créé pour la demande de certificat. Voici un exemple qui devrait générer une demande de certificat analogue au modèle de certificat Kerberos Authentication :

Le fichier d'information doit être enregistré avec le codage UTF-8. Si l'encodage est différent, la création de la demande de certificat échouera (voir article "La création d'une demande manuelle de certificat échoue avec le message d'erreur "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%"

Le fichier doit ensuite être enregistré en tant que fichier texte avec l'extension .inf.

Le fichier doit être encodé en ANSI. Certains outils comme Notepad++ ou Visual Studio Code encodent par défaut au format UTF-8.

Pour des informations de fond sur les différentes options, voir les articles suivants :

Génération de la paire de clés et de la demande de certificat

Il est maintenant possible de générer une paire de clés et une demande de certificat à partir de ce fichier d'informations. La création se fait sur le contrôleur de domaine en tant qu'administrateur via la ligne de commande avec la commande suivante :

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

La demande de certificat qui vient d'être générée peut être consultée sur demande avec la commande de ligne de commande suivante :

certutil -dump {Zertifikatantrag}.req

Création de la demande de certificat avec Windows PowerShell

Le site PSCertificateEnrollment Le module PowerShell peut être utilisé via Galerie PowerShell et être ensuite chargés.

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

Pour la création de la demande de certificat, Windows PowerShell doit être lancé en tant qu'administrateur, car la paire de clés pour un contrôleur de domaine doit normalement être générée dans le contexte du système.

La commande suivante génère une demande de certificat de contrôleur de domaine pour le serveur "dc01.intra.adcslabor.de", qui utilise une clé RSA de 3072 bits.

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

Envoi de la demande de certificat à l'autorité de certification

L'envoi d'une demande de certificat à une autorité de certification et la récupération du certificat délivré sont décrits dans l'article "Envoyer une demande de certificat créée manuellement à une autorité de certification" décrit.

Installation du certificat délivré

Le certificat peut maintenant être copié sur le contrôleur de domaine. Il doit maintenant être installé dans le magasin de certificats et associé à la clé privée.

Installation via Windows PowerShell

Avec le module PSCertificateEnrollment PowerShell, l'installation du certificat peut se faire avec la commande suivante :

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

Installation via certutil

Avec les moyens du bord (certutil), le certificat peut être installé avec la commande de ligne de commande suivante :

certreq -accept {Zertifikat}

Test de fonctionnement

La commande de ligne de commande suivante permet de vérifier si le contrôleur de domaine utilise à présent le certificat :

certutil -dcinfo

Si (par exemple pour des raisons de Durcissement de sécurité) le "Smartcard Logon" Extended Key Usage n'apparaît pas dans le certificat du contrôleur de domaine, cette commande affichera le code d'erreur "CRYPT_E_NOT_FOUND"..

De même, une entrée (malheureusement peu détaillée) est écrite dans le journal des événements.

Liens complémentaires :

Sources externes

Les commentaires sont fermés.

fr_FRFrançais
de_DEDeutsch en_USEnglish fr_FRFrançais