Demande manuelle d'un certificat Remote Desktop (RDP)

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

Il existe des cas où il n'est pas possible ou souhaitable d'obtenir des certificats de bureau à distance auprès d'une autorité de certification dans sa propre structure Active Directory, par exemple lorsque le système concerné n'est pas membre du domaine.

Dans ce cas, l'utilisation de modèles de certificat 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 Remote Desktop, 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 Remote Desktop sont émis 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 expliqué 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.

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 les contrôleurs de domaine peut servir de point de repère. Dans l'exemple suivant, nous nous basons sur le modèle présenté dans l'article „Configurer un modèle de certificat pour les certificats Remote Desktop (RDP)“pour les certificats de bureau à distance.

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 être pris en compte dès la création de la clé sur l'ordinateur demandeur.

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 de bureau à distance utilise encore des fournisseurs „hérités“, c'est-à-dire des CSP qui ne prennent en charge que RSA. La longueur de la clé est fixée à 2048 bits 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.

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

  • Authentification du bureau distant (identificateur d'objet : 1.3.6.1.4.1.311.54.1.2)

Créer un modèle de certificat pour la demande manuelle de certificats Remote Desktop

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 „Configurer un modèle de certificat pour les certificats Remote Desktop (RDP)“est décrite dans l'onglet „Certificats“. Pour les demandes manuelles, il faut toutefois configurer l'onglet "Subject Name" de manière à ce que le demandeur puisse indiquer l'identité avec la demande de certificat.

Toutefois, comme cela peut poser un problème de sécurité, les demandes de certificat doivent être validées par un gestionnaire de certificats, ce qui peut être réalisé en activant l'option „CA certificate manager approval“ dans l'onglet „Issuance Requirements“.

Étant donné que lors d'une demande manuelle de certificat, c'est un compte d'utilisateur et non un compte d'ordinateur qui fera la demande de certificat, l'utilisateur correspondant ou un groupe de sécurité dont il est membre doit obtenir le droit „Enroll“.

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 folgende Variable an die Umgebung anpassen
SERVER_FQDN = "CA01.intra.adcslabor.de"

; Nachfolgende Strings nicht bearbeiten
szOID_SUBJECT_ALT_NAME2 = "2.5.29.17" 
szOID_ENHANCED_KEY_USAGE = "2.5.29.37" 
szOID_KP_RDC_AUTH = "1.3.6.1.4.1.311.54.1.2"

 [NewRequest] 
; Nach RFC2818 sollte das Subject nicht mehr verwendet werden und darf leer sein (Subject =)
Subject = "CN=" 
; Der private Schluessel ist nicht exportierbar 
Exportable = FALSE
; Das Schluesselpaar wird im lokalen Maschinenspeicher erzeugt
MachineKeySet = True
; Empfohlene Schluessellaengen: 2048, 3072, 4096
; 2048 Bit sollten nur noch bis 2021 verwendet werden
; Vor Erhöhung der Schluessellaenge sollte die Kompatibilitaet sichergestellt sein
KeyLength = 3072
; AT_KEYEXCHANGE 
KeySpec = 1
; Digital Signature, Key Encipherment 
KeyUsage = 0xA0
ProviderName = "Microsoft RSA SChannel Cryptographic Provider" 
ProviderType = 12 
SMIME = FALSE 
RequestType = CMC

[Extensions]
%szOID_SUBJECT_ALT_NAME2% = "{text}dns=%SERVER_FQDN%"
%szOID_ENHANCED_KEY_USAGE% = "{text}%szOID_KP_RDC_AUTH%"

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 l'ordinateur 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

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 l'ordinateur. Il doit maintenant être installé dans le magasin de certificats et associé à la clé privée. Cela se fait à l'aide de la commande de ligne de commande suivante : 

certreq -accept {Zertifikat}

Activation du certificat et test de fonctionnement ultérieur

L'attribution du certificat à l'hôte de la session Remote Desktop est décrite dans l'article „Attribuer manuellement un certificat Remote Desktop (RDP)" décrit.

L'article „Comment identifier le certificat Remotedesktop actuellement utilisé" explique comment identifier le certificat Remotedesktop.„Identification du certificat Remote Desktop (RDP) actif" décrit.

Liens complémentaires :

Sources externes

Les commentaires sont fermés.

fr_FRFrançais
de_DEDeutsch en_USEnglish fr_FRFrançais