Décodeur de CSR (demande de signature de certificat)

Collez simplement votre CSR (demande de signature de certificat) au format PEM pour vérifier le CN, le SAN, le nom d'organisation et l'algorithme de clé publique avant de la soumettre à une autorité de certification. Un outil gratuit pour détecter les erreurs de saisie à temps.

Qu'est-ce que le décodeur de CSR ?

Le décodeur de CSR est un outil gratuit qui affiche, à partir d'une simple CSR (Certificate Signing Request, demande de signature de certificat) au format PEM que vous collez, le Subject prévu (CN, nom d'organisation, etc.), le SAN (Subject Alternative Name), l'algorithme de clé publique ainsi que l'algorithme de signature. Vous pouvez ainsi vérifier immédiatement, avant de soumettre votre demande à une autorité de certification (CA), que le contenu saisi correspond bien à ce que vous souhaitiez.

Alors que notre outil voisin, le « Décodeur de certificats X.509 », analyse des certificats déjà délivrés, cet outil-ci s'adresse à la CSR elle-même, c'est-à-dire à l'étape qui précède l'examen et la délivrance par la CA. Il est donc utile lorsque le certificat n'a pas encore été émis, ou comme dernière vérification avant de regénérer une paire de clés.

Comment utiliser le décodeur de CSR

Collez votre CSR au format PEM Collez tel quel, dans le champ de saisie, le texte qui commence par « -----BEGIN CERTIFICATE REQUEST----- ».
Plusieurs CSR peuvent être collées ensemble Si vous collez plusieurs CSR à la suite, chaque bloc est détecté automatiquement et séparément.
Cliquez sur le bouton « Analyser » Une fois le nombre de CSR détectées vérifié, cliquez sur le bouton pour lancer l'analyse côté serveur.
Consultez les résultats Le Subject, le SAN, l'algorithme de clé publique et les autres informations s'affichent sous forme de liste.

Astuces pour en tirer le meilleur parti

Avant de soumettre votre CSR, vérifiez systématiquement que le CN (nom commun) et le SAN contiennent bien tous les noms d'hôte que vous souhaitez faire certifier. Un oubli dans le SAN entraîne généralement une nouvelle demande de délivrance, avec la perte de temps que cela implique.
Profitez de cette vérification pour vous assurer que l'algorithme de clé publique n'est pas du RSA en dessous de 2048 bits, ni une courbe EC obsolète : cela évite souvent un refus lors de l'examen par la CA.
Avant de réutiliser une même CSR pour plusieurs serveurs, vérifiez à nouveau que le nom d'organisation et le domaine indiqués dans le Subject et le SAN correspondent bien à la demande réellement visée.
Cet outil ne peut vérifier que ce qui est écrit dans la CSR, c'est-à-dire la demande telle que formulée. Les SAN réellement délivrés par la CA peuvent différer selon le résultat de son examen.

Dans quelles situations l'utiliser

Dernière vérification avant soumission à une CA

Avant d'acheter un certificat SSL payant, vérifiez que le CN et le SAN saisis lors de la génération de la CSR sont corrects.

Contrôle de la procédure de génération de CSR en interne

Même sans être à l'aise avec la ligne de commande, un collaborateur peut vérifier visuellement que le contenu d'une CSR générée avec openssl req correspond bien à ce qui était prévu.

Relecture d'une CSR envoyée par le passé

Vous pouvez réexaminer en toute sécurité le contenu d'une CSR conservée sous forme de fichier, sans jamais manipuler la clé privée correspondante.

Vérification des SAN manquants pour un certificat multidomaine

Lorsque plusieurs noms d'hôte doivent être couverts par un seul et même certificat, repérez les oublis dans le SAN avant d'envoyer votre demande.

Glossaire

CSR (demande de signature de certificat): Abréviation de Certificate Signing Request. Il s'agit des données soumises à une CA pour demander la délivrance d'un certificat, regroupant la clé publique et les informations de la demande (Subject, SAN, etc.).
CA (autorité de certification): Abréviation de Certificate Authority. C'est l'organisme tiers qui examine le contenu d'une CSR et délivre le certificat SSL/TLS proprement dit.
CN (nom commun): Champ du Subject désignant le nom d'hôte ou de service principal visé par le certificat. Autrefois, les navigateurs ne vérifiaient que le CN, mais c'est désormais le SAN qui fait foi.
SAN (Subject Alternative Name): Champ d'extension qui énumère les noms d'hôte ou adresses IP supplémentaires couverts par le certificat. Au stade de la CSR, il figure sous la forme d'« extensions demandées » (Requested Extensions).
Requested Extensions (extensions demandées): Attribut par lequel le demandeur d'une CSR indique « je souhaite que ces extensions soient incluses lors de la délivrance ». Le SAN y figure généralement, mais la CA n'est pas tenue de le reprendre tel quel.
Algorithme de clé publique: Méthode de génération de la clé publique contenue dans la CSR. RSA et EC (cryptographie sur courbes elliptiques) sont les principaux, la robustesse variant selon la longueur de clé ou la courbe choisie.

Questions fréquentes

Elle est transmise une fois au serveur pour être analysée, mais elle n'est ni stockée ni journalisée durablement. Une CSR ne contient pas de clé privée, mais évitez tout de même d'y coller des informations de demande que vous ne souhaitez pas divulguer.

Non. Cet outil ne prend en charge que les CSR commençant par « -----BEGIN CERTIFICATE REQUEST----- ». Ne collez jamais une clé privée dans un outil en ligne, quel qu'il soit.

Les causes possibles sont : les lignes BEGIN/END manquantes, une partie Base64 corrompue, ou le collage d'un fichier de certificat ou de clé privée à la place d'une CSR.

Le décodeur de certificats X.509 analyse un certificat déjà délivré par une CA, tandis que cet outil analyse la CSR elle-même, c'est-à-dire la demande avant sa soumission à la CA. La date d'expiration et l'empreinte numérique n'existant pas dans une CSR, elles ne sont donc pas affichées.

Dans la plupart des cas, oui, mais la décision finale appartient à la CA lors de son examen. Certaines CA ignorent même le SAN de la CSR et privilégient les informations saisies dans le formulaire web au moment de la commande.

Anecdote — pourquoi une CSR contient-elle une « signature » ?

Si vous examinez attentivement le contenu d'une CSR, vous trouverez, à la suite du Subject et des informations de clé publique, un algorithme de signature ainsi qu'une valeur de signature. Cela peut sembler étrange à première vue : pourquoi un document qui demande à une CA de « bien vouloir me certifier » contiendrait-il déjà sa propre signature ? La réponse tient au concept de « Proof of Possession » (preuve de possession de la clé privée). En signant l'ensemble de la CSR (Subject, clé publique, etc.) avec la clé privée qui forme une paire avec la clé publique indiquée dans la CSR, le demandeur prouve à la CA qu'il détient bel et bien la clé privée correspondant à cette clé publique. Quelqu'un qui fabriquerait une CSR en y incluant la clé publique d'un tiers ne pourrait pas produire une signature valide sans posséder la clé privée correspondante, ce qui empêche les usurpations d'identité.

Le mécanisme de la CSR a été normalisé en 1986 sous le nom de PKCS#10, l'un des standards de la famille PKCS (Public-Key Cryptography Standards) élaborée par RSA. Il a depuis été redéfini par l'IETF sous la référence RFC 2986, mais dans la pratique, le nom PKCS#10 reste encore aujourd'hui très largement utilisé. Bien que discret dans l'univers des certificats TLS, ce mécanisme constitue le point de départ indispensable de tout le processus de délivrance de certificats.

L'inclusion du SAN dans les Requested Extensions (extensions demandées) d'une CSR est une pratique standardisée relativement récente. À l'origine, le standard PKCS#10 ne prévoyait guère plus que le Subject et le CN. C'est avec la généralisation des certificats multidomaines et des certificats wildcard que chaque CA a développé sa propre méthode pour accepter le SAN. Aujourd'hui, les principaux outils comme openssl prennent en charge de manière standard l'inclusion du SAN via le mécanisme Extension Request défini par la RFC 2985, et c'est précisément à cet emplacement standard (l'attribut extensionRequest au sein des Attributes) que cet outil lit le SAN.

Voir toutes les anecdotes