Modifier ultérieurement le Subject Distinguished Name (DN) d'une demande de certificat (CSR)

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

Il est parfois nécessaire de modifier le Subject Distinguished Name (également appelé Subject, Subject DN, demandeur ou sujet) d'une demande de certificat avant l'émission du certificat.

Dans certaines circonstances, cela est tout à fait possible, comme décrit ci-dessous.

Il existe plusieurs façons d'y parvenir :

  • Modification du Subject DN d'une demande de certificat en attente d'approbation
  • Modification du Subject DN pendant la transmission à l'autorité de certification
  • Modification du Subject DN d'une demande de certificat avant sa soumission à l'autorité de certification

Toutefois, pour les deux méthodes, l'autorité de certification doit être préparée.

Conditions générales

  • La procédure décrite ci-dessous ne fonctionne qu'avec les modèles de certificats hors ligne, c'est-à-dire ceux pour lesquels le demandeur peut déterminer lui-même le contenu du certificat.
  • La procédure fonctionne indépendamment du fait que le modèle de certificat soit configuré pour signer directement la demande de certificat ou pour exiger une vérification par un gestionnaire de certificats.
  • L'activation du drapeau mentionné ci-dessous aura pour conséquence que tous les utilisateurs disposant d'autorisations pour demander un certificat pourront modifier le Subject DN pour tous les modèles de certificats hors ligne publiés sur l'autorité de certification. Cela peut, dans certaines circonstances, poser un problème de sécurité.
  • Les modifications du Subject DN sont effectuées via les "Request Attribute" et ne font donc pas partie de la demande de certificat.
  • Il n'est possible que de "connu"Les types de RDN doivent être activés. Si vous utilisez des types de RDN qui ne sont pas activés par défaut sur l'autorité de certification, vous devez d'abord les activer. active être.

Préparer l'organisme de certification

Veuillez noter que l'activation de ce drapeau peut poser un problème de sécurité.

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.

Tout d'abord, le drapeau CRLF_ALLOW_REQUEST_ATTRIBUTE_SUBJECT doit être activé sur l'autorité de certification. La commande de ligne de commande suivante permet de vérifier si c'est déjà le cas :

certutil -v –getreg CA\CRLFlags

Si le drapeau est en retrait et entre parenthèses, il n'est pas actif.

certutil –setreg CA\CRLFlags +CRLF_ALLOW_REQUEST_ATTRIBUTE_SUBJECT

Il est ensuite nécessaire de redémarrer le service d'autorité de certification pour que les modifications soient lues.

Modification du Subject DN d'une demande de certificat en attente d'approbation

Pour cette variante, des autorisations de gestionnaire de certificats (Issue and Manage Certificates) sont nécessaires.

Le modèle de certificat doit être configuré de manière à ce que les demandes de certificat entrantes ne soient pas directement émises, mais qu'une vérification par un gestionnaire de certificats soit nécessaire (option "CA certificate manager approval").

Les demandes de certificat entrantes atterrissent alors dans la section "Pending Certificates" sur l'autorité de certification.

Dans notre cas, la Inspection de la demande de certificatLe résultat est que le sujet est incorrect et doit être remplacé.

Si le drapeau CRLF_ALLOW_REQUEST_ATTRIBUTE_SUBJECT est activé sur l'autorité de certification, on peut maintenant Subject Noms distinctifs relatifs (RDN) sous la forme "Nom:Valeur". Voici un exemple :

certutil –setattributes {Request-Id} "CN:{Wert-für-CN-Feld}\nOU:{Wert-für-OU-Feld}\nO:{Wert-für-O-Feld}"

Si l'on inspecte maintenant la demande à émettre avec "All Tasks" - "View Atributes/Extensions...", on devrait retrouver les attributs dans le premier onglet.

Si le certificat est maintenant délivré, ces valeurs devraient être reprises dans le certificat délivré.

Si la syntaxe est correcte, la commande signalera toujours un succès, même si le drapeau ci-dessus n'est pas activé sur l'autorité de certification. Elle ne fonctionnera cependant que lorsque le drapeau ci-dessus aura été activé, que le service d'autorité de certification aura été redémarré et que les attributs auront ensuite été modifiés.

Il n'est pas possible de supprimer un RDN existant. Il est toutefois possible de le remplacer par une chaîne vide (par exemple au format "CN="), ce qui a pour conséquence que l'autorité de certification ne peut pas inscrire le RDN dans le certificat délivré.

Modification du Subject DN pendant la transmission à l'autorité de certification

Un demandeur peut également transmettre les manipulations souhaitées du Subject DN pendant la transmission d'une demande de certificat à l'autorité de certification via Request Attribute.

certreq -submit -config "{DNS-Name-der-CA}\{CA-Common-Name}" -attrib "CertificateTemplate:{Name-derZertifikatvorlage}\nCN:{Wert-für-CN-Feld}\nOU:{Wert-für-OU-Feld}\nO:{Wert-für-O-Feld}"

Modification du Subject DN d'une demande de certificat avant sa soumission à l'autorité de certification

Pour cette méthode, la demande de certificat doit être signée par un utilisateur qui dispose d'un Agents d'inscription-certificat d'accréditation. En outre, le certificat d'autorité de certification de l'autorité de certification qui a délivré le certificat d'agent d'inscription doit être conservé dans le dossier de candidature. Objet NTAuthCertificates être déposés dans la structure globale d'Active Directory.

La méthode suivante est généralement aussi effectuée par un gestionnaire de certificats, car un certificat correspondant est nécessaire pour signer la demande. La différence réside dans le fait que le traitement est effectué avant la transmission de la demande de certificat à une autorité de certification. La demande de certificat PKCS#10 est emballée dans une couche CMC, dans laquelle les attributs divergents sont indiqués. Celle-ci est ensuite signée. Cette procédure est nécessaire pour obtenir la demande de certificat originale. Celle-ci ne peut pas être modifiée, sinon la signature ne serait pas valable.

Il faut d'abord créer un fichier INF dont le contenu est le suivant :

[Version]
Signature= "$Windows NT$"

[RequestAttributes]
CN = "{CommonName}"
DC = "{DomainComponent}"
OU = "{OrganizationalUnitName}"
L = "{LocalityName}"
O = "{OrganizationName}"
S = "{StateOrProvinceName}"
C = "{Country}"
G = "{GivenName}"
I = "{Initials}"
E = "{EmailAddress}"
T = "{Title}"
SN = "{SurName}"
StreetAddress = "{StreetAddres}"
DeviceSerialNumber = "{DeviceSerialNumber}"
UnstructuredAddress = "{UnstructuredAddress}"
UnstructuredName = "{UnstructuredName}"

Les valeurs placées entre parenthèses ("{valeur}") doivent être adaptées en conséquence à l'environnement propre. Les valeurs qui ne sont pas nécessaires peuvent être commentées en les faisant précéder d'un point-virgule (" ;") ou on peut supprimer la ligne complète.

Il faut encore noter que les attributs de la demande de certificat initiale et de la version modifiée sont combinés s'ils sont différents. Les attributs qui se chevauchent doivent donc impérativement être écrasés. Il n'est pas possible de les supprimer, mais on peut les écraser avec des chaînes vides (par exemple C=""), ce qui équivaut à une suppression.

Le fichier de stratégie peut maintenant être appliqué à la demande de certificat à l'aide de la commande suivante. Un nouveau fichier d'exigences est créé, dont le nom doit également être indiqué.

certreq -policy {Request-Datei} {Policy-Datei} {Ausgabe-Datei}

Pendant le processus, il est demandé d'indiquer le certificat de signature à utiliser. Celui-ci doit contenir l'Extended Key Usage "Certificate Request Agent".

On peut aussi utiliser un certificat d'autorité de certification, mais ce n'est pas recommandé.

Maintenant, le nouveau fichier Fichier de demande envoyé à l'autorité de certification:

certreq -submit {Ausgabe-Datei}

En inspectant la demande de certificat, on devrait maintenant trouver les nouveaux attributs souhaités dans la couche CMC ainsi que les valeurs précédentes dans la couche PKCS#10.

Il en va de même pour le certificat délivré.

Liens complémentaires :

Sources externes

Les commentaires sont fermés.

fr_FRFrançais
de_DEDeutsch en_USEnglish fr_FRFrançais