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

Un certificat de signature de code prouve qui a publié un logiciel et montre que le code n’a pas été modifié depuis sa signature. Pour en commander un, vous créez une CSR (Certificate Signing Request), le bloc de texte encodé que l’autorité de certification (CA) utilise pour vous identifier et délivrer le certificat. Les CSR de signature de code suivent des règles différentes de celles que vous créez pour un site web, et ces règles ont changé en 2023. Ce guide explique le processus actuel et les méthodes qui s’appliquent encore.

La clé privée doit résider sur un matériel physique

Depuis le 1er juin 2023, les exigences de base du CA/Browser Forum pour la signature de code imposent que la clé privée de chaque certificat de signature de code publiquement approuvé soit générée et stockée sur un matériel conforme à la norme FIPS 140-2 Niveau 2, Critères Communs EAL4+, ou une norme équivalente. Cela s’applique aussi bien aux certificats standard (Organization Validation et Individual Validation) qu’aux certificats Extended Validation (EV). La signature de code EV exigeait déjà un support matériel avant cette date ; le changement de 2023 a étendu la même règle aux certificats standard.

La conséquence pratique est importante : une clé privée et une CSR générées purement en logiciel, dans un navigateur, ou dans un fichier ordinaire sur un ordinateur portable ou un serveur, ne sont plus acceptées pour un certificat de signature de code publiquement approuvé. Les CA ont cessé de prendre en charge la génération de clés via navigateur et la livraison de fichiers .pfx téléchargeables pour ces produits. La clé doit être créée sur, et rester sur, un dispositif conforme. Il reste deux voies valides :

• Un jeton matériel préconfiguré par la CA. La CA génère la paire de clés et la CSR directement sur un jeton USB certifié, installe le certificat émis dessus, et vous envoie le jeton par courrier. Vous signez avec le jeton branché. Avec cette méthode, vous ne générez pas vous-même la CSR.
• Votre propre HSM ou HSM cloud, avec attestation de clé. Si vous disposez déjà d’un module de sécurité matériel (HSM) conforme (ou d’un HSM cloud tel qu’AWS CloudHSM, Azure Dedicated HSM, ou Google Cloud HSM), vous générez la clé et la CSR sur ce dispositif et fournissez un fichier d’attestation qui prouve à la CA que la clé a été créée sur un matériel conforme, et qu’elle ne peut en être exportée.

La voie que vous choisissez est déterminée au moment de la commande. Pour une comparaison côte à côte, consultez les méthodes de livraison des certificats de signature de code.

Option 1 : jeton avec expédition (la CA crée la CSR)

C’est la voie que choisissent la plupart des particuliers et des petites équipes, car elle ne nécessite aucun matériel de votre part. Lorsque vous sélectionnez jeton avec expédition au moment de la commande, la CA se charge de la génération de la clé et de la création de la CSR sur un jeton certifié de son côté, puis vous envoie le jeton avec le certificat déjà installé. Il n’y a pas de CSR à coller dans un formulaire de commande.

Ce que vous devez faire à la place :

• Compléter les étapes de validation demandées par la CA (vérification de l’organisation ou de l’identité).
• Attendre la réception du jeton physique.
• Installer les pilotes du jeton (généralement SafeNet Authentication Client) et signer votre logiciel avec le jeton connecté.

Option 2 : générer la CSR sur votre propre HSM ou jeton

Si vous possédez déjà un matériel conforme, vous générez la paire de clés et la CSR sur ce dispositif et fournissez une attestation correspondante. Les étapes exactes dépendent du matériel, suivez donc le guide de votre appareil ou la documentation propre à votre fournisseur :

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

Pour les HSM cloud (AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM), générez la clé à l’intérieur du HSM, exportez la CSR et le fichier d’attestation produit par la plateforme, et soumettez les deux à votre CA lors de la commande.

Quelques détails s’appliquent à toutes les CSR reposant sur du matériel :

• Utilisez une clé RSA d’au moins 3072 bits, ou une clé ECDSA équivalente, comme le précisent les exigences de base.
• Marquez la clé comme non exportable afin qu’elle ne puisse pas quitter le dispositif.
• Générez l’attestation en même temps que la clé. Une CSR sans attestation valide sera rejetée.

Où se situent désormais les méthodes OpenSSL, Java Keytool, MMC, CertReq et Trousseau d’accès

Vous avez peut-être déjà vu d’anciennes instructions qui créent une CSR de signature de code avec OpenSSL, l’utilitaire Java keytool, la Console de gestion Microsoft (MMC), la commande Windows certreq, ou Trousseau d’accès sous macOS. Utilisés seuls, ces outils génèrent une clé en logiciel, de sorte qu’une CSR produite ainsi n’est plus valide aujourd’hui pour un certificat de signature de code publiquement approuvé.

Ils conservent une utilité lorsque vous les pointez vers un matériel conforme plutôt que vers un magasin de clés logiciel. Par exemple, OpenSSL peut créer une CSR à partir d’un HSM via un module PKCS#11, et CertReq ou MMC peuvent construire une demande utilisant un fournisseur de stockage de clés matériel. N’utilisez ces références que dans ce contexte, et associez toujours la demande à une attestation provenant du dispositif :

• Générer une CSR de signature de code avec OpenSSL
• Générer une CSR de signature de code avec Java Keystore
• Générer une CSR de signature de code avec CertReq
• Générer une CSR de signature de code avec la Console de gestion Microsoft
• Générer une CSR de signature de code avec Trousseau d’accès macOS

Vérifier le contenu de votre CSR

Avant de soumettre une CSR, confirmez que les détails du sujet sont corrects. Si vous disposez d’OpenSSL, décodez la demande localement et relisez-la en texte clair :

openssl req -noout -text -in codesigning.csr

Vérifiez l’organisation ou le nom commun ainsi que la taille de la clé dans le résultat. Un vérificateur de CSR standard pour site web n’est pas l’outil adapté ici, car une CSR de signature de code est liée à un matériel et est validée par attestation plutôt que par une analyse HTTPS publique.

Questions fréquemment posées