Visualiseur de certificat SSL et de CSR

Aperçu

Un certificat est un ensemble signé d’affirmations en DER, un encodage binaire, enveloppé en Base64 pour le transport. Tout ce qui va de travers avec les certificats en pratique est visible dans ces affirmations : un nom absent de la liste SAN, une fenêtre de validité qui se termine plus tôt que prévu, un intermédiaire collé là où va une feuille, un usage de clé qui interdit l’usage pour lequel il a été acheté.

Cette visionneuse décode le PEM, analyse le DER et présente le contenu — pour les certificats X.509 comme pour les demandes de certificat PKCS#10. Elle le fait dans votre navigateur, et elle refuse catégoriquement les clés privées.

Utilisation

1. Collez un bloc PEM commençant par -----BEGIN CERTIFICATE----- ou -----BEGIN CERTIFICATE REQUEST-----.
2. Lisez la synthèse : type, sujet, émetteur, validité, jours restants.
3. Confrontez la liste SAN aux noms d’hôte que vous comptez servir.

Pour récupérer un certificat en direct depuis un serveur : openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509

Les noms alternatifs sont les seuls qui comptent

Le Common Name du sujet ressemble au nom du certificat, et pour la validation du nom d’hôte il n’est pas utilisé. Chrome l’a ignoré depuis la version 58, et les autres navigateurs ont suivi. Seule l’extension subjectAltName est consultée.

Les conséquences pratiques :

• Un certificat dont le nom d’hôte n’apparaît que dans le CN échoue à la validation dans tous les navigateurs actuels, tout en paraissant parfaitement correct dans n’importe quel outil qui affiche le sujet en évidence.
• Un joker *.example.com correspond à une seule étiquette. Il couvre www.example.com et non a.b.example.com, et il ne couvre pas le example.com nu — ce nom exige sa propre entrée SAN, d’où le fait que les certificats listent couramment les deux.
• Les SAN sont typés. Les entrées dNSName, iPAddress, rfc822Name et URI sont toutes affichées, et un nom d’hôte placé dans le mauvais type ne correspond pas.

Lire la clé et son usage

L’algorithme et la taille de clé sont lus dans la structure de clé publique. Pour RSA, la longueur du module donne directement la taille en bits. Pour EC, la courbe nommée est indiquée lorsqu’il y en a une, et lorsque le certificat porte des paramètres explicites au lieu d’un nom de courbe, cela est signalé comme tel — les paramètres explicites sont rejetés par la plupart des piles TLS modernes, il vaut donc la peine de le voir. En l’absence de nom de courbe, la taille est déduite de la longueur du point public, d’où une clé P-521 rapportée à 521 plutôt qu’aux 528 qu’un simple comptage d’octets donnerait.

keyUsage et extendedKeyUsage décrivent ce que la clé est autorisée à faire, et les deux sont appliqués. Un certificat sans serverAuth dans son EKU ne fonctionnera pas pour TLS même si tout le reste est correct — résultat fréquent lorsqu’un certificat client est installé par erreur sur un serveur.

basicConstraints indique si le certificat est une AC. Si vous avez collé ce que vous pensiez être votre certificat feuille et qu’il est rapporté comme AC, vous avez collé l’intermédiaire — cause habituelle d’une chaîne qui valide localement et échoue ailleurs.

La liste des extensions montre chaque extension présente avec son indicateur critique. Une extension critique que le client ne comprend pas doit provoquer un rejet, selon la RFC 5280 : une extension critique inconnue mérite donc examen.

Exemples

• Un nom qui ne valide pas — vérifiez la liste SAN, pas le sujet. Si le nom d’hôte n’est que dans le CN, le certificat doit être réémis.
• Lire une CSR avant de l’envoyer — la CSR fixe le sujet et la clé publique. Confirmer les noms avant soumission évite un cycle de réémission, surtout lorsque l’AC le facture.
• Confirmer quel certificat vous avez — feuille, intermédiaire et racine se ressemblent en texte. basicConstraints et la relation sujet/émetteur les identifient immédiatement : une racine a un sujet et un émetteur identiques.
• Planifier les renouvellements — les jours restants sont affichés directement. Le secteur évoluant vers des durées de vie maximales bien plus courtes, un processus de renouvellement manuel qui fonctionnait pour des certificats annuels ne survit pas à ce changement.
• Auditer un lot — collez chaque bloc à son tour. Un lot dans le mauvais ordre, ou incluant un certificat sans rapport, est une cause fréquente d’erreur de chaîne n’apparaissant que chez certains clients.

Remarques

Seuls les blocs PEM CERTIFICATE et CERTIFICATE REQUEST sont acceptés. Tout autre type de bloc, y compris tous les formats de clé privée, est refusé avec une erreur nommant ce qui a été trouvé. Rien d’un bloc refusé n’est analysé ni affiché.

L’analyseur DER rejette ce que DER interdit : les encodages de longueur indéfinie, les longueurs dépassant la fin du tampon, et l’imbrication au-delà de 32 niveaux. Un collage tronqué produit un message précis tel que ASN.1 length exceeds buffer plutôt qu’un rapport partiellement rempli, car un certificat à demi analysé invite à la méprise. Lorsque l’analyse échoue, tout résultat précédent est effacé pour la même raison.

Les dates sont affichées telles qu’encodées dans le certificat. GeneralizedTime porte une année à quatre chiffres ; UTCTime en porte deux, et la RFC 5280 fixe l’interprétation à 50–99 pour 19xx et 00–49 pour 20xx. Les jours restants sont calculés d’après l’horloge de votre appareil : une heure système erronée donne donc un chiffre erroné.

Cet outil lit un certificat isolé. La construction de chaîne, la révocation et la confiance ne sont pas évaluées. Pour voir ce qu’un serveur envoie réellement et comment il répond, utilisez en-têtes HTTP et le vérificateur d’en-têtes de sécurité. Tout se passe ici dans votre navigateur — voir la politique de confidentialité.