Analyseur de CSR

Pourquoi analyser un CSR avant de le soumettre ?

Un décodeur de CSR affiche des champs. Il répond à « qu'y a-t-il dans ce fichier », jamais à la question qui se pose avant de payer un certificat : mon autorité de certification va-t-elle l'accepter, et sinon, pourquoi.

L'écart est mesurable. Un Common Name absent des SAN, un wildcard posé sur *.co.uk, un underscore dans un nom DNS, un nom en .local, une adresse IP privée en SAN, ou aucun SAN du tout : autant de demandes qu'une autorité publique refuse, et que les décodeurs du marché affichent sans un mot.

Cet analyseur décode le CSR intégralement, puis confronte chaque fait mesuré aux CA/Browser Forum Baseline Requirements et aux RFC applicables. Il rend un verdict à trois états, conforme, avertissement ou non conforme, avec les constats et leur source. Le catalogue compte 59 codes ; le nombre de contrôles exécutés dépend du CSR analysé.

Trois usages qui reviennent :

• Avant soumission : corriger les points bloquants et n'envoyer qu'une fois le bon CSR.
• À réception du certificat : vérifier qu'il provient bien de ce CSR, empreinte de clé publique à l'appui.
• En reprise d'une PKI héritée : repérer noms internes, clés courtes et champs prohibés.

Ce que contient un CSR

Un Certificate Signing Request est un objet ASN.1 défini par la RFC 2986, encodé en DER puis transporté en base64 dans une enveloppe PEM. Il porte trois choses :

• une clé publique, RSA ou sur courbe elliptique, et elle seule ;
• des identifiants demandés : le sujet (CN, O, L, ST, C) et, dans un attribut PKCS#9 nommé extensionRequest, les extensions souhaitées dont les SAN ;
• une signature produite avec la clé privée correspondante.

Les SAN ne sont donc pas un champ de premier niveau : ils voyagent dans un attribut. C'est ce qui explique qu'une configuration openssl incomplète produise un CSR sans le moindre SAN sans que rien ne proteste.

Ce que votre autorité de certification fait vraiment du CSR

Voici le point que presque tous les décodeurs ratent : l'autorité reconstruit le certificat, elle ne recopie pas le CSR. Elle génère elle-même l'authorityInformationAccess, l'authorityKeyIdentifier, les certificatePolicies, l'extKeyUsage et jusqu'au subjectAltName du certificat émis. Un seul champ est repris à l'octet près : le SubjectPublicKeyInfo, votre clé publique et son identifiant d'algorithme.

Cela dicte la sévérité de chaque constat, et c'est le calibrage central de l'outil. Un contenu ne devient bloquant que s'il rend un certificat conforme impossible : clé hors profil, clé compromise, identifiant illicite, ou violation de la RFC 2986 par le CSR lui-même. Tout ce que l'autorité écrase ou ignore, une unité organisationnelle ou une extension exotique, plafonne à l'avertissement.

Ce que prouve la signature, et ce qu'elle ne prouve pas

La signature d'un CSR établit une chose : au moment de la fabrication, l'auteur détenait la clé privée associée à la clé publique, et le triplet sujet, clé et attributs n'a pas bougé depuis. Elle ne prouve aucun contrôle du domaine, aucune autorité du demandeur, aucune fraîcheur (PKCS#10 ne porte pas d'horodatage) et aucune exclusivité : la clé peut traîner dans un dépôt public.

Une signature invalide n'interrompt donc pas l'analyse, c'est un constat parmi les autres, et la cause en est souvent bénigne : troncature au copier-coller, CSR ré-encodé par un portail d'hébergeur. L'outil distingue trois états et non deux, valide, invalide et non vérifiable ; il n'accuse jamais d'altération un CSR qu'il n'a pas su vérifier.

Les refus qu'un décodage seul ne voit pas

Le CN doit figurer dans les SAN

Le Common Name est facultatif et déconseillé dans les profils actuels. Mais s'il est présent, il doit reprendre exactement une des valeurs du subjectAltName : un CN qui n'apparaît nulle part dans les SAN rend le certificat non conforme.

Le cas voisin est plus courant encore, le CSR sans aucun SAN. Avec un CN, il dépend d'une reconstruction bienveillante par l'autorité, à proscrire. Sans CN ni SAN, l'autorité n'a rien à valider et le refus est certain.

Les deux couches de règles sur les wildcards

La couche syntaxique vient de la RFC 9525 : un seul wildcard, seul contenu du label le plus à gauche. *.captaindns.com est valide ; *.*.captaindns.com et www*.captaindns.com ne le sont pas, et un client conforme doit ignorer le nom. Le certificat serait émis, puis inutilisable.

La couche politique vient des Baseline Requirements : une autorité doit refuser un wildcard posé sur un suffixe public de la section ICANN, *.co.uk par exemple. Sur la section privée de la même liste, le refus n'est qu'une recommandation, d'où un simple avertissement.

Rappel souvent oublié : un wildcard ne descend que d'un niveau. *.captaindns.com ne couvre ni captaindns.com ni a.b.captaindns.com.

Les noms internes ne sont plus émissibles depuis 2015

serveur.local, intranet.corp, nas.lan, localhost, un label unique sans point, ou un TLD absent de la zone racine : ce sont des noms internes. Leur émission est interdite depuis le 1er novembre 2015 et les certificats existants ont été révoqués de force le 1er octobre 2016. On les retrouve pourtant encore dans des CSR issus d'anciennes PKI internes, recyclés vers une autorité publique.

Même logique pour les adresses IP réservées en SAN, qu'elles relèvent de la RFC 1918, du loopback, du lien local, du CGNAT ou des ULA : une autorité ne valide pas ce qu'elle ne peut pas atteindre. Nouveauté : depuis le 15 mars 2026, un nom qui se termine par .in-addr.arpa ou .ip6.arpa est également interdit.

L'unité organisationnelle a disparu des certificats

Le champ organizationalUnit est prohibé depuis le 1er septembre 2022, en application du ballot SC047v2 adopté le 29 juin 2021 ; la référence courante au « ballot SC62 » est inexacte. L'autorité ne rejette pas le CSR pour autant, elle supprime le champ, d'où un avertissement.

Une adresse de courrier dans le sujet est dépréciée par la RFC 5280 et n'a aucune destination légale dans un certificat TLS serveur. Et un point contre-intuitif : un sujet vide est conforme, et même moderne. Le profil de validation de domaine n'accepte que le pays, facultatif, et le Common Name, déconseillé.

Tailles de clé, algorithmes et clés déjà compromises

RSA 2048 reste conforme : 3072 bits est une recommandation à l'horizon 2030, signalée en information. Une signature en SHA-1 n'est pas bloquante au sens des Baseline Requirements, dont la clause anti-SHA-1 vise les objets signés par une autorité et non par le souscripteur ; elle est classée en avertissement, avec la nuance qu'en pratique les autorités la refusent depuis 2016.

Deux contrôles vont plus loin. Ce sont les seuls endroits des Baseline Requirements où il est écrit que l'autorité doit rejeter la demande :

• ROCA (CVE-2017-15361) : les clés RSA produites par une bibliothèque répandue dans les cartes à puce et les TPM ont une structure reconnaissable qui effondre leur entropie. La détection ne factorise rien, c'est un test d'empreinte sur le modulus.
• Clés faibles Debian (CVE-2008-0166) : entre septembre 2006 et mai 2008, un générateur d'aléa cassé a réduit l'espace des clés à quelques dizaines de milliers de valeurs par taille. La liste est embarquée dans le service et consultée hors ligne.

Dans les deux cas, la paire de clés entière est à régénérer : reprendre la même clé dans un nouveau CSR reconduirait la faiblesse.

L'empreinte SPKI, celle qui apparie tout le reste

Tous les décodeurs affichent une « empreinte » du CSR. C'est le condensé du fichier entier : elle change si vous régénérez le CSR avec la même clé, et elle n'a aucun rapport avec le certificat que vous recevrez.

L'empreinte qui sert est celle du SubjectPublicKeyInfo, définie par la RFC 7469 : le condensé SHA-256 de la structure de clé publique encodée en DER. Comme c'est le seul champ recopié à l'octet près, la même valeur se retrouve dans le CSR, dans le certificat émis et dans la clé privée correspondante, et elle survit à une réémission.

Trois usages immédiats : apparier un certificat reçu à son CSR, sans comparer des sujets que l'autorité a de toute façon réécrits ; vérifier localement que votre clé privée est la bonne, avec la commande donnée plus bas ; composer un enregistrement DANE 3 1 1, dont le sélecteur 1 est exactement cette empreinte, que le vérificateur DANE/TLSA contrôle ensuite dans le DNS. L'empreinte est publiée en hexadécimal et en base64.

Comparer le CSR au certificat déployé

Option facultative, décochée par défaut : indiquez un hôte, et l'analyseur récupère le certificat qu'il sert réellement puis compare les deux empreintes SPKI. Trois cas, même clé, autre clé, ou hôte injoignable, ce dernier étant le plus fréquent puisqu'un CSR s'analyse avant émission.

C'est le seul chemin réseau de l'outil : case décochée, aucune connexion sortante. Le résultat n'entre jamais dans le verdict de conformité, car ce qui est déployé ailleurs ne dit rien de la validité d'une demande, et rien du CSR n'est transmis à l'hôte.

Pour juger le certificat déployé lui-même, chaîne de confiance et échéance comprises, l'outil dédié est le SSL Certificate Checker. Ensuite vient la gestion du cycle de vie des certificats, d'autant que la durée de validité descend à 47 jours d'ici 2029.

Commandes openssl utiles

Fichier san.cnf, sans lequel openssl produit un CSR dépourvu de SAN :

[ req ]
prompt = no
distinguished_name = dn
req_extensions = v3_req
[ dn ]
CN = www.captaindns.com
[ v3_req ]
subjectAltName = @alt
[ alt ]
DNS.1 = www.captaindns.com
DNS.2 = captaindns.com

# RSA 3072
openssl req -new -newkey rsa:3072 -nodes -keyout captaindns.key -out captaindns.csr -config san.cnf

# ECDSA P-256
openssl ecparam -name prime256v1 -genkey -noout -out captaindns.key
openssl req -new -key captaindns.key -out captaindns.csr -config san.cnf

Calculer l'empreinte SPKI du CSR, du certificat reçu et de la clé privée, puis vérifier que les trois coïncident, sans rien envoyer nulle part :

openssl req  -in captaindns.csr -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256
openssl x509 -in captaindns.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256
openssl pkey -in captaindns.key -pubout       | openssl pkey -pubin -outform DER | openssl dgst -sha256

Pour un domaine internationalisé, saisissez la forme punycode (préfixe xn--) dans les SAN : l'analyseur affiche la forme Unicode en regard et n'invalide jamais un label xn-- correct.

Confidentialité

Ne collez jamais votre clé privée, ici ou ailleurs : un CSR ne porte que la clé publique. Un en-tête PEM de clé privée est détecté avant tout envoi et l'analyse est refusée sur place. Si la clé a déjà été collée dans un formulaire web, considérez-la comme compromise et régénérez la paire.

Le CSR, lui, n'est pas un secret : il porte des identifiants destinés à figurer dans un certificat, publié ensuite dans les journaux de Certificate Transparency. Il est traité en mémoire pour être analysé et affiché. Seule exception, la valeur de l'attribut challengePassword n'est jamais renvoyée, ni affichée, ni journalisée : seule sa présence est signalée.

FAQ - Questions fréquentes

Q : Qu'est-ce qu'un CSR (Certificate Signing Request) ?

R : Un fichier PKCS#10, transporté en PEM, qui porte votre clé publique, les identifiants demandés (sujet et SAN) et une signature produite avec la clé privée correspondante. Il ne contient jamais la clé privée. Vous le transmettez à une autorité de certification, qui vérifie votre contrôle des domaines puis émet le certificat.

Q : Pourquoi une autorité de certification refuse-t-elle un CSR ?

R : Le plus souvent un Common Name absent des SAN, un wildcard mal formé ou posé sur un suffixe public, un caractère illégal dans un nom DNS (l'underscore en tête de liste), un nom interne en .local ou .corp, une adresse IP privée en SAN, une clé sous 2048 bits, ou l'absence totale de SAN.

Q : Le Common Name doit-il figurer dans les SAN ?

R : Oui, dès lors qu'il est présent : les Baseline Requirements imposent qu'il reprenne exactement une des valeurs du subjectAltName. Le plus simple reste de ne pas le renseigner, puisque les navigateurs ne lisent que les SAN depuis des années.

Q : Mon CSR est signé en SHA-1, est-ce bloquant ?

R : Pas au sens des Baseline Requirements : la clause qui interdit SHA-1 vise les objets signés par la clé privée d'une autorité, or un CSR est signé par le souscripteur. L'outil le classe en avertissement. En pratique, les autorités publiques refusent les CSR en SHA-1 depuis 2016, donc régénérez en SHA-256. MD5 et MD2 sont bloquants.

Q : Faut-il remplir les champs O, OU, L et ST du sujet ?

R : Non pour un certificat de validation de domaine : le profil n'accepte que le pays, facultatif, et le Common Name, déconseillé. Un sujet vide est parfaitement conforme. L'unité organisationnelle est même prohibée depuis le 1er septembre 2022.

Q : À quoi sert l'empreinte SPKI ?

R : C'est le condensé SHA-256 de la structure de clé publique, le seul champ qu'une autorité recopie à l'octet près du CSR vers le certificat. Elle prouve qu'un CSR, un certificat reçu et une clé privée portent la même clé, et elle sert de sélecteur 1 dans un enregistrement DANE TLSA. L'empreinte publiée par les autres décodeurs porte sur le fichier entier et ne permet aucun de ces rapprochements.

Q : Le certificat déjà en ligne correspond-il à mon CSR ?

R : Cochez l'option de comparaison et indiquez l'hôte. L'analyseur récupère le certificat servi et compare son empreinte SPKI à celle du CSR : même clé, autre clé, ou hôte injoignable. Cette comparaison n'influence jamais le verdict de conformité et ne transmet rien du CSR à l'hôte interrogé.

Q : Comment générer un CSR avec des SAN sous openssl ?

R : Créez un fichier de configuration listant DNS.1, DNS.2, etc., puis lancez openssl req -new -newkey rsa:3072 -nodes -keyout captaindns.key -out captaindns.csr -config san.cnf. Pour une clé elliptique, générez d'abord la clé avec openssl ecparam -name prime256v1 -genkey -noout, puis appelez openssl req -new -key. Sans ce fichier, openssl produit un CSR dépourvu de SAN.

Outils complémentaires

Ressources utiles

• RFC 2986 - syntaxe de requête de certification (structure PKCS#10 du CSR)
• RFC 9525 - vérification d'identité de service (règles de wildcard, remplace la RFC 6125)
• RFC 7469 - épinglage de clé publique (définition normative de l'empreinte SPKI)
• CA/Browser Forum - Baseline Requirements (règles d'émission des certificats TLS)