Un certificat SSL/TLS est ce qui permet à un navigateur de vérifier l'identité d'un site et de chiffrer la connexion. Ce guide explique sa structure, ce que contient chaque champ, et comment le lire sans jargon excessif.
X.509 est le standard qui définit la structure d'un certificat numérique. Un certificat lie une identité (un nom de domaine, une organisation) à une clé publique, et porte la signature numérique d'une autorité qui certifie ce lien. Concrètement, il répond à la question "ce serveur est-il bien celui qu'il prétend être ?" lors d'une connexion HTTPS.
Le format de stockage le plus courant est PEM : du texte encodé en Base64, encadré par -----BEGIN CERTIFICATE----- et -----END CERTIFICATE-----. C'est ce format que tu peux coller dans l'outil de cette page.
| Champ | Rôle |
|---|---|
| Sujet (Subject) | L'identité couverte par le certificat — généralement le nom de domaine principal (CN) et l'organisation. |
| Émetteur (Issuer) | L'autorité qui a signé et délivré ce certificat. |
| Validité | La période durant laquelle le certificat est considéré valide (notBefore / notAfter). |
| Numéro de série | Identifiant unique attribué par l'émetteur, utilisé notamment pour la révocation. |
| Clé publique | La clé cryptographique associée au certificat (RSA ou EC), utilisée pour établir la connexion chiffrée. |
| Signature | La preuve cryptographique que l'émetteur a bien validé et signé ce certificat. |
Le champ SAN liste tous les noms de domaine (et parfois adresses IP) couverts par le certificat — c'est lui que le navigateur vérifie réellement aujourd'hui pour valider qu'un certificat correspond au domaine visité, bien plus que le champ CN historique.
Un certificat avec*.example.comdans son SAN est un certificat "wildcard" : il couvre tous les sous-domaines de premier niveau (www.example.com,api.example.com...), mais pasexample.comlui-même ni les sous-domaines de second niveau (a.b.example.com) — une nuance fréquemment source de confusion.
Un certificat de site n'est presque jamais auto-suffisant : il est signé par un certificat intermédiaire, lui-même signé par un certificat racine (root CA) préinstallé et reconnu de confiance par les navigateurs et systèmes d'exploitation. Cette chaîne (certificat → intermédiaire → racine) doit être complète et valide pour que la connexion soit acceptée sans avertissement.
Un serveur mal configuré qui n'envoie que son certificat final sans les intermédiaires provoque des erreurs de confiance sur certains navigateurs ou clients, même si le certificat lui-même est parfaitement valide.
Un certificat auto-signé est signé par sa propre clé privée plutôt que par une autorité tierce — son sujet et son émetteur sont identiques. Il permet de chiffrer une connexion tout aussi efficacement qu'un certificat "normal", mais ne prouve rien sur l'identité du serveur puisque n'importe qui peut en générer un pour n'importe quel nom : c'est pourquoi les navigateurs affichent un avertissement de sécurité face à un certificat auto-signé non explicitement approuvé par l'utilisateur.
Les certificats auto-signés restent légitimes pour des usages internes (environnements de test, communication entre services internes d'une infrastructure) où l'identité est vérifiée par un autre moyen.
L'empreinte (fingerprint) d'un certificat est un hash (SHA-256 ou SHA-1) calculé sur l'intégralité du certificat encodé. Elle permet de vérifier rapidement, sans comparer tout le contenu, que deux certificats sont strictement identiques — utile pour confirmer qu'un certificat déployé correspond bien à celui attendu, ou pour l'épinglage de certificat (certificate pinning).
Utiliser le décodeur de certificat SSL →DV (Domain Validated) ne vérifie que la propriété du domaine — le plus courant et automatisable (ex: Let's Encrypt). OV (Organization Validated) vérifie en plus l'existence légale de l'organisation. EV (Extended Validation) impose une vérification encore plus poussée, mais n'apporte plus d'indicateur visuel distinct dans les navigateurs modernes.
C'est un choix délibéré de Let's Encrypt pour encourager l'automatisation du renouvellement plutôt qu'une gestion manuelle, réduisant ainsi le risque de certificats expirés non détectés à temps.
Non — il décode et affiche le contenu du certificat, mais ne vérifie ni sa chaîne de confiance, ni sa révocation (CRL/OCSP), ni sa correspondance avec une clé privée. Pour une vérification complète, utilise des outils dédiés comme openssl verify ou un service de test SSL en ligne.
Non, cet outil est spécifiquement conçu pour les certificats X.509 (-----BEGIN CERTIFICATE-----). Les clés privées et CSR utilisent une structure ASN.1 différente.
Outils similaires