Outil gratuit · 100 % navigateur
Certificate Decoder
Calcul : @peculiar/x509 (PeculiarVentures) · MIT
01Décoder
PEM (un ou plusieurs blocs, texte autour toléré), DER en base64 ou hexadécimal, PKCS#7. Décodé à chaque frappe, dans le navigateur.
Certificats fictifs générés pour l’outil (example.com, example.internal).
Recon
Noms découverts
- Les noms d’hôtes, adresses et domaines extraits des certificats apparaîtront ici.
Domaines racines
Chaque lien ouvre crt.sh sur les journaux Certificate Transparency du domaine. Rien n’est interrogé tant que vous ne cliquez pas.
Hôtes de la PKI (AIA, CRL)
02Faiblesses
03Chaîne
04Détail
05Récupérer un certificat en mission
openssl s_client -connect www.example.com:443 -servername www.example.com -showcerts </dev/nullopenssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -outform PEM > www.example.com.pemnmap -p 443 --script ssl-cert -- www.example.comopenssl s_client -connect www.example.com:25 -starttls smtp -showcerts </dev/nullcurl -s 'https://crt.sh/?q=%25.example.com&output=json' | jq -r '.[].name_value' | sort -uÀ lancer depuis votre poste. Collez ensuite la sortie complète de s_client ci-dessus : le texte autour des blocs est ignoré.
Qu’est-ce qu’un certificat X.509 ?
Un certificat X.509 est un document signé qui associe une clé publique à une identité, comme un nom de domaine. Dans HTTPS, sa validation aide le client à authentifier le serveur. Il contient notamment l’émetteur, la période de validité, les noms alternatifs et la clé publique.
Structure d’un certificat X.509
Un certificat X.509 v3 (RFC 5280) lie une clé publique à une identité, sous la signature d’une autorité. Il contient trois éléments : le tbsCertificate, qui regroupe les champs signés, l’algorithme de signature et la signature elle-même.
Les champs signés comprennent le numéro de série, l’émetteur et le sujet (des noms distinctifs : CN, O, OU, C…), la période de validité (notBefore, notAfter), la clé publique et les extensions.
Les extensions portent l’essentiel du sens. basicConstraints dit si le certificat est une autorité, keyUsage et extendedKeyUsage limitent les usages (serverAuth pour un serveur TLS), subjectAltName liste les noms couverts, authorityInfoAccess indique le répondeur OCSP et l’adresse de l’intermédiaire, cRLDistributionPoints la liste de révocation.
Le CN n’a plus de rôle pour les noms d’hôtes : le RFC 2818 demandait dès 2000 d’utiliser le SAN quand il existe, et Chrome ignore le CN depuis la version 58 (2017).
Sur le disque, un certificat se présente en DER, l’encodage binaire ASN.1, ou en PEM, le même DER en base64 entre deux lignes -----BEGIN CERTIFICATE----- (RFC 7468). Les extensions .crt et .cer désignent l’un ou l’autre.
Un fichier PKCS#7 (.p7b, RFC 2315) transporte une liste de certificats sans clé ; un PKCS#12 (.pfx, .p12, RFC 7292) contient en général la clé privée, protégée par un mot de passe. Conversions : openssl x509 -inform DER -in a.cer -out a.pem, openssl pkcs7 -print_certs -in a.p7b, openssl pkcs12 -in a.pfx -nokeys.
Les certificats comme source de recon
Le SAN d’un certificat de production liste souvent bien plus que le site visé : API, préproduction, VPN, consoles d’administration. Le certificat servi par une adresse IP nue donne le nom virtuel à placer dans l’en-tête Host pour atteindre la bonne application, et un wildcard indique une convention de nommage à compléter par énumération DNS.
Les noms internes (.local, .corp, .internal, plages RFC 1918) dévoilent le réseau privé, et les URL LDAP des points de distribution CRL d’une PKI AD CS donnent le nom du domaine Active Directory et du serveur d’autorité.
Certificate Transparency (RFC 6962, 2013) oblige les autorités publiques à inscrire chaque certificat dans des journaux publics en ajout seul ; Chrome l’exige pour les certificats émis après le 30 avril 2018. Ces journaux forment un inventaire complet et historique des noms de chaque domaine, que crt.sh (exploité par Sectigo) rend interrogeable : %.example.com renvoie tous les certificats émis pour le domaine et ses sous-domaines, y compris des hôtes retirés depuis.
C’est une recon entièrement passive, sans aucun paquet envoyé vers la cible.
La chaîne de confiance
Un client accepte un certificat de serveur s’il remonte, signature après signature, jusqu’à une racine de son magasin de confiance. Le serveur doit envoyer sa feuille puis les intermédiaires ; la racine est inutile puisque le client la possède déjà. TLS 1.2 (RFC 5246) imposait l’ordre feuille, puis chaque certificat signé par le suivant ; TLS 1.3 (RFC 8446) demande aux clients de tolérer le désordre, que des bibliothèques anciennes, Java ou embarquées gèrent encore mal.
Un intermédiaire manquant passe inaperçu dans Chrome sous Windows, qui le télécharge depuis l’URL caIssuers de l’extension AIA, mais casse curl, OpenSSL, les applications mobiles et la plupart des clients d’API. L’outil vérifie chaque maillon (nom de l’émetteur, identifiants de clé AKI et SKI, signature) avec Web Crypto.
Il ne consulte ni magasin de confiance ni état de révocation : pour cela, utilisez openssl verify -CAfile ou testez la connexion réelle.
Faiblesses fréquentes et règles du CA/B Forum
Les Baseline Requirements du CA/B Forum s’imposent aux autorités reconnues par les navigateurs. Elles interdisent les certificats signés en SHA-1 depuis le 1er janvier 2016 et les noms internes ou adresses réservées depuis le 1er novembre 2015, et exigent des clés RSA d’au moins 2048 bits. Les signatures MD5 sont exclues depuis bien plus longtemps : une collision MD5 a permis de forger un certificat d’autorité en 2008.
La durée de validité maximale d’un certificat public dépend de sa date d’émission : 39 mois à partir du 1er avril 2015, 825 jours à partir du 1er mars 2018 (ballot 193), puis 398 jours à partir du 1er septembre 2020, règle imposée par Apple puis reprise dans les Baseline Requirements par le ballot SC31 en juillet 2020.
Le ballot SC-081v3, adopté le 11 avril 2025, la réduit à 200 jours pour les certificats émis à partir du 15 mars 2026, à 100 jours à partir du 15 mars 2027 et à 47 jours à partir du 15 mars 2029. L’outil applique le plafond en vigueur à la date notBefore, seulement aux certificats qui portent une politique du CA/B Forum ou des SCT.
Hors de ces règles, les défauts typiques d’une PKI interne ou d’un équipement sont les certificats auto-signés, que les utilisateurs apprennent à accepter, les certificats de serveur marqués CA:TRUE (le défaut de openssl req -x509 avec la configuration standard), les wildcards partagés entre de nombreux serveurs et les durées de dix ans ou plus.
Se défendre
- Tenez un inventaire des certificats à partir des journaux CT : crt.sh, Cert Spotter ou une surveillance dédiée signalent toute émission pour vos domaines, y compris par un tiers.
- Automatisez le renouvellement avec ACME (RFC 8555) : les durées courtes imposées d’ici 2029 rendent le renouvellement manuel intenable, et une clé volée cesse vite d’être utile.
- N’exposez pas de noms internes dans un certificat public : réservez-les à une PKI interne et évitez de regrouper préproduction et production dans le même SAN.
- Publiez un enregistrement CAA (RFC 8659) pour limiter les autorités autorisées à émettre pour vos domaines.
- Préférez des certificats par service aux wildcards partagés, et des clés ECDSA P-256 ou RSA 2048 et plus, signées en SHA-256.
?Questions fréquentes
Mon certificat est-il envoyé à un serveur ?
Le décodage, le calcul des empreintes et la vérification des signatures se font dans votre navigateur, avec la bibliothèque @peculiar/x509 et l’API Web Crypto. Aucune requête ne part : les liens vers crt.sh ne s’ouvrent que si vous cliquez, et l’outil ne télécharge jamais l’intermédiaire indiqué par l’extension AIA.
Comment récupérer le certificat d’un serveur ?
openssl s_client -connect hôte:443 -servername hôte -showcerts </dev/null affiche toute la chaîne envoyée par le serveur ; collez la sortie entière, le texte autour des blocs PEM est ignoré. Sur une plage d’adresses, nmap --script ssl-cert lit le certificat de chaque service TLS. Dans un navigateur, le cadenas permet aussi d’exporter le certificat en PEM.
Pourquoi les SAN intéressent-ils un pentester ?
L’extension Subject Alternative Name liste tous les noms qu’un certificat couvre. Un seul certificat révèle souvent des environnements de préproduction, des API, des VPN et parfois des noms internes. Comme tous les certificats publics sont inscrits dans les journaux Certificate Transparency, une recherche sur crt.sh étend la liste à tout l’historique du domaine.
Que vérifie l’analyse de chaîne ?
Pour chaque certificat, l’outil compare son émetteur au sujet du suivant, compare les identifiants de clé (AKI et SKI), puis vérifie la signature avec la clé publique du suivant. Il signale une chaîne dans le désordre, un intermédiaire manquant ou une racine envoyée inutilement. Il ne consulte ni magasin de confiance, ni CRL, ni OCSP : un certificat révoqué ou émis par une autorité inconnue passe cette vérification.
J’ai collé une clé privée par erreur, que faire ?
L’outil la détecte sans la décoder ni l’afficher, et rien n’a quitté votre navigateur. Si le même texte a circulé ailleurs (ticket, messagerie, dépôt Git, outil en ligne), considérez la clé comme compromise : générez une nouvelle paire, faites réémettre le certificat et révoquez l’ancien.
Quelle est la durée maximale d’un certificat TLS public ?
Elle dépend de la date d’émission : 398 jours depuis le 1er septembre 2020, puis, avec le ballot SC-081v3 du CA/B Forum adopté en avril 2025, 200 jours depuis le 15 mars 2026, 100 jours à partir du 15 mars 2027 et 47 jours à partir du 15 mars 2029. Une PKI interne n’est pas soumise à ces règles.
+Autres outils
- /24Subnet Calculator
IPv4 et IPv6 : masques, plages et découpage CIDR.
- *-srcCSP Evaluator
Trouvez les contournements d’une Content Security Policy.
- #Hash Lab
Calculez des empreintes et identifiez un format de hash.
Audit technique
Faire vérifier une application ou une infrastructure
Pour une analyse par notre équipe, indiquez les systèmes concernés, les accès disponibles et les tests souhaités dans votre demande.