Thème

Outils populaires

Décodeur CSR

Collez un CSR (demande de signature de certificat) et lisez chaque champ qu'il contient : le sujet, la clé, chaque nom alternatif et chaque extension. La page vérifie aussi la demande au regard des règles qu'applique une AC publique, et vous dit si votre clé privée lui correspond. Un certificat SSL se décode ici aussi.

Décodé dans votre navigateur avec Web Crypto · rien n'est envoyé, rien n'est conservé · Baseline Requirements du CA/Browser Forum v2.3.1

Décodé dans votre navigateur. Rien n'est envoyé, rien n'est conservé.
Déposez le fichier n'importe où sur cette page PEM, DER, .csr, .cer, .crt, .pem, .req, .txt

Essayez-en un

Tout se passe dans votre navigateur sur cette page. Ouvrez le panneau réseau et observez : aucune requête ne transporte vos données.

Qu'est-ce qu'un CSR ?

Un CSR est un petit fichier signé qui demande un certificat à une autorité de certification. Il contient votre clé publique, les noms que vous voulez voir figurer sur le certificat, et une signature faite avec votre clé privée.

Le format est PKCS#10, défini dans la RFC 2986. La partie qui est signée ne contient que quatre choses : un numéro de version, un nom de sujet, une SubjectPublicKeyInfo qui porte votre clé publique, et un ensemble d'attributs. Le tout est ensuite signé par la clé privée associée à la clé publique qu'il contient, si bien qu'un CSR est auto-signé. Cette signature est la preuve de possession : n'importe qui peut lire votre clé publique, mais seul le détenteur de la clé privée peut signer une demande qui se vérifie face à elle.

Votre clé privée ne se trouve pas dans le fichier, et ne devrait jamais s'y trouver. Un CSR peut être envoyé par e-mail, collé dans le formulaire web d'une AC, et décodé ici sans risque — c'est pourquoi cette page peut faire tout son travail dans votre navigateur sans rien envoyer nulle part.

Une demande, octet par octetRFC 2986 · PKCS#10

Le fichier entier

  • Enveloppe4 octets
  • La partie qui est signée469 octets
  • Quel algorithme de signature15 octets
  • La signature elle-même261 octets

À l'intérieur de la partie qui est signée

  1. Version3 octetsToujours zéro : la seule version que le format définit
  2. Nom du sujet108 octetsLe nom distinctif que vous avez saisi dans le formulaire
  3. Votre clé publique294 octetsAlgorithme, taille et clé — le seul champ qu'une autorité de certification est sûre d'utiliser
  4. Attributs60 octetsLà où voyagent les noms alternatifs que vous avez demandés

Votre clé privéesigne la partie ci-dessusLa preuve que vous détenez la clé privée correspondante · La signature ne couvre que cette partie, pas le fichier entier

La demande d'exemple que propose cette page, 749 octets au total. Quatre éléments entrent dans la partie qui est signée ; la clé privée correspondant à la clé publique qu'elle contient signe exactement cette partie, et ce qui en ressort est le dernier 261 octets.
Résultat du décodeur CSR : un CSR décodé avec son sujet, sa clé, ses noms alternatifs et les constats de règles de l'ACRésultat du décodeur CSR : un CSR décodé avec son sujet, sa clé, ses noms alternatifs et les constats de règles de l'ACCollez ou déposezUn CSR, un certificat ou une clé publique — PEM, base64, dump hexadécimal ou fichier. Plusieurs à la fois, c'est permis.Le verdictCe qu'une AC publique fera de cette demande : l'émettre, la modifier ou la refuser, avec la raison de chaque cas.Les nomsChaque nom que le certificat couvrirait, le nom commun étant vérifié par rapport à eux.La clé et la signatureAlgorithme, taille, courbe et exposant, et si la signature propre de la demande tient.Correspondance de cléAjoutez la clé privée ou le certificat émis pour voir s'il appartient à cette demande. Ni l'un ni l'autre ne quitte votre navigateur.
Un CSR décomposé : le verdict, les noms demandés, la clé qui le soutient et un emplacement pour comparer votre propre clé. Sélectionnez un numéro pour voir ce que montre chaque partie.

Comment vérifier un CSR avant de l'envoyer

Trois choses méritent d'être vérifiées : que les noms sont bien ceux que vous vouliez, que la signature se vérifie, et que rien n'enfreint une règle qu'applique votre AC.

Collez la demande ci-dessus. La page lit le sujet attribut par attribut, liste chaque nom alternatif du sujet, affiche l'algorithme et la taille de la clé, puis vérifie la signature propre de la demande. Une demande dont la signature ne se vérifie pas a été modifiée, tronquée ou corrompue depuis sa création — régénérez-la plutôt que de l'envoyer.

Viennent ensuite les règles. Une autorité de certification applique les Baseline Requirements du CA/Browser Forum, et une demande qui en enfreint une est refusée ou discrètement modifiée. Les constats de cette page sont marqués À corriger lorsque l'AC ne peut pas émettre ce que vous avez demandé, Sera modifié lorsqu'elle l'émettra mais en modifiant ou en supprimant un champ, et À noter lorsque rien n'est faux mais que quelque chose mérite un coup d'œil.

Trois vérifications, dans l'ordre où elles s'exécutentCA/Browser Forum TLS BR 2.3.1
  1. Les nomsChaque nom que le certificat couvrirait, et si le nom commun en fait partie
  2. La signatureVérifiée avec la cryptographie de votre propre navigateur
  3. Les règles de l'autorité de certificationAppliquées une par une, chacune avec le document dont elle provient
  • Envoyez-laRien dans la demande n'enfreint une règle
  • Elle sera refuséeLe fichier est sain ; ce qu'il demande n'est pas autorisé
  • Refaites-laUne signature qui ne se vérifie pas signifie que le fichier a été modifié, tronqué ou mal copié après sa création
Les deux premières vérifications portent sur le fichier lui-même, et la troisième sur ce qu'autorise une autorité de certification. Une demande peut réussir les deux premières et être quand même refusée.

Ce que contient un CSR — et ce que votre AC utilise réellement

De tout ce que contient un CSR, une AC publique n'utilise de façon fiable qu'un seul champ : la clé publique. Elle valide elle-même la plupart du reste, l'écrase, ou n'a pas le droit de le recopier.

DigiCert le dit sans détour dans sa propre documentation : « DigiCert utilise la clé publique intégrée au CSR pour créer votre certificat client. Tous les autres champs du CSR sont ignorés. » Sur un certificat OV ou EV, l'AC doit valider elle-même l'organisation, la localité et le pays avant de les inscrire ; ce que vous avez saisi n'est pas pris pour argent comptant. Les dates de validité ne viennent jamais d'une demande : elles suivent le calendrier des Baseline Requirements.

Deux champs du sujet ne sont pas simplement ignorés mais interdits. organizationalUnitName (OU) ne doit pas apparaître dans un certificat TLS public — selon le vote SC047 du CA/Browser Forum, aucun certificat émis depuis le 1er septembre 2022 ne peut le contenir — et emailAddress n'est absolument pas permis dans un certificat à validation de domaine. Un nom commun est autorisé mais déconseillé, et s'il est présent, il doit reproduire exactement l'un des noms alternatifs du sujet. C'est cette dernière règle qui fait que cette page signale un nom commun absent de la liste SAN.

Ce qu'une autorité de certification fait de chaque champCA/Browser Forum TLS BR 2.3.1
Dans votre demandeCe qu'il devientPourquoi
Clé publiqueSubjectPublicKeyInfoUtilisé tel que vous l'avez envoyéLa seule chose qu'une autorité de certification est sûre de vous prendre
Noms alternatifssubjectAltName2.5.29.17Utilisé tel que vous l'avez envoyéL'AC confirme que vous contrôlez chaque nom avant d'en inscrire un seul
Nom communCN2.5.4.3Validé, puis écrit par l'ACDéconseillé ; s'il est présent, il doit reproduire exactement l'un des noms alternatifs
Organisation, localité, étatO, L, ST2.5.4.10Validé, puis écrit par l'ACSur un certificat à validation d'organisation, ces informations proviennent des registres validés de l'AC elle-même, pas de ce que vous avez saisi
PaysC2.5.4.6Validé, puis écrit par l'ACPeut apparaître, quel que soit le niveau de validation
Unité organisationnelleOU2.5.4.11Pas autorisé du toutInterdite dans un certificat public depuis 1 septembre 2022
Adresse e-mailemailAddress1.2.840.113549.1.9.1Pas autorisé du toutNon autorisée dans un certificat à validation de domaine
Valide à partir de, valide jusqu'ànotBefore, notAfterNe vient jamais de la demandeFixée par le calendrier que suit l'autorité de certification, jamais par votre demande

« DigiCert utilise la clé publique intégrée au CSR pour créer votre certificat client. Tous les autres champs du CSR sont ignorés. »

DigiCert, sa propre documentation
Les champs pour lesquels on s'inquiète, et ce qu'ils valent vraiment. Votre clé et vos noms survivent ; l'unité d'organisation ne peut apparaître en aucun cas, ni une adresse e-mail sur un certificat à validation de domaine, quoi que vous saisissiez ; et les dates n'ont jamais été les vôtres à fixer.

Pourquoi une AC rejette un CSR

Presque chaque rejet se résume à un nom qu'une AC ne peut pas certifier, un wildcard trop large, une adresse IP réservée, une clé trop petite, un algorithme de hachage de signature trop ancien, ou une demande dont la signature ne se vérifie pas.

Une autorité de certification ne peut pas émettre pour un nom interne — un nom qui « ne se termine pas par un domaine de premier niveau enregistré dans la base de données de la zone racine de l'IANA ». Cela inclut server.local, intranet, un nom à une seule étiquette sans aucun point, et tout suffixe inventé. Les étiquettes ne peuvent contenir que des lettres, des chiffres et des traits d'union : un tiret bas dans un nom d'hôte est donc refusé, et un nom ne doit pas s'écrire avec un point final. Un wildcard ne peut remplacer que l'étiquette la plus à gauche en entier, et jamais un suffixe public : *.example.com convient, *.co.uk non. Une adresse IP peut apparaître, mais pas une adresse réservée — ni 10.0.0.0/8, ni 192.168.0.0/16, ni 127.0.0.1, ni fc00::/7.

Pour les clés, les Baseline Requirements sont précises : un module RSA d'au moins 2048 bits, divisible exactement par 8, ou un point sur P-256, P-384 ou P-521, et « aucun autre algorithme ni taille de clé n'est autorisé ». Une AC doit aussi refuser une clé qu'elle peut factoriser, y compris une clé « qui peut être factorisée en 100 itérations avec la méthode de factorisation de Fermat » — cette page applique ce test à la clé de votre demande. Et bien que l'algorithme de hachage de la signature d'un CSR ne soit pas celui du certificat, Let's Encrypt a cessé d'accepter les auto-signatures en SHA-1 en 2022 : un vieil outil qui signe encore en SHA-1 verra donc sa demande repoussée.

Des noms qu'une autorité de certification ne certifiera pasCA/Browser Forum TLS BR 2.3.1
  • server.local
    Un nom interneIl ne se termine pas par un domaine de premier niveau qui existe dans la zone racine publique, personne ne peut donc prouver qu'il est à vous
    Refusé
  • intranet
    Une seule étiquetteUn nom sans aucun point relève de la même définition
    Refusé
  • my_host.example.com
    Un tiret basUne étiquette ne peut contenir que des lettres, des chiffres et des traits d'union, rien d'autre
    Refusé
  • *.co.uk
    Un wildcard sur tout un registreUn wildcard peut remplacer l'étiquette la plus à gauche, jamais un suffixe public
    Refusé
  • 192.168.1.10
    Une adresse réservéeUne adresse publique peut être certifiée ; une adresse d'une plage privée ou à usage spécial jamais
    Refusé
  • example.com.
    Un point finalL'étiquette racine vide ne doit pas être écrite
    Refusé
Six noms, chacun enfreignant une règle différente — et chacun un rejet que vous auriez pu voir avant d'envoyer la demande.

Comment savoir si ma clé privée correspond à mon CSR ?

Un fichier de clé privée contient déjà sa propre clé publique, si bien que la correspondance se résume à comparer deux clés publiques — aucun secret n'est nécessaire, et rien n'a besoin d'être envoyé où que ce soit.

Ouvrez Comparer une clé ou un certificat ci-dessus et ajoutez la clé à côté de la demande. La page ne lit que la moitié publique du fichier — les clés PKCS#8, PKCS#1 et SEC1 sont toutes comprises —, la compare à la clé de la demande, et répond. Rien n'est envoyé, rien n'est conservé, et la clé est effacée dès que vous quittez le champ. La même vérification fonctionne entre une demande et le certificat renvoyé par l'AC, ce qui permet de repérer « le certificat et la clé privée ne correspondent pas » avant qu'un serveur refuse de démarrer.

Si vous préférez ne coller de clé dans aucune page web, la même réponse tient en deux commandes sur votre propre machine. openssl req -in request.csr -pubkey -noout affiche la clé publique de la demande, et openssl pkey -in private.key -pubout l'affiche à partir de la clé : une sortie identique signifie qu'elles correspondent. L'ancienne forme -modulus ne fonctionne que pour les clés RSA ; -pubkey fonctionne pour tous les types de clé.

Deux fichiers, une seule comparaisonRFC 2986 · OpenSSL manual
Votre navigateur
  • Le fichier de clé privéeLe fichier que vous ne devez jamais envoyer nulle partSa moitié publique en est extraite
  • La demandeLe fichier que vous envoyez à l'autorité de certificationElle porte déjà la clé publique

Est-ce la même clé ?

  • Elles correspondentLe certificat qui reviendra s'installera avec cette clé
  • Elles ne correspondent pasC'est la discordance que signale un serveur web quand il refuse de démarrer

Rien ne franchit cette ligne · La comparaison fonctionne même réseau coupéPartout ailleurs

Ou faites-le sur votre propre machineopenssl req -in request.csr -pubkey -nooutopenssl pkey -in private.key -puboutUne sortie identique signifie qu'elles correspondent
Un fichier de clé privée porte déjà sa propre clé publique, la question se règle donc en comparant deux clés publiques. Aucun secret n'a besoin de se déplacer pour cela, et aucun ne le fait.

CSR, certificat, clé privée : quelle est la différence ?

La clé privée est le secret. Le CSR est une demande qui prouve que vous la détenez. Le certificat est la réponse signée de l'AC, et c'est le seul des trois qui soit public par nature.

Les trois fichiers se trouvent souvent dans le même dossier, avec des noms qui prêtent à confusion. Une clé privée commence par -----BEGIN PRIVATE KEY----- ou -----BEGIN RSA PRIVATE KEY----- et ne doit jamais être envoyée à qui que ce soit, pas même à une autorité de certification. Un CSR commence par -----BEGIN CERTIFICATE REQUEST-----, est signé par cette clé, et peut être envoyé sans risque. Un certificat commence par -----BEGIN CERTIFICATE-----, est signé par l'AC, et est de toute façon envoyé à chaque visiteur de votre site.

Une fois le certificat émis, la demande ne sert plus à rien : elle n'est nécessaire ni pour installer, ni pour renouveler, ni pour révoquer quoi que ce soit. C'est la clé qu'il faut garder, et garder en sécurité. Collez l'un des trois ci-dessus et cette page vous dira lequel c'est.

Trois fichiers, un dossier, des noms qui prêtent à confusionRFC 7468

  • La clé privéeSecret

    Sa première ligne-----BEGIN PRIVATE KEY-----Également très répandues-----BEGIN RSA PRIVATE KEY-----

    Signé par
    Rien — c'est elle qui signe
    Qui peut le voir
    Vous, et personne d'autre
    À quoi il sert
    Prouve que ce serveur est bien celui auquel le certificat a été délivré

  • Le CSRPublic

    Sa première ligne-----BEGIN CERTIFICATE REQUEST-----Également très répandues-----BEGIN NEW CERTIFICATE REQUEST-----

    Signé par
    Lui-même, avec la clé privée
    Qui peut le voir
    Vous et l'autorité de certification
    À quoi il sert
    Demande un certificat, et prouve que vous détenez la clé à laquelle il correspond

  • Le certificatPublic

    Sa première ligne-----BEGIN CERTIFICATE-----

    Signé par
    L'autorité de certification
    Qui peut le voir
    Chaque visiteur de votre site
    À quoi il sert
    Dit à un navigateur que cette clé appartient à ces noms

.csr.pem.req.txtAucune norme n'attribue d'extension de fichier à une demande ; toutes celles-ci sont en usage, et cette page lit le contenu plutôt que le nom

Seul le premier des trois est un secret. Le dernier est de toute façon remis à chaque visiteur, et celui du milieu ne sert plus à rien dès que le certificat arrive.

Est-il sûr de décoder un CSR en ligne ?

Un CSR ne contient aucun secret, donc le décoder n'importe où est sans danger. Une clé privée, c'est différent, et c'est le fichier avec lequel on le confond.

Tout, sur cette page, s'exécute dans votre navigateur. La demande est analysée par du code téléchargé avec la page, la signature est vérifiée avec le Web Crypto de votre propre navigateur, et aucune requête n'est envoyée à un serveur avec vos données dedans — vous pouvez observer le panneau réseau pendant que vous l'utilisez. C'est une propriété de la façon dont la page est construite, pas une promesse qu'on vous demande de croire sur parole.

Ce qui compte vraiment, c'est l'autre fichier, celui qui accompagne le CSR. La définition du CA/Browser Forum lui-même est sans appel : « Une clé privée est considérée comme compromise si sa valeur a été divulguée à une personne non autorisée, ou si une personne non autorisée y a eu accès. » Aucun mésusage n'est nécessaire — il suffit qu'elle atteigne le serveur de quelqu'un d'autre. En 2020, DigiCert a trouvé 337 clés privées que des clients avaient collées à côté de leur CSR, et a révoqué tous les certificats concernés, écrivant qu'« en envoyant la clé privée à DigiCert avec le CSR, le client a compromis la clé privée ». Si cette page lit un jour une clé privée que vous collez, elle vous le dit, refuse de la décoder, et n'en garde rien.

Où va réellement le fichierCA/Browser Forum TLS BR 2.3.1

Cette page

Votre navigateur
  1. Le fichier est lu
  2. Il est décomposé par du code arrivé avec la page
  3. La signature est vérifiée par le navigateur lui-même
  4. Le résultat est affiché

Aucune requête ne part avec vos données dedansOuvrez le panneau réseau et observez pendant que vous l'utilisez

Une page qui l'envoie

Votre navigateur

Le fichier est envoyé… avec tout ce qui a été collé à côté

Le serveur de quelqu'un d'autre

Une clé privée qui arrive là est compromise par ce seul fait

« Une clé privée est considérée comme compromise si sa valeur a été divulguée à une personne non autorisée, ou si une personne non autorisée y a eu accès. »

la définition que les autorités de certification ont écrite pour elles-mêmes

C'est déjà arrivéEn 2020, une autorité de certification a trouvé 337 clés privées collées à côté d'une demandeTous les certificats concernés ont été révoqués

Rien dans une demande n'est secret, la décoder n'importe où est donc sans danger. Le fichier avec lequel on la confond, c'est une autre affaire, et le dommage ne nécessite aucun mésusage — être vu suffit.

RSA ou ECDSA : quelle clé un CSR doit-il demander ?

Une clé ECDSA P-256 est aussi solide qu'une clé RSA de 3072 bits, et bien plus petite : c'est donc le meilleur choix par défaut. RSA 2048 reste accepté partout.

Le NIST place P-256 et RSA-3072 à la même force de sécurité de 128 bits, et son tableau n'a aucune ligne pour RSA-4096 : la ligne suivante est RSA-7680, à 192 bits, le niveau qu'atteint P-384. Une clé RSA de 4096 bits impose donc à chaque visiteur un travail de négociation supplémentaire, sans gain documenté par rapport à 3072. Les Baseline Requirements autorisent aussi P-521, mais Let's Encrypt la refuse : une demande en P-521 peut donc être parfaitement légale et échouer quand même chez l'AC que vous comptiez utiliser.

Ed25519 n'est pas une option pour un certificat TLS public aujourd'hui, aussi bon que soit l'algorithme : les Baseline Requirements listent RSA et les trois courbes du NIST, et ajoutent qu'« aucun autre algorithme ni taille de clé n'est autorisé ». Une clé post-quantique non plus : le vote qui aurait permis ML-DSA en TLS public a été clos sans être adopté en octobre 2026. Ed25519 et ML-DSA restent utiles pour SSH, pour la signature, et pour une AC privée, et cette page lit les demandes qui les utilisent.

La même force, pour deux tailles très différentesNIST SP 800-57 Part 1 Rev 5, Table 2
ForceClé RSACourbe
112 bits de sécurité2 048 bitsToute AC publiqueAucune courbe autorisée par une autorité de certification publique ne se situe à cette force
128 bits de sécurité3 072 bitsToute AC publiqueP-256Toute AC publique
4 096 bitsToute AC publique4 096 bits ne figure pas du tout dans le tableau
192 bits de sécurité7 680 bitsToute AC publiqueP-384Toute AC publique
256 bits de sécurité15 360 bitsToute AC publiqueP-521Toute AC publique
  • Clé RSA
  • Courbe
  • Les paliers passent directement d'une taille à l'autre et sautent celle qui est populaire entre les deux, si bien que le travail de négociation supplémentaire qu'elle impose à chaque visiteur n'achète aucun gain que quiconque ait documenté
  • Acceptée parLet's Encrypt

Une courbe porte la même force en une fraction des octets

La comparaison publiée, avec les deux éléments qui décident si vous pouvez réellement utiliser une clé : ce que permettent les règles, et ce que permet l'autorité de certification que vous comptiez utiliser.

Comment générer un CSR sur n'importe quelle plateforme

Une seule commande OpenSSL couvre Linux, macOS et Windows avec OpenSSL installé. IIS a certreq, macOS a Trousseaux d'accès, et ce site a un générateur qui n'envoie jamais votre clé nulle part.

Avec OpenSSL, openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com" crée la clé et la demande en une seule étape. (-nodes laisse la clé non chiffrée. OpenSSL 3 l'écrit aussi -noenc, mais le LibreSSL intégré à macOS ne connaît que -nodes.) Puis openssl req -in example.com.csr -text -verify -noout l'affiche et la vérifie. Sous Windows, certreq -new request.inf request.req lit un fichier .inf dont les noms alternatifs vont sous l'OID 2.5.29.17 avec des lignes _continue_ — il n'existe pas de clé SAN=. La page de référence de Microsoft elle-même avertit que son exemple utilise SHA-1, qu'une AC refuse désormais : définissez donc vous-même le hachage.

Sur un Mac, Trousseaux d'accès > Assistant de certification > Demander un certificat à une autorité de certificat en écrit un, la taille de la clé se cachant derrière la case « Me laisser indiquer les informations sur la bi-clé ». Ou utilisez notre générateur de CSR, qui crée la clé avec le Web Crypto de votre navigateur et vous remet les deux fichiers sans qu'ils touchent un serveur. Aucune norme n'impose d'extension de fichier à un CSR : .csr, .pem, .req et .txt sont tous en usage, et cette page lit le contenu plutôt que de se fier au nom.

Quatre façons d'en créer unOpenSSL · Microsoft Learn · Apple Support

  1. OpenSSLLinux, macOS, Windows

    Génère la clé et la demande en une seule commandeopenssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com"Puis relisez-la et vérifiez sa propre signatureopenssl req -in example.com.csr -text -verify -noout

  2. certreqWindows Server et IIS

    Lit un fichier texte brut ; les noms alternatifs vont dans une section d'extensions, une ligne chacuncertreq -new request.inf request.req[Extensions] 2.5.29.17 = "{text}" _continue_ = "DNS=example.com&" _continue_ = "DNS=www.example.com"La page d'exemple de Microsoft elle-même est encore écrite autour d'un algorithme de hachage qu'une autorité de certification refuse désormais : définissez vous-même le hachage

  3. Keychain AccessmacOS

    Keychain Access › Certificate Assistant › Request a Certificate From a Certificate AuthorityVotre Mac nomme ces menus dans sa propre langueLe type et la taille de la clé se cachent derrière la case qui permet de préciser la bi-cléClés RSA de 2048 à 4096 bits ; les plus petites ne sont plus proposées

  4. DNS RobotN'importe quel navigateur

    Crée la clé avec la cryptographie de votre propre navigateur et vous remet les deux fichiers sans qu'aucun ne touche un serveurOuvrir le générateur
Une même commande OpenSSL fonctionne sous Linux, macOS et Windows. Les trois autres voies sont pour les machines où elle n'est pas à portée de main.

Combien de temps le certificat durera-t-il ?

Un certificat TLS public émis aujourd'hui ne peut pas dépasser 200 jours. Cela tombe à 100 jours en mars 2027 et à 47 jours en mars 2029.

Ce calendrier provient du vote SC-081v3 du CA/Browser Forum, adopté en avril 2025, et un CSR n'y change rien : la validité ne vient jamais de la demande. Chaque palier comporte deux nombres, un SHOULD NOT un jour sous le MUST NOT — 199 et 200 aujourd'hui, 99 et 100 à partir du 15 mars 2027, 46 et 47 à partir du 15 mars 2029. Pour ce calcul, « un jour se mesure comme 86 400 secondes exactement », et toute fraction de jour supplémentaire compte pour un jour entier.

La conséquence pratique, c'est que le renouvellement doit être automatique. Si vous générez encore un CSR à la main chaque année, c'est le moment de passer à ACME, où le client génère la demande à votre place — et où, au passage, PKCS#10 est réellement exigé, même si les Baseline Requirements elles-mêmes ne demandent qu'« une demande de certificat dans une forme prescrite par l'AC ».

Combien de temps un certificat peut durerCA/Browser Forum TLS BR 2.3.1 §6.3.2
  1. avant 15 mars 2026Où se situe aujourd'hui397 jours398 jours
  2. à partir de 15 mars 2026199 jours200 jours
  3. à partir de 15 mars 202799 jours100 jours
  4. à partir de 15 mars 202946 jours47 jours
  • Tout ce calendrier vient d'un seul vote, SC-081v3, adopté 11 avril 2025
  • Un jour compte pour exactement 86 400 secondes et toute fraction de jour supplémentaire compte pour un jour entier
  • Rien dans une demande ne change quoi que ce soit à tout cela
Quatre paliers, chacun avec deux nombres : celui que les règles découragent, et celui qu'elles interdisent. Les dates sont déjà fixées, ce qui fait du renouvellement automatique la seule réponse viable.

Ce que montre l'ASN.1 brut

Sous le base64, un CSR est un arbre encodé en DER. Le décodeur le dessine avec les décalages en octets et nomme chaque identifiant d'objet qu'il connaît, ce qu'affiche openssl asn1parse.

C'est la façon honnête de montrer un champ auquel personne n'a donné de nom convivial. Ouvrez Structure brute sur n'importe quel élément décodé et vous verrez le CertificationRequestInfo, les noms distinctifs relatifs du sujet un par un, le SubjectPublicKeyInfo, l'ensemble attributes [0] et, à l'intérieur, l'attribut extensionRequest — identifiant d'objet 1.2.840.113549.1.9.14, défini non pas dans la RFC 2986 mais dans la RFC 2985 §5.4.2 — qui porte les extensions X.509 de la RFC 5280 elles-mêmes.

L'autre attribut que vous pouvez y rencontrer est challengePassword (1.2.840.113549.1.9.7). Il devait servir de secret partagé pour faire révoquer un certificat plus tard, il est encore utilisé par l'inscription SCEP, et ne joue aucun rôle dans une commande de certificat web normale. Cette page l'affiche quand il est présent, car un champ qu'on ne voit pas est un champ qu'on ne peut pas vérifier.

La même demande, en octetsRFC 2986 · RFC 2985 · RFC 5280
À l'octetStructureTaille
0SEQUENCE749 octets
4SEQUENCE469 octets
8INTEGER03 octets
11SEQUENCE108 octets
13SET13 octets
15SEQUENCE11 octets
17OBJECT IDENTIFIERC2.5.4.65 octets
22PrintableStringUS4 octets
26SET21 octets
28SEQUENCE19 octets
30OBJECT IDENTIFIERST2.5.4.85 octets
35UTF8StringCalifornia12 octets
47SET24 octets
49SEQUENCE22 octets
51OBJECT IDENTIFIERL2.5.4.75 octets
56UTF8StringSan Francisco15 octets
71SET22 octets
73SEQUENCE20 octets
75OBJECT IDENTIFIERO2.5.4.105 octets
80UTF8StringExample Inc13 octets
93SET26 octets
95SEQUENCE24 octets
97OBJECT IDENTIFIERCN2.5.4.35 octets
102UTF8Stringwww.example.com17 octets
119SEQUENCE294 octets
123SEQUENCE15 octets
125OBJECT IDENTIFIERrsaEncryption1.2.840.113549.1.1.111 octets
136NULL2 octets
138BIT STRING2 160 bits30 82 01 0a 02 82 01 01 00 c5 47 47 1d 26 1c bf275 octets
413[0]60 octets
415SEQUENCE58 octets
417OBJECT IDENTIFIERextensionRequest1.2.840.113549.1.9.1411 octets
428SET45 octets
430SEQUENCE43 octets
432SEQUENCE41 octets
434OBJECT IDENTIFIERSubject Alternative Name2.5.29.175 octets
439OCTET STRING32 octets30 1e 82 0f 77 77 77 2e 65 78 61 6d 70 6c 65 2e34 octets
473SEQUENCE15 octets
475OBJECT IDENTIFIERsha256WithRSAEncryption1.2.840.113549.1.1.1111 octets
486NULL2 octets
488BIT STRING2 048 bits00 57 41 c5 09 98 14 78 8c ee c3 61 d4 c0 e0 2d261 octets
  • Contient d'autres éléments
  • Contient une valeur
  • Nommé par sa position

  • L'attribut qui porte les extensions

    1.2.840.113549.1.9.14Il est défini dans un document différent de celui qui définit la demande elle-même, c'est pourquoi les noms alternatifs voyagent à l'intérieur d'un attribut plutôt qu'à côté du sujet

  • L'autre attribut que vous pouvez rencontrerAbsent de cette demande

    1.2.840.113549.1.9.7Un secret partagé, destiné à demander plus tard la révocation du certificat, et encore utilisé quand un appareil s'inscrit lui-même sur un réseau
Chaque octet de la demande d'exemple, avec chaque identifiant d'objet nommé. C'est ce qu'affiche un décodeur en ligne de commande, dessiné plutôt qu'imprimé, pour que vous voyiez où un champ se termine et où le suivant commence.

Décodeur CSR : questions et réponses

Comment décoder un CSR ?

Collez toute la demande dans le champ ci-dessus, y compris les lignes -----BEGIN CERTIFICATE REQUEST----- et -----END CERTIFICATE REQUEST-----, ou déposez le fichier sur la page. Elle se décode au fur et à mesure que vous collez : le sujet, la clé publique, chaque nom alternatif du sujet, chaque extension demandée et les empreintes. Vous pouvez aussi coller uniquement le corps base64, un dump hexadécimal, ou importer un fichier DER binaire.

Ce décodeur CSR est-il sûr à utiliser ?

Oui, pour deux raisons. Un CSR ne contient aucun secret — il est destiné à être envoyé à une autorité de certification — donc le décoder n'importe où est sans danger. Et cette page fait le travail dans votre navigateur : la demande est analysée par du code téléchargé avec la page, et rien n'est envoyé à aucun serveur. Si vous collez une clé privée par erreur, la page vous le signale, refuse de la décoder et n'en garde rien.

Comment vérifier si mon CSR est valide ?

Décodez-le ici et lisez le verdict. La page vérifie la signature propre de la demande, qui prouve que l'expéditeur détient la clé privée correspondante, puis applique les règles qu'applique une autorité de certification publique : des noms qu'elle ne peut pas certifier, des wildcards trop larges, des adresses IP réservées, des clés trop petites ou factorisables, des champs du sujet obsolètes et des algorithmes de hachage de signature dépassés. Chaque constat indique si l'AC la refusera, la modifiera, ou n'y prêtera simplement aucune attention.

Pourquoi mon autorité de certification rejette-t-elle mon CSR ?

Les causes les plus courantes sont un nom interne comme server.local ou un nom d'hôte à une seule étiquette, un tiret bas dans un nom d'hôte, un wildcard sur un suffixe public comme *.co.uk, une adresse IP privée parmi les noms alternatifs, une clé RSA de moins de 2048 bits, ou une demande encore signée avec SHA-1. Décodez la demande ci-dessus et chacun de ces cas est nommé explicitement, avec la règle qu'il enfreint.

Comment savoir si ma clé privée correspond à mon CSR ?

Utilisez Comparer une clé ou un certificat ci-dessus : ajoutez la clé à côté de la demande, et la page compare la clé publique du fichier de clé à celle de la demande, dans votre navigateur. Ou faites-le vous-même — openssl req -in request.csr -pubkey -noout et openssl pkey -in private.key -pubout affichent la même clé publique quand elles correspondent. La même comparaison fonctionne entre une clé et un certificat émis.

Ce décodeur peut-il aussi décoder un certificat SSL ?

Oui. Collez un certificat et il se décode comme un certificat : émetteur et sujet, numéro de série, dates de validité, chaque nom alternatif, usage de la clé et usage étendu de la clé, les identifiants de clé de l'autorité et du sujet, les URL OCSP et de l'émetteur (AIA), les politiques de certification et les éventuels horodatages Certificate Transparency intégrés. Collez un certificat et sa demande ensemble, et la page vous dit aussi s'ils partagent une clé.

Quels champs une autorité de certification utilise-t-elle réellement depuis mon CSR ?

De façon fiable, un seul : la clé publique. La documentation de DigiCert dit elle-même que le reste est ignoré. Sur un certificat OV ou EV, l'AC doit valider elle-même l'organisation et le pays avant de les inscrire ; les dates de validité viennent toujours du calendrier des Baseline Requirements, jamais de la demande. Deux champs ne sont pas simplement ignorés mais interdits dans un certificat TLS public : OU et, sur les certificats à validation de domaine, emailAddress.

Le nom commun compte-t-il encore ?

Seulement comme copie d'autre chose. Les navigateurs ignorent le nom commun pour la correspondance de nom d'hôte depuis 2017 et n'utilisent que les noms alternatifs du sujet. Les Baseline Requirements marquent le nom commun NOT RECOMMENDED et exigent, s'il est présent, qu'il « DOIT contenir exactement une entrée qui soit l'une des valeurs contenues dans l'extension subjectAltName du certificat ». Un nom commun absent de vos noms alternatifs est un motif de rejet, et cette page le signale.

Puis-je décoder plusieurs fichiers à la fois ?

Oui. Collez ensemble une demande, son certificat et les intermédiaires, et chaque bloc se décode sur sa propre carte, dans l'ordre où vous les avez collés. Un bloc corrompu n'arrête pas les autres. Si une clé privée se trouve quelque part dans le collage, elle est nommée et ignorée, jamais décodée. Jusqu'à quarante blocs sont décodés, et tout ce qui dépasse est compté et signalé plutôt que silencieusement abandonné.

Qu'est-ce qu'un « challenge password » dans un CSR ?

Un attribut facultatif de la RFC 2985, à l'origine un secret partagé que l'on citait pour demander la révocation du certificat. Il garde un rôle dans l'inscription SCEP, où un appareil prouve qu'il est autorisé à faire la demande. Il ne joue aucun rôle dans une commande de certificat web ordinaire, et comme c'est un champ que peu d'outils affichent, cette page le montre dès qu'une demande en porte un.

Puis-je utiliser une clé Ed25519 pour un certificat public ?

Pas aujourd'hui. Les Baseline Requirements autorisent RSA et les courbes P-256, P-384 et P-521, puis précisent qu'« aucun autre algorithme ni taille de clé n'est autorisé » : aucune autorité de certification publique n'émettra donc pour une demande en Ed25519. C'est une bonne clé pour SSH, pour la signature et pour une AC privée, et ce décodeur lit sans problème les demandes en Ed25519 et Ed448, ainsi que les clés post-quantiques ML-DSA.

Combien de temps un certificat est-il valide aujourd'hui ?

Un certificat TLS public émis aujourd'hui ne peut pas dépasser 200 jours, contre 398 avant le 15 mars 2026. Il passe à 100 jours le 15 mars 2027, puis à 47 jours le 15 mars 2029, en vertu du vote SC-081v3 du CA/Browser Forum. Rien dans un CSR n'influence cela ; la validité est fixée par l'AC. À ces durées, le renouvellement doit être automatisé, ce qui, en pratique, signifie ACME.

Il vous manque quelque chose ?Suggérez une fonction ou un nouvel outil

Outils associés