Comment générer une CSR pour un certificat de signature de code via MMC

Le composant logiciel enfichable Certificats dans la Console de gestion Microsoft (MMC) permet de créer une demande de certificat PKCS #10 sur une machine Windows sans logiciel supplémentaire. Ce guide passe en revue cet assistant écran par écran pour un certificat de signature de code, et il commence par la partie que la plupart des anciens tutoriels omettent : les règles concernant les clés privées de signature de code ont changé le 1er juin 2023, et elles déterminent si une demande créée via MMC est utilisable ou non.

Lisez cette exigence avant d’ouvrir l’assistant. Le reste du guide suppose que vous savez quel parcours suit votre commande.

Les clés de signature de code doivent être générées sur du matériel

En vertu des exigences de base du CA/Browser Forum pour la signature de code, en vigueur depuis le 1er juin 2023, la clé privée de tout certificat de signature de code de confiance publique doit être générée, stockée et utilisée dans un module cryptographique matériel certifié au moins FIPS 140-2 Niveau 2, Critères Communs EAL 4+, ou une norme équivalente. Cela concerne aussi bien les certificats standards (validation d’organisation et validation individuelle) que les certificats à validation étendue. La signature de code EV fonctionnait déjà ainsi ; le changement de 2023 a étendu la même règle aux produits standards.

Les exigences fixent également les caractéristiques de la clé elle-même. Les clés RSA doivent faire au moins 3072 bits, les clés ECDSA doivent utiliser les courbes NIST P-256, P-384 ou P-521, et SHA-1 n’est pas autorisé pour les certificats de signature de code.

Tout aussi important, l’autorité de certification doit prouver que la clé se trouve réellement sur du matériel, en utilisant l’une des méthodes listées dans les exigences. En pratique, voici celles que vous rencontrerez :

• L’AC vous expédie un jeton matériel qui contient déjà une paire de clés générée par l’AC sur cet appareil.
• Vous contresignez la demande avec un certificat du fabricant, ce qui correspond à ce qu’on appelle l’attestation de clé : la preuve que la clé a été créée de manière non exportable à l’intérieur d’un appareil conforme.
• Vous utilisez une combinaison de bibliothèque cryptographique et de module matériel prescrite par l’AC.
• Vous fournissez un audit informatique, un rapport d’un service de protection de clés cloud, ou un accord que vous signez via un service de signature conforme.

Aucune de ces conditions n’est satisfaite par une demande que MMC construit à partir du Microsoft Software Key Storage Provider. Ce fournisseur crée la clé dans le stockage logiciel de Windows, ce qui fait que la demande résultante sera rejetée pour un certificat de signature de code de confiance publique, quelle que soit la manière dont le reste de l’assistant est rempli. Les autorités de certification ont également cessé, au même moment, de proposer la génération de clé via navigateur et la livraison au format .pfx téléchargeable pour ces produits.

Si votre objectif est un certificat de confiance publique, le parcours est déterminé au moment de la commande. Soit l’AC génère la clé sur un jeton et vous l’envoie par courrier, auquel cas vous n’avez aucune CSR à créer, soit vous générez la clé sur du matériel que vous possédez déjà et vous soumettez une attestation avec la demande. Le guide sur les méthodes de livraison des certificats de signature de code compare les deux approches, et les étapes spécifiques aux appareils se trouvent ici :

• YubiKey 5 FIPS : génération de CSR et attestation
• Luna Network Attached HSM v7.x : guide de CSR et d’attestation

Dans quels cas MMC reste pertinent

L’assistant n’est pas obsolète. C’est le fournisseur que vous choisissez à l’intérieur de celui-ci qui détermine où la clé naît, et il existe trois situations où il reste le bon outil.

Une demande adossée à un fournisseur matériel. La liste des fournisseurs de services cryptographiques dans l’assistant affiche tous les fournisseurs installés sur la machine, pas seulement les fournisseurs logiciels de Microsoft. Une fois le pilote d’un jeton ou le minipilote d’une carte à puce installé, son fournisseur y apparaît également. La différence réside dans l’endroit où naît la paire de clés : un fournisseur logiciel la génère sur votre ordinateur, tandis qu’un fournisseur matériel, comme un fournisseur de carte à puce ou de jeton, demande à l’appareil de générer la paire, et l’appareil conserve ensuite la clé privée et contrôle l’accès à celle-ci. Sélectionnez un fournisseur matériel et MMC produit une demande pour une clé qui n’a jamais existé en tant que logiciel.

Deux mises en garde avant de vous fier à cela. MMC produit une demande PKCS #10 et rien de plus ; il ne génère donc pas le fichier d’attestation de clé que la plupart des autorités de certification exigent en complément. Celui-ci provient de l’outillage propre à l’appareil. Et c’est l’AC qui décide quelle méthode de vérification elle acceptera, beaucoup d’entre elles imposant leur propre utilitaire à cet effet. Demandez à votre AC quel parcours elle prend en charge avant de générer quoi que ce soit, car une clé créée avec le mauvais outil ne peut pas être déplacée par la suite.

Une AC interne ou d’entreprise. Les exigences de base régissent les certificats de confiance publique. Un certificat émis par votre propre AC des services de certificats Active Directory pour une signature interne échappe à ce périmètre ; c’est donc votre propre politique qui décide comment la clé est stockée, et un fournisseur logiciel constitue un choix légitime. N’oubliez cependant pas ce que vous obtenez : un code signé de cette manière n’est fiable que sur les machines qui font déjà confiance à votre racine interne, et partout ailleurs, Windows continue de considérer l’éditeur comme inconnu.

Signature de test et préparation. Une demande logicielle convient tout à fait pour un certificat de test, et pour mettre au point les valeurs exactes du sujet que vous réutiliserez lorsque vous générerez la vraie demande sur votre matériel.

Étape 1 : Ouvrir le composant logiciel enfichable Certificats

Appuyez sur la touche Windows + R, tapez mmc et appuyez sur Entrée. Vous pouvez aussi taper mmc dans le champ de recherche de la barre des tâches et l’ouvrir depuis là. Acceptez l’invite du Contrôle de compte d’utilisateur. Une fenêtre Console1 vide s’ouvre.

Cliquez sur Fichier, puis sur Ajouter/Supprimer un composant logiciel enfichable. Dans la liste Composants logiciels enfichables disponibles, sélectionnez Certificats et cliquez sur Ajouter.

Windows demande alors quel magasin de certificats le composant logiciel enfichable doit gérer : Mon compte d’utilisateur, Compte de service ou Compte d’ordinateur. Ce choix importe davantage pour un certificat de signature de code que pour un certificat de serveur Web, car il détermine où réside la clé et dans quel magasin votre outil de signature effectue ses recherches :

• Mon compte d’utilisateur place la clé dans le magasin personnel de l’utilisateur connecté. C’est le choix habituel lorsqu’un développeur signe de manière interactive, car signtool de Microsoft ouvre par défaut le magasin My de l’utilisateur actuel.
• Compte d’ordinateur place la clé dans le magasin de la machine, ce qui convient à un serveur de build où la signature s’exécute sous un compte de service. Les outils de signature doivent alors être configurés pour aller chercher là : signtool prend l’option /sm pour le magasin de la machine.

Si vous choisissez Mon compte d’utilisateur, cliquez sur Terminer. Si vous choisissez Compte d’ordinateur, cliquez sur Suivant, laissez Ordinateur local (l’ordinateur sur lequel cette console s’exécute) sélectionné et cliquez sur Terminer. Dans les deux cas, cliquez sur OK pour fermer la fenêtre Ajouter ou supprimer des composants logiciels enfichables.

Deux raccourcis permettent de sauter entièrement l’étape du composant logiciel enfichable lorsque vous n’avez pas besoin d’une console enregistrée : certmgr.msc ouvre directement les magasins de certificats de l’utilisateur actuel, et certlm.msc ouvre les magasins de l’ordinateur local. Si vous avez construit la console manuellement et prévoyez d’y revenir, utilisez Fichier puis Enregistrer pour la conserver.

Étape 2 : Démarrer une demande personnalisée

Dans l’arborescence de la console, développez Certificats et faites un clic droit sur le dossier Personnel (ou sur le dossier Certificats en dessous, si le magasin contient déjà des certificats). Choisissez Toutes les tâches, puis Opérations avancées, puis Créer une demande personnalisée. Les mêmes commandes se trouvent dans le menu Action si vous préférez.

L’assistant Inscription de certificats s’ouvre sur Avant de commencer. Cliquez sur Suivant.

Sur Sélectionner la stratégie d’inscription de certificats, sous la rubrique Demande personnalisée, sélectionnez Continuer sans stratégie d’inscription, puis cliquez sur Suivant. Cela indique à Windows de créer une demande autonome pour une AC externe plutôt que de s’inscrire par rapport à un modèle Active Directory.

La page Demande personnalisée comporte trois paramètres :

• Modèle. Choisissez (Aucun modèle) Clé CNG. Cela utilise un fournisseur de stockage de clés (Key Storage Provider), ce qui correspond à la manière dont les fournisseurs matériels modernes s’enregistrent. (Aucun modèle) Clé héritée utilise les anciens fournisseurs CryptoAPI et n’est nécessaire que lorsqu’un appareil ou une application spécifique l’exige.
• Supprimer les extensions par défaut. Laissez cette case décochée, sauf si vous avez l’intention d’envoyer uniquement les extensions que vous définissez manuellement.
• Format de demande. Sélectionnez PKCS #10. Toute AC l’accepte. CMC est destiné aux demandes visant des systèmes qui le requièrent spécifiquement.

Cliquez sur Suivant. Sur la page Informations sur le certificat, vous verrez une seule ligne intitulée Demande personnalisée avec un statut Disponible. Cliquez sur la flèche Détails à droite de cette ligne pour la développer, puis cliquez sur le bouton Propriétés qui apparaît. La boîte de dialogue Propriétés du certificat s’ouvre avec quatre onglets : Général, Objet, Extensions et Clé privée.

Étape 3 : Saisir les détails du sujet

Sous l’onglet Général, saisissez un Nom convivial et, si vous le souhaitez, une Description. Ce sont deux étiquettes locales qui vous aideront à retrouver le certificat dans le magasin plus tard. Aucune des deux ne fait partie de la demande, et aucune n’est validée.

Passez à l’onglet Objet. C’est ici qu’est assemblée l’identité qui apparaîtra comme éditeur du logiciel. Sous Nom de l’objet, choisissez une entrée dans la liste déroulante Type, saisissez le texte correspondant dans la zone Valeur, puis cliquez sur Ajouter >. Chaque entrée passe dans la liste de droite, où Windows l’affiche sous forme abrégée (CN=, O=, OU=, L=, S=, C=). Répétez cette opération pour chacun des éléments suivants :

• Nom commun (CN) : le nom enregistré de votre organisation, ou le nom légal complet de l’individu pour un certificat individuel. C’est l’identité que voient les utilisateurs lorsque Windows nomme l’éditeur.
• Organisation (O) : le nom d’organisation enregistré auquel appartient le certificat. Si le nom contient un symbole comme une esperluette, écrivez-le en toutes lettres ou supprimez-le, car ces caractères ne sont pas acceptés dans ce champ. « AB & C Corporation » devient « AB and C Corporation » ou « ABC Corporation ».
• Unité organisationnelle (OU) : le service chargé de l’inscription, par exemple l’IT. Facultatif.
• Localité (L) : la ville où l’organisation est enregistrée.
• État (S) : l’État ou la province, écrit en toutes lettres. Utilisez Floride, et non FL.
• Pays (C) : le code pays ISO à deux lettres du lieu où l’organisation est enregistrée, par exemple US.

Saisissez des informations qui correspondent exactement à vos documents légaux, car l’AC les valide par rapport à des sources publiques et officielles avant d’émettre quoi que ce soit. Une incohérence est la raison la plus fréquente d’un blocage dans une commande de certificat de signature de code.

Laissez la zone Autre nom vide. Les noms alternatifs du sujet identifient les serveurs par nom d’hôte, et un certificat de signature de code identifie un éditeur plutôt qu’une machine, il ne comporte donc aucune entrée DNS.

Étape 4 : Choisir le fournisseur, la taille de clé et le hachage

Ouvrez l’onglet Clé privée. Il contient plusieurs groupes repliables : Fournisseur de services de chiffrement, Options de clé, Sélectionner l’algorithme de hachage, Sélectionner le format de signature et Autorisations de clé. Cliquez sur un intitulé pour le développer.

Développez d’abord Fournisseur de services de chiffrement, car c’est le paramètre que les exigences de base mettent en avant. La liste affiche tous les fournisseurs installés sur la machine, chacun avec une case à cocher. Assurez-vous que seul le fournisseur que vous souhaitez réellement utiliser est coché :

• Pour un certificat de signature de code de confiance publique, sélectionnez le fournisseur associé à votre jeton ou à votre HSM. Il n’apparaît dans cette liste qu’une fois le pilote ou le minipilote de l’appareil installé ; branchez donc d’abord l’appareil et installez son logiciel.
• RSA, Microsoft Software Key Storage Provider est l’option logicielle. Ne l’utilisez que pour une AC interne ou un certificat de test.
• La liste comporte également des entrées ECDSA telles que ECDSA_P256, Microsoft Software Key Storage Provider. Vérifiez que votre AC prend en charge ECDSA pour la signature de code avant d’en choisir une, car ce n’est pas le cas de tous les produits.

Développez Options de clé. Réglez Taille de clé sur 3072 ou 4096. RSA 3072 est le seuil minimal pour la signature de code, et une demande construite avec 2048 sera refusée. Si la liste déroulante ne propose pas 3072 pour le fournisseur choisi, utilisez 4096.

Dans le même groupe, laissez décochée l’option Rendre la clé privée exportable. C’est la correction la plus importante à apporter aux anciennes instructions concernant MMC. Une clé exportable peut être copiée de la machine sous forme de fichier .pfx, ce qui est exactement ce que l’exigence matérielle vise à empêcher, et le parcours d’attestation certifie explicitement que la clé a été créée de manière non exportable. Le seul cas justifiant de cocher cette case est une configuration de signature interne où vous devez déplacer le certificat et la clé vers une autre machine, et même dans ce cas, cela affaiblit la clé. Laissez également décochée l’option Autoriser l’archivage de la clé privée. La Protection renforcée de la clé privée est facultative et fait en sorte que Windows demande une confirmation à chaque utilisation de la clé, ce qui est raisonnable pour une clé de signature sur un poste de travail partagé.

Développez Sélectionner l’algorithme de hachage et réglez Algorithme de hachage sur sha256. SHA-1 n’est pas autorisé pour les certificats de signature de code.

L’onglet Extensions mérite d’être examiné si vous vous inscrivez auprès d’une AC interne. Développez Utilisation de la clé et ajoutez Signature numérique, puis développez Utilisation de la clé étendue (stratégies d’application) et ajoutez Signature de code. Une AC publique construit le certificat à partir du produit que vous avez commandé plutôt qu’à partir des extensions de votre demande, donc pour une commande publique, cet onglet ne change rien. Une AC interne peut en tenir compte.

Cliquez sur OK pour fermer Propriétés du certificat, puis sur Suivant.

Étape 5 : Enregistrer la demande

L’assistant demande Où voulez-vous enregistrer la demande hors connexion ? Cliquez sur Parcourir, choisissez un dossier que vous contrôlez, donnez au fichier un nom tel que codesigning.req et confirmez. Naviguez toujours vers un dossier plutôt que de taper un simple nom de fichier : sans chemin d’accès, la demande atterrit dans le dossier depuis lequel la console s’exécute, ce qui est rarement l’endroit souhaité et difficile à retrouver ensuite.

Sous Format de fichier, laissez Base 64 sélectionné. C’est la forme textuelle que les AC collent dans un champ d’inscription. Binaire écrit du DER brut, que la plupart des formulaires de commande rejettent. Cliquez sur Terminer.

Ouvrez le fichier dans un éditeur de texte brut, tel que le Bloc-notes, et copiez l’ensemble du bloc, y compris les première et dernière lignes :

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIEbDCCA1QCAQAwZDELMAkGA1UEBhMCVVMx...
...base64 encoded request...
-----END NEW CERTIFICATE REQUEST-----

Les outils d’inscription Windows écrivent normalement la formulation plus longue montrée ci-dessus, avec le mot NEW dans les lignes marqueurs, tandis qu’OpenSSL écrit BEGIN CERTIFICATE REQUEST et END CERTIFICATE REQUEST. Si votre fichier utilise la forme plus courte, rien n’est anormal : le contenu constitue la même demande PKCS #10 et les autorités de certification acceptent l’une comme l’autre. Copiez exactement ce que vous voyez et ne réécrivez pas les lignes marqueurs.

Un point que l’assistant ne produit pas est un fichier de clé privée que vous pourriez enregistrer ou copier, et les anciens guides qui vous disent de conserver en lieu sûr les fichiers de clé publique et privée décrivent en réalité un autre outil. MMC conserve la nouvelle clé privée à l’intérieur du magasin de clés Windows, sous le compte que vous avez sélectionné à l’étape 1, sur cet ordinateur uniquement. La demande en attente apparaît normalement dans le composant logiciel enfichable sous Demandes d’inscription de certificats. Trois conséquences en découlent :

• Ne supprimez pas la demande en attente pendant que vous attendez l’émission. La supprimer élimine aussi la clé, et le certificat émis deviendra alors inutilisable.
• Finalisez la commande sur le même ordinateur, dans le même contexte de compte. Une demande générée dans le magasin de l’utilisateur ne peut pas être finalisée dans le magasin de la machine, ni l’inverse.
• Ne reconstruisez pas et ne réimagez pas la machine entre la génération de la demande et l’installation du certificat.

Étape 6 : Vérifier la demande avant de la soumettre

Une demande ne peut pas être modifiée une fois créée, alors vérifiez-la maintenant plutôt que de découvrir une faute de frappe après le début de la validation. Windows peut la relire sans logiciel supplémentaire. Ouvrez une invite de commande dans le dossier contenant le fichier et exécutez :

certutil -dump codesigning.req

Si OpenSSL est installé, cette commande lit le même fichier et vérifie également la signature de la demande :

openssl req -noout -text -verify -in codesigning.req

Confirmez quatre éléments dans le résultat : l’objet liste le pays, l’État, la localité, l’organisation et le nom commun exactement comme vous le souhaitez ; la clé publique fait 3072 bits ou plus, ou utilise une courbe ECDSA approuvée ; l’algorithme de signature est SHA-256 ; et, avec la commande OpenSSL, qu’une ligne verify OK apparaît, confirmant que la demande a bien été signée par la clé privée correspondante. Vous pouvez également coller le bloc dans le décodeur de CSR pour le lire dans un navigateur.

Si quelque chose ne va pas, générez une nouvelle demande à partir de l’étape 2. Pour voir quels fournisseurs sont disponibles sur la machine, y compris tout fournisseur matériel que vous avez installé, exécutez :

certutil -csplist

Étape 7 : Installer le certificat émis sur la même machine

Soumettez le bloc Base 64 lors de votre commande de certificat, effectuez la validation demandée par l’AC, puis téléchargez le certificat émis à son arrivée. Comme la clé privée est restée dans le magasin de clés Windows, le certificat doit revenir dans ce même magasin pour être utilisable.

Dans le même composant logiciel enfichable, faites un clic droit sur Personnel, choisissez Toutes les tâches, puis Importer, et pointez l’assistant vers le fichier. Windows associe le certificat à la clé qu’il avait conservée à partir de la demande, et l’entrée en attente sous Demandes d’inscription de certificats disparaît. Ouvrez ensuite le certificat et vérifiez que l’onglet Général indique que vous disposez d’une clé privée correspondant à ce certificat. Si cette ligne est absente, l’association n’a pas eu lieu, et vous pouvez la refaire avec le numéro de série du certificat :

certutil -repairstore My <serial-number>

Ajoutez l’option -user si le certificat appartient à l’utilisateur actuel plutôt qu’à la machine :

certutil -user -repairstore My <serial-number>

À partir de là, votre outil de signature récupère le certificat dans le magasin. N’oubliez pas le magasin que vous avez choisi à l’étape 1 : signtool lit le magasin My de l’utilisateur actuel, sauf si vous transmettez /sm pour le magasin de la machine.

D’autres méthodes pour créer la même demande sont présentées dans les guides CertReq, OpenSSL, Java Keystore et macOS Keychain Access. Vous pourriez également être intéressé par les tutoriels sur la signature de code dans leur ensemble ou par d’autres méthodes pour générer une CSR.

Questions fréquemment posées