Structure des certificats X.509

Un X.509 certificate est un document numérique standardisé qui associe une clé publique à une identité. La norme X.509 (définie dans la RFC 5280) précise le format, les champs et les extensions utilisés dans les certificats numériques partout dans le monde. Tous les certificats TLS/HTTPS, les certificats de messagerie S/MIME, les certificats de signature de code et les certificats d’authentification client suivent le format X.509. Comprendre la structure d’un X.509 certificate vous aide à lire les informations d’un certificat, à diagnostiquer les erreurs de certificat et à prendre des décisions éclairées concernant le déploiement et la validation des certificats.

Les premiers champs d’un certificat X.509 définissent son identité de base. Version : X.509 v3 est la norme actuelle (v3 a ajouté les extensions). Serial Number : entier unique attribué par la CA émettrice, qui identifie ce certificat précis — il est utilisé dans les CRL (listes de révocation) pour révoquer des certificats individuels. Signature Algorithm : précise l’algorithm utilisé par la CA pour signer le certificat (par exemple, sha256WithRSAEncryption ou ecdsa-with-SHA256). Ce champ apparaît deux fois : une fois dans le TBSCertificate et une fois dans l’enveloppe de signature externe — les deux valeurs doivent correspondre.

Deux des champs les plus importants d’un certificat définissent les parties concernées. Le champ Issuer identifie la CA qui a signé le certificat (par exemple, CN=DigiCert Global CA G2, O=DigiCert Inc, C=US). Le champ Subject identifie l’entité à laquelle le certificat a été délivré (par exemple, CN=*.example.com, O=Example Corp, C=US). Pour un certificat TLS, le Common Name (CN) du Subject ou l’extension Subject Alternative Name (SAN) précise le ou les noms de domaine pour lesquels le certificat est valide. Les navigateurs comparent le nom d’hôte demandé à ces champs.

La période de validité définit la période pendant laquelle le certificat est actif. Elle se compose de deux horodatages : notBefore (le certificat n’est pas encore valide avant cette date) et notAfter (le certificat est expiré après cette date). Les clients TLS vérifient que l’heure actuelle se situe dans cette période. Les certificats présentés en dehors de leur période de validité provoquent une erreur de certificat dans les navigateurs et doivent être renouvelés. La bonne pratique actuelle consiste à émettre des certificats à courte durée de vie (90 jours, comme le fait Let’s Encrypt) afin de limiter l’exposition si une clé privée est compromise entre l’émission et l’expiration.

La charge utile principale du certificat est le champ Subject Public Key Info, qui contient le public key certifié et précise l’algorithm avec lequel il est utilisé. Pour un certificat RSA, ce champ contient le module et l’exposant du public key RSA, ainsi que sa longueur en bits (2048, 4096). Pour un certificat ECC, il contient le nom de la courbe (par exemple, prime256v1) et le point du public key. La CA ne génère pas cette paire de clés : le demandeur du certificat génère sa propre paire de clés et soumet uniquement le public key dans une Certificate Signing Request (CSR).

X.509 v3 a introduit des extensions qui étendent considérablement les fonctionnalités des certificats. Les extensions peuvent être critiques (un client qui ne peut pas traiter cette extension doit rejeter le certificat) ou non critiques (elles peuvent être ignorées si elles ne sont pas comprises). Les principales extensions sont les suivantes : Subject Alternative Name (SAN) — noms de domaine ou adresses IP supplémentaires couverts par le certificat ; Key Usage — limite les opérations pour lesquelles la clé peut être utilisée (signature numérique, chiffrement de clé) ; Extended Key Usage — restreint davantage l’usage prévu (authentification du serveur TLS, authentification du client, signature de code) ; et Basic Constraints — indique si le Subject est une CA.

Historiquement, le champ Common Name (CN) du champ Subject distinctif était utilisé pour le nom de domaine principal. Les certificats modernes utilisent plutôt les Subject Alternative Names (SANs), car les navigateurs ont abandonné la correspondance fondée sur le CN (RFC 2818) au profit des SANs. Les SANs permettent à un seul certificat de couvrir plusieurs domaines (certificats multi-SAN) ou tous les sous-domaines d’un domaine (certificats génériques : *.example.com). Les caractères génériques des SANs ne couvrent qu’un seul niveau : *.example.com couvre www.example.com, mais pas sub.www.example.com.

Deux extensions essentielles indiquent aux clients comment vérifier si un certificat a été révoqué avant sa date d’expiration. CRL Distribution Points (CDP) : contient les URL depuis lesquelles la Certificate Revocation List de la CA peut être téléchargée. Authority Information Access (AIA) : contient l’URL du répondeur OCSP (Online Certificate Status Protocol) de la CA pour effectuer une vérification de révocation en temps réel. Les clients modernes préfèrent OCSP aux téléchargements de CRL, car les CRL peuvent être des fichiers volumineux. La signature numérique de la CA sur les réponses OCSP garantit que les clients reçoivent des informations authentiques sur l’état de révocation.

Les certificats X.509 existent dans plusieurs formats d’encodage que vous rencontrerez en pratique. PEM (Privacy Enhanced Mail) : DER encodé en base64 et entouré d’en-têtes -----BEGIN CERTIFICATE-----. Lisible par l’être humain, il est utilisé sous Linux/Apache/nginx. DER (Distinguished Encoding Rules) : format binaire. Il est utilisé dans les applications Java et certains contextes Windows. PFX/PKCS#12 : format conteneur qui regroupe le certificat, sa chaîne et la clé privée dans un seul fichier protégé par mot de passe. Il est utilisé dans Windows IIS et lors de l’exportation de certificats avec leurs clés privées. P7B/PKCS#7 : chaîne de certificats uniquement, sans clé privée, utilisée dans les magasins de certificats Windows.

Certificate Transparency (CT) est un cadre qui oblige les CA à inscrire tous les certificats émis dans des journaux accessibles pour audit public. Cela permet à n’importe qui de surveiller les certificats non autorisés émis pour ses domaines. Chrome et Safari exigent l’inclusion dans les journaux CT pour les certificats TLS. SCT (Signed Certificate Timestamp) constitue la preuve de cette inclusion dans un journal ; il est intégré au certificat ou transmis via une extension TLS. Les journaux CT révèlent rapidement les émissions incorrectes : si une CA émet par erreur un certificat pour votre domaine, vous le verrez dans des journaux comme crt.sh avant que des attaquants puissent en profiter.

Le dernier composant d’un certificat X.509 est la signature numérique de la CA. La CA calcule le hachage de toutes les données du certificat (TBSCertificate), puis signe ce hachage avec sa propre clé privée. Cette signature rend le certificat digne de confiance : n’importe qui peut la vérifier à l’aide du public key de la CA (présent dans le propre certificat de la CA). L’algorithm de signature utilisé (indiqué dans le champ de signature) doit correspondre à celui spécifié précédemment dans le certificat. Toute modification du certificat après sa signature invalide la signature et garantit ainsi l’intégrité du certificat.

Évaluez votre compréhension des concepts de CompTIA Security+ (SY0-701) abordés dans cette leçon.

Dans cette leçon, vous avez appris qu’un certificat X.509 contient une version, un numéro de série, un émetteur, un sujet, une période de validité, une clé publique et des extensions v3 ; l’extension SAN détermine les noms d’hôte couverts par le certificat ; les extensions CDP et AIA indiquent les points de terminaison utilisés pour vérifier les révocations ; et les journaux CT fournissent des pistes d’audit publiques de l’émission des certificats. Nous allons maintenant étudier le cycle de vie et la révocation des certificats.