Décodeur de certificats et de PEM

Ce que fait cet outil

Un certificat arrive sous forme de bloc Base64 entre deux lignes de tirets, et rien ne s’en devine à l’œil. Cet outil le décode : à qui il a été délivré et par qui, quand il expire, quels noms d’hôte il couvre, quelle clé il contient et toutes les extensions qu’il porte. Collez une chaîne entière et chaque certificat est confronté au suivant.

Tout s’exécute dans votre navigateur. Cela compte ici plus qu’ailleurs : l’alternative consiste généralement à coller un certificat de production sur le serveur de quelqu’un d’autre, ou à se souvenir de l’invocation openssl, ce que presque personne ne fait.

PEM n’est que l’emballage

Les tirets et le Base64 sont de l’emballage. À l’intérieur se trouve du DER, un encodage binaire d’une structure appelée ASN.1, et l’étiquette entre les tirets indique quelle structure attendre :

CERTIFICATE           un certificat X.509 délivré
CERTIFICATE REQUEST   une CSR : ce que vous avez demandé à une AC
PUBLIC KEY            une clé seule, sans identité attachée
PRIVATE KEY           la moitié secrète, refusée ici

Le même certificat peut aussi arriver en DER brut dans un fichier .cer ou .crt, sans tirets ni Base64. Si un fichier s’ouvre comme du bruit binaire plutôt que du texte, c’est de cela qu’il s’agit : encodez-le d’abord en Base64, ou exportez-le en PEM.

Ce qu’il y a vraiment dans un certificat

Les champs de base sont les mêmes dans tous les certificats jamais délivrés :

• Sujet — de qui parle le certificat. Pour un site web, ce n’est plus aujourd’hui qu’un nom commun, et souvent rien de plus.
• Émetteur — l’autorité de certification qui l’a signé. Son nom de sujet apparaît mot pour mot comme émetteur de tout ce qu’elle signe, et c’est ce qui rend la vérification de chaîne possible.
• Validité — deux instants absolus, toujours en UTC. Cet outil affiche les deux et calcule le temps restant dans votre navigateur, car la machine qui a généré cette page ignore quand vous la lisez.
• Numéro de série — unique par émetteur, et l’identifiant utilisé lorsqu’un certificat est révoqué.
• Algorithme de signature — avec quoi l’émetteur a signé, par exemple SHA-256 avec ECDSA.
• Clé publique — le type et la taille. Pour RSA, c’est la longueur en bits du module ; pour EC, c’est une propriété de la courbe nommée, si bien que P-256 fait toujours 256 bits.

Un champ que l’on cherche et que l’on ne trouve plus : le nom commun du sujet n’est pas ce que vérifient les navigateurs. Il est ignoré pour la correspondance de nom d’hôte depuis des années. Ce qui compte, c’est l’extension des noms alternatifs, ci-dessous.

Les extensions qui décident si ça marche

Un certificat peut porter un nombre quelconque d’extensions. Cinq déterminent s’il sera réellement accepté, et cet outil les décode intégralement :

• Noms alternatifs du sujet — les noms d’hôte, adresses IP ou adresses de courriel pour lesquels le certificat est valide. C’est le champ que vérifient les navigateurs, et un certificat dont les noms alternatifs n’incluent pas celui que vous avez tapé sera rejeté, si correct que soit le reste.
• Contraintes de base — s’il s’agit d’une autorité de certification, et combien d’intermédiaires peuvent se placer en dessous. Un certificat final marqué comme AC, ou l’inverse, casse la chaîne.
• Utilisation de la clé — ce à quoi la clé peut servir : signature, chiffrement de clé, signature de certificats. Marquée critique presque toujours, ce qui oblige un logiciel à rejeter le certificat plutôt qu’à ignorer un usage qu’il ne comprend pas.
• Utilisation étendue de la clé — la finalité : serveur TLS, client TLS, signature de code, courriel. Un certificat sans authentification de serveur TLS ne servira pas un site web, et c’est une surprise fréquente pour les certificats délivrés à d’autres fins.
• Identifiants de clé du sujet et de l’autorité — de courtes empreintes qui permettent à un logiciel de rattacher rapidement un certificat à son émetteur lorsque plusieurs partagent un nom.

Toute autre extension est listée avec son nom lorsqu’il est connu, son OID, et le fait qu’elle soit marquée critique ou non. Rien n’est écarté en silence : une extension que cet outil ne décode pas apparaît quand même, pour que l’on voie qu’elle est là.

Les chaînes, et ce que « continue » veut dire ici

Un serveur n’envoie presque jamais un seul certificat. Il envoie le sien plus les intermédiaires nécessaires pour atteindre une racine à laquelle le client fait déjà confiance. L’ordre compte et le fichier s’appelle généralement fullchain.pem :

bloc 1   final          subject: example.com     issuer: Example CA R3
bloc 2   intermediaire  subject: Example CA R3   issuer: Example Root
bloc 3   racine         souvent omise : le client la possede deja

Chaque certificat nomme son émetteur, et le certificat suivant devrait avoir exactement ce nom comme sujet. Cet outil compare ces deux noms octet par octet et dit s’ils correspondent. C’est la seule relation vérifiable hors ligne, et elle attrape les deux défaillances qui expliquent la plupart des problèmes de chaîne : un intermédiaire oublié et des blocs collés dans le mauvais ordre.

Ces défaillances ont un symptôme caractéristique. Les navigateurs de bureau masquent souvent un intermédiaire manquant en allant le chercher eux-mêmes : le site paraît correct sur votre portable et échoue sur un téléphone, dans une application mobile ou depuis curl. Si cela décrit ce que vous déboguez, collez d’abord la chaîne complète ici.

Ce que cet outil ne vous dit pas

Il ne vérifie pas les signatures, et il ne le peut pas. Contrôler qu’un certificat a bien été signé par son émetteur exige la clé publique de celui-ci ; décider si cet émetteur mérite d’être cru exige un magasin de confiance. Un fichier collé ne fournit ni l’un ni l’autre. Il ne peut pas davantage vérifier la révocation, qui suppose une requête réseau vers l’AC.

Donc « la chaîne est continue » signifie ici que les noms s’alignent, pas que la chaîne est valide. Une chaîne de certificats falsifiés s’alignerait parfaitement. Ce à quoi la vérification sert, c’est à repérer les erreurs de structure dans votre propre configuration — précisément ce que l’on regarde en collant une chaîne dans un décodeur.

Empreintes et clés privées

L’empreinte SHA-256 est un condensat du certificat entier, et c’est elle que l’on compare à une valeur transmise ou à un pin. Notez ce qu’elle identifie : le certificat, pas la clé qu’il contient. Renouveler un certificat pour la même clé produit une empreinte différente, ce qui explique le plus souvent qu’un pin casse au renouvellement. L’empreinte SHA-1 est affichée aussi parce que d’anciens outils et consoles l’impriment encore — à des fins d’identification seulement ; SHA-1 n’a rien à faire dans une signature.

Les clés privées sont reconnues et refusées. Rien de ce qui est collé ici ne quitte votre navigateur, donc le refus ne concerne pas cette page : coller une clé privée dans un formulaire web est une habitude à ne pas prendre, et le prochain site qui le demandera ne tournera peut-être pas en local. Si vous devez vérifier qu’une clé et un certificat vont ensemble, comparez localement la clé publique du certificat et celle dérivée de la clé.