Décodeur de Certificat SSL (X.509)
Collez un certificat SSL/TLS au format PEM pour décoder instantanément son sujet, son émetteur, sa période de validité, son SAN, son numéro de série, son algorithme de clé publique et ses empreintes SHA-1/SHA-256. Outil gratuit qui fonctionne aussi hors ligne avec les certificats autosignés et les CA internes.
Qu'est-ce que le Décodeur de Certificat SSL ?
Le Décodeur de Certificat SSL est un outil gratuit qui, à partir d'un certificat SSL/TLS au format PEM que vous collez, affiche en un coup d'œil le sujet, l'émetteur, la période de validité, les entrées SAN, le numéro de série, l'algorithme de clé publique, l'algorithme de signature et les empreintes. L'analyse de la structure binaire ASN.1 DER sous-jacente s'effectue côté serveur, si bien que n'importe qui peut examiner le contenu d'un certificat sans avoir besoin de la ligne de commande OpenSSL ni d'aucun logiciel spécial.
Contrairement à un vérificateur SSL en direct (qui se connecte à un domaine public sur internet et récupère le certificat via un véritable handshake TLS), cet outil décode directement le texte PEM que vous collez. Cela signifie qu'il peut aussi examiner des certificats qu'un vérificateur en direct ne peut tout simplement pas atteindre : des certificats pas encore déployés en production, des certificats autosignés ou issus d'une CA interne sur un réseau privé, ainsi que des fichiers de certificat déjà enregistrés localement.
Comment utiliser le Décodeur de Certificat SSL
- Collez votre certificat PEM Collez le texte commençant par « -----BEGIN CERTIFICATE----- » directement dans le champ de texte.
- Plusieurs certificats sont pris en charge Collez une chaîne complète (certificat feuille plus intermédiaires) : chaque bloc est détecté automatiquement.
- Cliquez sur « Décoder » Vérifiez le nombre de certificats détectés, puis cliquez sur le bouton pour les analyser côté serveur.
- Consultez les résultats Sujet, émetteur, période de validité, SAN, empreintes et plus encore sont listés pour chaque certificat.
Astuces pour en tirer le meilleur parti
- Vous pouvez coller une chaîne de certificats entière (certificat serveur plus intermédiaires CA) en une seule fois : chaque bloc est séparé et décodé individuellement.
- Comparez l'empreinte SHA-256 affichée ici avec la valeur publiée par l'autorité de certification ou le fournisseur pour confirmer que le certificat n'a pas été substitué ou altéré.
- Un certificat dont le Sujet et l'Émetteur sont identiques est autosigné : il est signalé par un badge dédié dans les résultats.
- Cliquez sur « Charger un certificat d'exemple » avant de coller le vôtre pour voir exactement à quoi ressemble le résultat.
- Avant de mettre en production un certificat multidomaine, vérifiez toujours que tous les noms d'hôte requis figurent bien dans le SAN.
Quand utiliser cet outil
Diagnostiquer une erreur d'expiration
Quand le navigateur affiche un avertissement de certificat expiré, vérifiez directement l'horodatage exact de validTo.
Vérifier le SAN avant la mise en production
Avant de basculer un certificat multidomaine, confirmez que tous les noms d'hôte nécessaires figurent bien dans l'extension SAN.
Auditer la robustesse de la clé
Lors d'une revue de sécurité, vérifiez l'algorithme et la longueur de la clé publique, par exemple RSA 2048 bits ou plus, ou quelle courbe EC est utilisée.
Examiner des certificats internes ou autosignés
Décodez des certificats de systèmes internes ou de CA privées qu'un vérificateur en direct basé sur le domaine ne peut pas atteindre.
Glossaire
- PEM
- Un format texte qui encadre des données DER encodées en Base64 entre des lignes « -----BEGIN CERTIFICATE----- » et « -----END CERTIFICATE----- ». C'est la façon la plus courante de stocker et d'échanger des certificats.
- X.509
- La norme internationale qui définit la structure des certificats à clé publique. Elle est à la base non seulement de TLS/SSL, mais aussi de S/MIME et de la signature de code.
- ASN.1 / DER
- Les règles d'encodage binaire qui définissent strictement la structure interne du certificat. Le PEM n'est autre que ces données DER encodées en texte Base64.
- SAN (nom alternatif du sujet)
- Une extension qui liste les noms d'hôte ou adresses IP supplémentaires pour lesquels le certificat est valide. Elle est obligatoire pour tout certificat couvrant plusieurs domaines.
- Empreinte
- Un hachage de l'ensemble du certificat, utilisé pour vérifier qu'il n'a pas été substitué ou altéré.
- Certificat autosigné
- Un certificat dont l'Émetteur et le Sujet sont identiques, ce qui signifie qu'il n'a pas été vérifié par une autorité de certification (CA) tierce.
Questions fréquentes
Anecdote — Pourquoi un certificat ressemble-t-il à un charabia illisible ?
Ouvrez un fichier de certificat et vous trouverez généralement un bloc de texte dense et illisible commençant par « -----BEGIN CERTIFICATE----- ». Ce format s'appelle PEM (Privacy-Enhanced Mail) et, en dessous, il ne s'agit de rien d'autre que de données binaires encodées en DER — une structure définie par une notation appelée ASN.1 — enveloppées en Base64 afin de pouvoir circuler sans encombre à travers les systèmes de messagerie et les fichiers texte bruts. Autrement dit, le PEM n'est que le DER habillé différemment ; le contenu réel est strictement défini comme une série d'éléments ASN.1 TLV (étiquette, longueur, valeur), et le rôle de cet outil est précisément de décoder cette structure binaire en quelque chose qu'un humain peut réellement lire.
Le nom même « X.509 » a une histoire inattendue. Il a été défini à l'origine par l'UIT-T (Union internationale des télécommunications) en 1988 dans le cadre de la norme de services d'annuaire X.500, bien avant l'existence du Web moderne. Il a ensuite été adapté pour un usage sur internet par l'IETF sous la référence RFC 2459 en 1999, et aujourd'hui la RFC 5280 en est la spécification actuelle. Les certificats existent en versions v1, v2 et v3, et des champs d'extension comme le SAN (nom alternatif du sujet) ne sont disponibles qu'à partir de la v3. Pratiquement tous les certificats TLS émis aujourd'hui sont en v3, et cet outil suppose des extensions de type v3 lors du décodage.
Il est courant de voir une empreinte SHA-1 et une empreinte SHA-256 affichées côte à côte pour un même certificat. Le SHA-1 est déconseillé comme algorithme de signature depuis que des attaques par collision pratiques ont été démontrées contre lui, mais il continue d'apparaître comme empreinte pour identifier un certificat de façon unique, surtout par compatibilité avec des outils plus anciens, ce qui explique pourquoi cet outil affiche les deux valeurs. Pour toute nouvelle vérification, il est préférable de privilégier la valeur SHA-256.