Visualiseur de certificat X.509

Afficher les détails d’un certificat X.509 depuis un PEM

PEM Certificate

Certificate Details

Paste a PEM certificate to view its details

Le visualiseur de certificats X.509 analyse les certificats SSL/TLS encodés en PEM et affiche le sujet, l'émetteur, la validité, les détails de clé, les extensions et les empreintes dans un format lisible -- le tout traité localement dans votre navigateur sans envoyer les certificats vers des serveurs externes. Collez un bloc -----BEGIN CERTIFICATE-----...-----END CERTIFICATE----- et visualisez instantanément chaque champ décodé.

Comprendre les certificats X.509

Si vous travaillez avec des serveurs web, des load balancers ou tout service utilisant HTTPS, vous manipulez des certificats X.509 en permanence. Un certificat X.509 est essentiellement un document signé numériquement qui lie une clé publique à une identité -- généralement un nom de domaine ou une organisation. Lorsqu'un navigateur se connecte à votre serveur via TLS, il reçoit le certificat, vérifie qu'une autorité de certification de confiance l'a signé et confirme que le domaine dans la barre d'adresse correspond aux noms listés dans le certificat. Si quelque chose ne correspond pas -- mauvais domaine, date expirée, signataire non approuvé -- la connexion échoue et les utilisateurs voient une page d'avertissement.

Le problème est que les certificats sont encodés en ASN.1 DER, un format binaire totalement illisible sans outils. Même l'enveloppe PEM, qui encode les données binaires en base64 et ajoute des lignes d'en-tête et de pied de page, ne vous donne qu'un mur de caractères. Vous ne pouvez pas déterminer en regardant un bloc PEM si le certificat couvre votre domaine, quand il expire ou s'il utilise une clé suffisamment robuste. C'est là qu'un visualiseur de certificats intervient : il décode la structure binaire et présente chaque champ en texte clair afin que vous puissiez vérifier que tout est correct avant le déploiement en production.

Ce visualiseur est particulièrement utile pour les certificats que vous ne pouvez pas ou ne devriez pas téléverser vers des services d'inspection tiers. Les certificats de CA internes, les certificats d'authentification client et les certificats contenant des informations organisationnelles propriétaires méritent tous d'être inspectés dans un outil qui traite tout localement. Collez le texte PEM, examinez la sortie décodée et confirmez que les noms de sujet, les dates de validité, la robustesse de la clé et les extensions correspondent à vos attentes.

Comment visualiser un certificat X.509

  1. Ouvrez l'outil de visualisation de certificats X.509
  2. Collez votre certificat encodé en PEM (commençant par -----BEGIN CERTIFICATE-----)
  3. Le visualiseur analyse et affiche instantanément tous les champs du certificat
  4. Consultez le sujet décodé, l'émetteur, la période de validité, les informations de clé et les extensions
  5. Copiez les empreintes ou les champs spécifiques selon vos besoins

Explication des champs d'un certificat X.509

Sujet et émetteur

Le Sujet (Subject) identifie à qui le certificat a été délivré. L'Émetteur (Issuer) identifie l'Autorité de Certification (CA) qui l'a signé. Les deux utilisent le format Distinguished Name (DN) :

ChampAbréviationExemple
Common NameCNwww.example.com
OrganizationOExample Inc.
Organizational UnitOUIT Department
CountryCUS
State/ProvinceSTCalifornia
LocalityLSan Francisco

Informations sur la clé

Le visualiseur affiche l'algorithme de clé publique et sa robustesse :

  • RSA 2048 bits -- minimum acceptable pour les certificats de production
  • RSA 4096 bits -- sécurité plus élevée, handshakes légèrement plus lents
  • ECDSA P-256 -- équivalent à RSA 3072 bits avec de meilleures performances
  • ECDSA P-384 -- exigé par certains référentiels de conformité

Extensions du certificat

Les certificats modernes reposent sur les extensions pour des fonctionnalités critiques :

  • Subject Alternative Names (SANs) -- tous les noms d'hôte et adresses IP couverts par le certificat
  • Key Usage -- opérations autorisées (digitalSignature, keyEncipherment)
  • Extended Key Usage -- usages spécifiques (serverAuth, clientAuth)
  • Basic Constraints -- indique si le certificat peut signer d'autres certificats (CA:TRUE/FALSE)
  • Authority Information Access -- URL du répondeur OCSP et de l'émetteur CA

Exemple de sortie pour un certificat

Le collage d'un certificat Let's Encrypt typique produit :

Subject:    CN=www.example.com
Issuer:     CN=R3, O=Let's Encrypt, C=US
Not Before: 2025-01-15 00:00:00 UTC
Not After:  2025-04-15 23:59:59 UTC
Serial:     04:A3:2B:9C:...
Algorithm:  RSA 2048-bit
SHA-256:    A1:B2:C3:D4:E5:F6:...
SHA-1:      1A:2B:3C:4D:5E:...

SANs:
  DNS: www.example.com
  DNS: example.com

Quand utiliser cet outil

  • Vérification avant déploiement -- confirmer que le contenu du certificat correspond à votre domaine et à la configuration prévue avant l'installation sur un serveur
  • Dépannage d'erreurs TLS -- inspecter les certificats pour trouver des CN non concordants, des SAN manquants ou des périodes de validité expirées
  • Audits de sécurité -- examiner la robustesse de la clé, l'algorithme de signature et la configuration des extensions sur l'ensemble de votre inventaire de certificats
  • Inspection de la chaîne de certificats -- examiner chaque certificat de la chaîne pour identifier l'entité finale, les CA intermédiaires et la CA racine
  • Gestion de certificats privés -- inspecter les certificats internes ou de CA privée sans les transmettre à des services tiers
  • Réponse aux incidents -- décoder rapidement un certificat suspect provenant d'une capture de paquets ou d'un fichier journal pour évaluer sa légitimité

Fonctionnement des certificats X.509

X.509 est le standard ITU-T définissant le format des certificats à clé publique. Chaque connexion HTTPS repose sur les certificats X.509 pour établir la confiance. Le certificat lie une clé publique à une identité (nom de domaine, organisation) et est signé cryptographiquement par une Autorité de Certification de confiance.

Structure d'un certificat

Un certificat X.509v3 contient les champs de premier niveau suivants :

Certificate:
  Version:            v3 (0x2)
  Serial Number:      identifiant unique attribué par la CA
  Signature Algorithm: ex. sha256WithRSAEncryption
  Issuer:             DN de la CA signataire
  Validity:
    Not Before:       début de la fenêtre de validité
    Not After:        fin de la fenêtre de validité
  Subject:            DN du titulaire du certificat
  Subject Public Key Info:
    Algorithm:        RSA, ECDSA ou Ed25519
    Public Key:       les données de la clé
  Extensions:         SANs, Key Usage, AIA, etc.
  Signature:          signature numérique de la CA sur tous les champs

Formats d'encodage

Les certificats sont encodés au format ASN.1 DER (binaire), puis généralement enveloppés en PEM (base64 avec lignes d'en-tête/pied de page) pour la manipulation humaine. Les marqueurs -----BEGIN CERTIFICATE----- et -----END CERTIFICATE----- délimitent les données DER encodées en base64. Vous pouvez récupérer le certificat d'un serveur au format PEM avec OpenSSL :

openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null

Inspection de certificats en pratique

L'habitude la plus importante lorsque vous travaillez avec des certificats est de les inspecter avant le déploiement. Il suffit de trente secondes pour coller un certificat dans un visualiseur et confirmer que le sujet correspond à votre domaine, que les SAN couvrent tous les noms d'hôtes nécessaires, que les dates de validité sont raisonnables et que l'algorithme de clé répond à vos exigences de sécurité. Sauter cette étape est la raison pour laquelle des équipes se retrouvent à déployer un certificat pour le mauvais domaine ou à oublier une entrée SAN pour un sous-domaine API qui n'est remarquée que lorsque les alertes de monitoring se déclenchent à 2 heures du matin.

Lors du dépannage d'erreurs TLS, commencez par obtenir le certificat que le serveur présente réellement. Exécutez openssl s_client -connect votreserveur.com:443 -servername votreserveur.com et collez la sortie PEM dans ce visualiseur. Comparez les champs décodés avec ce que vous attendez : le CN ou les SAN sont-ils corrects ? Le certificat est-il expiré ? L'émetteur est-il la CA prévue ? De nombreux problèmes TLS qui semblent mystérieux d'après un message d'erreur deviennent évidents lorsque vous voyez les champs réels du certificat côte à côte avec vos attentes.

Pour les organisations gérant des dizaines ou des centaines de certificats, mettre en place une routine d'inspection régulière est précieux. Exportez les certificats de vos serveurs, collez-les dans le visualiseur et vérifiez les expirations à venir, les tailles de clés faibles (RSA 1024 aurait dû être retiré depuis des années) ou les algorithmes de signature obsolètes. Ce type d'audit proactif détecte les problèmes avant qu'ils ne deviennent des pannes.

Questions fréquentes

Quelle est la différence entre CN et SAN dans un certificat ? Le Common Name (CN) est un champ historique du Subject qui contenait traditionnellement le nom de domaine. Les navigateurs modernes utilisent désormais exclusivement les Subject Alternative Names (SANs) pour la validation du hostname. Un certificat avec CN=example.com mais sans entrée SAN correspondante échouera à la validation dans Chrome et Firefox. Assurez-vous toujours que vos domaines apparaissent dans l'extension SAN.

Comment obtenir le texte PEM d'un certificat à inspecter ? Utilisez OpenSSL en ligne de commande : openssl s_client -connect example.com:443 -showcerts affiche les certificats au format PEM. Vous pouvez également les exporter depuis les outils de développement du navigateur (onglet Sécurité), ou trouver les fichiers PEM dans les configurations serveur -- ils ont généralement les extensions .pem, .crt ou .cer.

Ce visualiseur peut-il traiter les chaînes de certificats ? Oui. Si vous collez plusieurs certificats PEM (une chaîne complète), le visualiseur analyse chacun individuellement. Pour découper des chaînes en certificats séparés, utilisez le PEM Bundle Splitter.

Que signifie "CA:TRUE" dans l'extension Basic Constraints ? Un certificat avec CA:TRUE dans ses Basic Constraints est autorisé à signer d'autres certificats -- c'est un certificat d'Autorité de Certification, pas un certificat feuille. Les certificats feuille utilisés par les serveurs web doivent toujours afficher CA:FALSE. Si vous voyez CA:TRUE sur un certificat que vous pensiez être un certificat serveur, il y a un problème dans votre configuration.

Pourquoi mon certificat affiche-t-il un émetteur différent de la CA auprès de laquelle j'ai acheté ? Les autorités de certification utilisent souvent des certificats intermédiaires pour signer les certificats feuille plutôt que de signer directement avec leur racine. Le champ Issuer affiche le nom de la CA intermédiaire, pas celui de la racine. C'est normal et attendu. Vous pouvez tracer la chaîne complète en examinant les champs Subject et Issuer de chaque certificat, du feuille à la racine.

Comment savoir si un certificat utilise une clé suffisamment robuste ? Vérifiez la section Informations sur la clé. Pour RSA, 2048 bits est le minimum actuel ; 4096 bits offre une marge supplémentaire. Pour ECDSA, P-256 (256 bits) offre une sécurité équivalente à RSA 3072 bits. Toute clé RSA inférieure à 2048 bits devrait être remplacée immédiatement, car les CA n'émettront pas de certificats pour des clés plus petites et les navigateurs peuvent les rejeter.

Outils associés

IPparse•Outils de calcul réseau et sous-réseau gratuits

© 2026 IPparse. All tools run locally in your browser.

100% Privacy-First • No Data Collected