Aller au contenu
DomainVigil
S'inscrire

Outil gratuit

Que contient ma demande de certificat ?

Une demande de signature est un bloc de vingt lignes de base64, et on la remplit une fois par an sans jamais la relire. Collez-la ici : vous verrez le nom qu'elle porte, la taille de la clé, les noms qu'elle demande à couvrir, et les défauts de forme qui font qu'une autorité la refuse.

Le texte que vous collez est décodé par votre navigateur. Il ne part sur aucun serveur, pas même le nôtre : ni le certificat, ni la demande, ni le nom de domaine.

Ce que cet outil lit, et ce qu'il ne lit pas

Il lit la structure : le sujet, la clé publique, les extensions demandées, et il applique les contrôles de forme que les autorités appliquent aussi. Il ne vérifie pas la signature de la demande, et il ne sait pas si la clé privée correspondante est toujours sur votre serveur. Ces deux vérifications se font en une ligne de commande, et la table des commandes plus bas les donne.

Une demande se fait une fois, une date d'expiration revient tous les ans

Le certificat que vous allez recevoir porte une date de fin. C'est la panne la plus prévisible du métier et pourtant l'une des plus fréquentes, parce que personne ne relit la date d'un certificat installé onze mois plus tôt. DomainVigil relit la vôtre chaque jour et écrit avant l'échéance, pas après. Ce décodeur sert le jour de la demande ; la date, elle, reviendra.

Le mécanisme

Le guichet : ce qui fait refuser une demande

Une demande de signature part chez l'autorité, et la réponse arrive une heure plus tard : refusée, sans plus d'explication. Voici les quatre champs qui expliquent presque tous les refus. Mettez-en un de travers, et regardez le tampon.

Demande de signature — example.com

Clé
Nom commun
Noms couverts
Pays
Acceptée

Rien à signaler : cette demande passe le guichet. Cassez un champ pour voir ce que l'autorité aurait répondu.

Rien n'est envoyé nulle part : ce guichet est un dessin. Pour examiner votre vraie demande, collez-la dans le champ en haut de page.

Ce qu'une demande contient

La clé privée n'y est pas.

Une demande porte la clé publique et une signature. C'est la signature qui prouve que vous détenez la clé privée, sans jamais la révéler.

  • 1clé, et elle est publique
  • 0date : une demande ne périme pas
  • 9champs qu'elle peut porter

Lire le résultat

Le bandeau donne le nom principal et le verdict d'ensemble ; en dessous, chaque volet est un morceau de la demande, dans l'ordre où il est encodé.

Conforme
La demande passe les contrôles de forme : un nom commun présent et repris dans la liste des noms, une clé d'au moins 2048 bits, une signature en SHA-256. Votre autorité peut ajouter ses propres règles, mais rien ici ne la fera refuser la demande à la lecture.
Problème
Un défaut qui provoque un refus : une clé trop courte, une empreinte obsolète, un nom commun absent de la liste des noms, un nom mal formé. Il faut refaire la demande, et parfois la clé avec — une clé trop courte ne se rallonge pas.
À vérifier
Une demande qui sera signée, mais qui ne couvrira peut-être pas ce que vous croyez : un joker sans le domaine nu, une adresse électronique dans le sujet, un doublon. Rien ne bloque, tout se corrige en refaisant la demande depuis la même clé.
À savoir
Une particularité qui ne juge rien : un mot de passe de défi, un attribut inhabituel. Elle est signalée parce qu'elle explique souvent pourquoi deux demandes qui semblent identiques ne donnent pas le même certificat.
Les noms couverts
Chaque pastille est une entrée de la liste des noms alternatifs, avec son type. Ce sont ces noms, et eux seuls, que le certificat signé authentifiera. Le nom commun n'en fait pas partie s'il n'y est pas répété.
Les extensions demandées
Une demande ne contient pas d'extensions : elle en contient la demande, transportée par l'attribut extensionRequest. L'autorité les reprend, les complète ou les ignore selon sa politique. La liste s'affiche avec son identifiant, pour que vous puissiez comparer avec ce qui ressortira dans le certificat.

Les cinq refus les plus fréquents

Ce sont ceux qui reviennent quand on commande un certificat pour un client, avec la cause et le geste qui corrige.

  1. L'autorité répond « le nom commun n'est pas dans le SAN »

    Ce qui la provoque : La demande a été générée avec un seul champ CN, sans liste de noms alternatifs. Un certificat qui ne porte que le CN n'identifie plus rien pour un navigateur, et les autorités refusent de le signer.

    Le geste qui corrige : Régénérez la demande depuis la même clé en ajoutant l'extension : openssl req -new -key cle.key -out demande.csr -addext "subjectAltName=DNS:example.com, DNS:www.example.com". Répétez le nom commun dans la liste.

  2. Le certificat livré refuse de s'installer

    Ce qui la provoque : La demande a été générée sur un serveur et le certificat installé sur un autre, ou la clé a été régénérée entre-temps. Le certificat scelle la clé publique de la demande : il ne fonctionne qu'avec la clé privée qui lui correspond.

    Le geste qui corrige : Comparez les trois empreintes de module avec les commandes de la table ci-dessous. Si celle du certificat diffère de celle de la clé, la clé de la demande n'est plus celle du serveur : il faut refaire une demande et demander une réémission.

  3. Le certificat est bon mais le site nu affiche une erreur de nom

    Ce qui la provoque : La demande portait *.example.com et rien d'autre. Un joker couvre les noms d'un niveau en dessous, jamais le nom sur lequel il porte.

    Le geste qui corrige : Demandez les deux : *.example.com et example.com. C'est la seule façon de couvrir à la fois les sous-domaines et le domaine nu.

  4. La demande est refusée pour un nom accentué

    Ce qui la provoque : Le champ dNSName d'un certificat ne transporte que de l'ASCII : un nom accentué doit y figurer sous sa forme encodée, celle qui commence par xn--.

    Le geste qui corrige : Convertissez le nom, puis mettez la forme ASCII dans la demande. Le convertisseur Punycode de cette famille d'outils fait la conversion dans les deux sens.

  5. La clé privée a disparu entre la demande et la livraison

    Ce qui la provoque : La demande a été générée dans un panneau d'hébergeur, dans un conteneur recréé depuis, ou dans un dossier temporaire. Sans la clé privée, le certificat signé ne vaut rien.

    Le geste qui corrige : Refaites une clé et une demande, puis demandez une réémission à l'autorité — c'est en général gratuit et sans nouvelle validation. Et rangez la clé au même endroit que le certificat, dès le premier jour.

Les champs d'une demande, et ce que chacun engage

Une demande porte plus de champs qu'il n'en reste dans le certificat. Voici ce que chacun devient, et l'identifiant sous lequel il est encodé.

ChampCe qu'il contientCe qu'il engage
CN — 2.5.4.3Un seul nom, 64 caractères au plus (RFC 5280, annexe A).Il n'identifie plus le site : la RFC 2818 § 3.1 impose d'utiliser les noms alternatifs quand ils existent. Répétez-y le nom principal, sinon il ne sera pas couvert.
subjectAltName — 2.5.29.17La liste des noms, transportée par l'attribut extensionRequest.C'est cette liste qui compte. Un nom absent d'ici n'est pas couvert, même s'il figure dans le nom commun.
O — 2.5.4.10La raison sociale de l'organisation.Vérifiée pour un certificat à validation d'organisation, effacée pour un certificat validé sur le seul domaine.
OU — 2.5.4.11Un service, une équipe, un site.Sans effet. Les autorités publiques ne reprennent plus ce champ.
C, ST, L — 2.5.4.6, .8, .7Le pays, la région, la ville.Le pays attend un code à deux lettres. Un nom de pays en entier fait rejeter la demande à la lecture.
emailAddress — 1.2.840.113549.1.9.1Une adresse électronique dans le sujet.Vient de PKCS#9 et n'a rien à faire dans un certificat de site web. À laisser vide.
subjectPublicKeyInfoL'algorithme et la clé publique.RSA à 2048 bits au moins, ou une courbe P-256. C'est cette clé que le certificat scellera, et elle ne se change plus après.
challengePassword — 1.2.840.113549.1.9.7Un mot de passe défini par PKCS#9 § 5.4.1.Ignoré par les autorités publiques. À laisser vide.
signatureAlgorithmL'algorithme qui signe la demande elle-même.SHA-256 au minimum. Cette signature prouve que celui qui demande le certificat détient la clé privée.

Les identifiants sont les OID de chaque champ. C'est sous cette forme que l'outil affiche un champ qu'il ne connaît pas, plutôt que de lui inventer un nom.

Les commandes qui vont avec

Toutes ont été exécutées pour écrire cette page, avec OpenSSL 3.6. Elles marchent aussi avec le LibreSSL installé par défaut sur macOS.

CommandeCe qu'elle fait
openssl req -new -newkey rsa:2048 -nodes -keyout cle.key -out demande.csrCrée une clé privée de 2048 bits et la demande qui va avec, sans mot de passe sur la clé.
openssl req -in demande.csr -noout -textAffiche le contenu de la demande dans le terminal, champ par champ.
openssl req -in demande.csr -noout -verifyVérifie la signature de la demande. Répond « self-signature verify OK » quand la demande et sa clé vont ensemble.
openssl req -in demande.csr -noout -modulus | openssl sha256L'empreinte du module de la clé publique, côté demande.
openssl rsa -in cle.key -noout -modulus | openssl sha256La même empreinte, côté clé privée.
openssl x509 -in certificat.crt -noout -modulus | openssl sha256La même, côté certificat reçu. Les trois doivent être identiques, sinon le certificat ne s'installera pas.
openssl req -new -key cle.key -out demande.csr -addext "subjectAltName=DNS:example.com, DNS:www.example.com"Refait une demande depuis une clé existante, avec la liste des noms alternatifs.

Questions fréquentes

À quoi sert un CSR exactement ?

À dire à une autorité de certification quel nom vous voulez faire certifier et avec quelle clé publique. La demande contient la clé publique, jamais la clé privée ; elle est signée avec la clé privée, ce qui prouve que vous la détenez sans la révéler. L'autorité vérifie que le domaine est bien à vous, puis renvoie un certificat qui scelle cette clé publique et ces noms.

Peut-on décoder un CSR sans l'envoyer sur un site web ?

Oui, de deux façons. En ligne de commande : openssl req -in demande.csr -noout -text. Et sur cette page : le décodage est écrit en JavaScript et s'exécute dans votre navigateur, donc le contenu du champ ne part sur aucun serveur. Une demande de certificat n'est pas un secret, mais on colle parfois un fichier de trop.

Pourquoi faut-il répéter le nom dans le SAN alors qu'il est déjà dans le CN ?

Parce que le nom commun n'identifie plus le site. La RFC 2818 § 3.1 dit que si l'extension subjectAltName de type dNSName est présente, c'est elle qui fait l'identité, et le nom commun n'est lu que si elle est absente. Les autorités ont cessé d'émettre des certificats sans cette extension : un nom qui n'y figure pas n'est couvert par rien.

Faut-il régénérer la clé privée à chaque renouvellement ?

Rien ne l'impose : une nouvelle demande peut se faire depuis la clé existante, avec openssl req -new -key cle.key. Changer de clé limite la durée pendant laquelle une clé compromise reste utile, au prix d'un déploiement un peu plus lourd. Les deux pratiques existent ; ce qui compte est de savoir où la clé est rangée.

Une demande peut-elle couvrir plusieurs noms ?

Oui, par l'extension subjectAltName, et c'est la façon normale de faire : un certificat couvre couramment le domaine nu, le sous-domaine www et quelques autres. Le champ du nom commun, lui, n'en accepte qu'un. Un joker *.example.com compte pour un nom et couvre un seul niveau de sous-domaines.

Un CSR a-t-il une date d'expiration ?

Non, une demande ne porte aucune date : elle ne périme pas. C'est le certificat qui en porte deux, un début et une fin, et cet outil les affiche en jours pour un certificat déjà émis. Une demande conservée six mois reste techniquement valable, mais rien n'oblige une autorité à accepter de la signer.

De la demande au certificat

Quatre étapes, et une seule clé du début à la fin

Une demande se remplit une fois par an et ne se relit jamais. Voici ce qu'il advient de chacun de ses morceaux — c'est ce qui explique la moitié des refus.

  1. Vous générez une clé, puis la demande

    La clé privée reste chez vous. La demande emporte la clé publique, le nom commun et la liste des noms à couvrir, et se signe avec la clé privée.

  2. L'autorité lit la forme avant de vérifier le domaine

    Un nom commun de 64 caractères au plus, repris dans la liste des noms, une clé d'au moins 2048 bits, une signature en SHA-256. Un défaut ici, et la demande revient sans que le domaine ait été regardé.

  3. Elle renvoie un certificat qui scelle cette clé et ces noms

    Le certificat ne vaut que pour la clé publique de la demande. Les champs O, OU, C, ST et L sont repris, complétés ou effacés selon sa politique ; la liste des noms, elle, fait foi.

  4. Vous l'installez avec la clé privée d'origine

    S'il manque la clé, ou si elle a été régénérée entre-temps, le certificat ne s'installe pas. Il faut alors refaire une demande et obtenir une réémission.

Les bornes

Trois valeurs qu'une autorité ne négocie pas

Elles se lisent dans la demande elle-même, avant toute vérification de domaine. C'est là que se jouent les refus les plus bêtes.

2048bits

La taille minimale d'une clé RSA

En dessous, la demande est refusée. Une clé trop courte ne se rallonge pas : il faut la régénérer, puis refaire la demande depuis la nouvelle clé.

64

Les caractères admis dans le nom commun

La limite du champ, fixée en annexe A de la RFC 5280. Au-delà, la demande est rejetée à la lecture, avant même qu'on regarde le domaine.

3

Les empreintes de module qui doivent coïncider

Celle de la demande, celle de la clé privée, celle du certificat reçu. Si l'une diffère, le certificat ne s'installera pas — et la table des commandes donne les trois lignes qui les calculent.

Le minimum de 2048 bits est celui que cette lecture applique et que les autorités publiques imposent ; la limite de 64 caractères pour le nom commun vient de l'annexe A de la RFC 5280 ; les trois empreintes sont celles de la table des commandes plus haut.

Vingt contrôles, sans inscription