Décodeur de certificat SSL

Ce qu'un décodeur de certificat vous montre

Un certificat SSL est une structure X.509 encodée en DER, généralement enveloppée dans l'armure base64 qui constitue un fichier PEM. On y trouve les noms du sujet et de l'émetteur, un numéro de série, les deux dates entre lesquelles le certificat est valide, une clé publique et une liste d'extensions — dont celle qui compte pour un site web est le nom alternatif du sujet, puisque les navigateurs n'acceptent plus le nom commun comme nom d'hôte depuis des années.

Décoder tout cela ne demande aucun serveur. C'est une lecture octet par octet d'un profil très étroit d'un encodage, et c'est pourquoi cette page le fait dans l'onglet que vous avez déjà ouvert plutôt que de vous demander de téléverser quoi que ce soit. Cela compte moins pour un certificat public de serveur que pour une clé privée, mais l'habitude de coller du matériel cryptographique dans le formulaire d'autrui n'est pas une bonne habitude, et ce site tient la même position sur le décodeur JWT.

Ce que presque aucun décodeur ne vous dit, c'est si le certificat respecte réellement les règles. Le RFC 5280 est assez précis sur plusieurs points faciles à vérifier et faciles à rater, et de vrais certificats de votre propre magasin de confiance les enfreignent.

Comment s'en servir

1. Collez le certificat. Un bloc PEM complet, uniquement le base64 entre les lignes d'armure, ou de l'hexadécimal brut. Les trois fonctionnent, et les espaces sont ignorés.
2. Lisez les champs. Noms, série, validité, clé et extensions. Les deux dates indiquent en plus quel type de temps ASN.1 les encode, et c'est précisément la partie qui se révèle importante.
3. Regardez la liste de conformité. Tout ce que le certificat fait et que le RFC 5280 interdit ou déconseille est expliqué, avec sa raison. Un certificat conforme est signalé comme tel.

La règle que presque personne ne vérifie, et les racines qui l'enfreignent

La section 4.1.2.5 du RFC 5280 est singulière. Elle ne se contente pas d'autoriser deux façons d'écrire une date : elle impose laquelle selon l'année. Les dates jusqu'en 2049 doivent être en UTCTime, et celles de 2050 et au-delà en GeneralizedTime. La raison tient à ce qu'UTCTime porte une année sur deux chiffres, 00 à 49 se lisant 20xx et 50 à 99 se lisant 19xx : l'encodage ne peut tout simplement pas exprimer 2050.

Cela donne à la règle une forme étrange. Une moitié est imposée par l'encodage et ne peut pas être enfreinte — aucun certificat ne peut loger 2050 dans un UTCTime, faute de place. L'autre moitié n'est imposée par rien, et elle est enfreinte. Sur les 150 certificats racines d'un magasin de confiance standard, 149 encodent leurs dates en UTCTime et un utilise GeneralizedTime en expirant en 2046, quatre ans avant que la bascule ne soit permise. Certum Trusted Network CA 2 figure dans le magasin de confiance par défaut de pratiquement tous les navigateurs et systèmes d'exploitation, et vous pouvez le charger dans le cadre ci-dessus pour voir le signalement.

Le même magasin révèle une seconde infraction plus fréquente. La section 4.1.2.2 dit que le numéro de série d'un certificat doit être un entier positif. Huit des 150 racines ont un numéro de série nul, dont deux racines Go Daddy et deux de l'autorité Hellenic Academic and Research Institutions. Zéro n'est pas positif, et OpenSSL affichera serial=00 pour toutes si vous préférez vérifier avec autre chose que cette page.

Ni l'une ni l'autre ne rend un certificat dangereux. Ce sont de ces choses qu'autorisait ce qui a fabriqué le certificat il y a une décennie ou plus, et qui se transmettent discrètement depuis. Elles méritent d'être montrées parce qu'un décodeur qui ne rapporte que les champs vous dit ce que le certificat déclare, pas s'il est bien formé.

Limites assumées, et vérifications

Ceci lit un certificat, il ne le vérifie pas. Pas de contrôle de signature, pas de construction de chaîne, pas de consultation de révocation et pas de décision de confiance, car tout cela exige le certificat de l'émetteur et une source de révocation à jour, et une page ne peut honnêtement prétendre disposer ni de l'un ni de l'autre. Si l'outil dit qu'un certificat est auto-signé, c'est une affirmation sur l'égalité de deux noms, pas sur la validité de la signature.

Il ne décode par ailleurs que les extensions qui valent un résumé, et affiche les autres sous forme d'identifiant d'objet et d'octets bruts. Les politiques de certification et les horodatages de transparence sont des structures à part entière, et les décoder à moitié serait pire que de les montrer telles quelles.

L'analyseur est confronté à OpenSSL sur les 150 certificats racines d'un magasin réel : tous les numéros de série, toutes les versions, les deux instants de validité et tous les attributs du sujet concordent, avec 326 assertions et 15 contrôles négatifs. Trois désaccords sont apparus au cours de ce travail et tous les trois venaient de la comparaison, non de l'analyseur, dont un qui ne s'est manifesté que parce qu'OpenSSL échappe le texte non ASCII dans sa sortie alors que l'analyseur le décode. Les cas qu'un magasin de confiance ne peut pas fournir — une série de plus de vingt octets, un certificat qui ne soit pas auto-signé, un nom en BMPString — sont fabriqués de toutes pièces dans la suite de tests, car une règle que rien dans le corpus n'enfreint n'est pas réellement testée.

Pourquoi est-ce gratuit ?

Aucun serveur n'intervient. Analyser du DER, c'est de l'arithmétique sur des octets, cela s'exécute dans votre navigateur, et il n'y a rien à facturer ni de compte à créer.

Rien de ce que vous collez n'est envoyé, conservé ni journalisé. Un certificat public n'est pas un secret, mais le cadre ci-dessus acceptera volontiers des choses qui le sont, et la seule conception sûre est celle où cela ne peut pas avoir d'importance.