La norme X.509 expliquée

X.509 est la norme internationale qui définit le format des certificats numériques. Chaque certificat TLS, chaque certificat de signature de code et chaque certificat d'authentification client que vous rencontrez suit cette spécification. Comprendre X.509, c'est comprendre la langue de la confiance numérique.

Vue d'ensemble

X.509 est une norme initialement définie par l'UIT-T (Union internationale des télécommunications, secteur de la normalisation des télécommunications) dans le cadre du référentiel de services d'annuaire X.500. Publiée pour la première fois en 1988, elle visait à l'origine à associer des clés publiques aux entrées d'annuaire dans les systèmes de télécommunications mondiaux. Au fil des décennies, X.509 a largement dépassé son périmètre initial pour devenir le format universel des certificats numériques dans l'infrastructure à clé publique.

Aujourd'hui, la norme X.509 (formalisée par l'IETF dans la RFC 5280) régit la structure de chaque certificat utilisé en TLS/SSL, S/MIME, signature de code et authentification client. Quand votre navigateur valide l'identité d'un site web, il analyse un certificat X.509. Quand un serveur authentifie un client via mTLS, il lit des champs X.509. La norme définit non seulement les informations qu'un certificat contient, mais aussi la manière dont ces informations sont encodées, signées et validées.

Comprendre X.509 est essentiel pour quiconque travaille avec une PKI. Cela explique pourquoi les certificats ont l'allure qu'ils ont, ce que signifie chaque champ et comment les extensions apportent de la flexibilité à une structure autrement rigide. Ce chapitre décompose la norme en ses composants clés afin que vous puissiez lire, interpréter et diagnostiquer les certificats avec assurance.

Étapes clés

Key Usage

Définit les opérations cryptographiques que la clé du certificat est autorisée à effectuer. Les valeurs courantes incluent `digitalSignature`, `keyEncipherment`, `keyCertSign` et `cRLSign`. Par exemple, un certificat de CA a besoin de `keyCertSign` pour émettre d'autres certificats, tandis qu'un certificat de serveur TLS porte typiquement `digitalSignature` et `keyEncipherment`. Cette extension est presque toujours marquée comme critique.

Extended Key Usage (EKU)

Fournit une définition plus fine de l'usage du certificat. Là où Key Usage définit des opérations de bas niveau, EKU correspond à des cas d'usage concrets : `serverAuth` pour les serveurs TLS, `clientAuth` pour le TLS mutuel, `codeSigning` pour les éditeurs de logiciels et `emailProtection` pour S/MIME. Un certificat avec `serverAuth` ne peut pas servir à signer du code, même si le type de clé le permettrait techniquement.

Subject Alternative Name (SAN)

Liste les identités pour lesquelles le certificat est valide, au-delà de ce que précise le champ Subject. Pour les certificats TLS, le SAN contient typiquement des noms DNS (comme `www.example.com` et `example.com`), mais il peut aussi inclure des adresses IP, des adresses e-mail et des URI. Les navigateurs modernes s'appuient sur le SAN plutôt que sur le champ CN du Subject pour la validation du nom d'hôte, ce qui rend cette extension essentielle pour tout certificat TLS.

Basic Constraints

Indique si le certificat appartient à une CA ou à une entité finale. Lorsque `cA: TRUE`, le certificat est autorisé à émettre d'autres certificats. Le champ optionnel `pathLenConstraint` limite le nombre de CA intermédiaires qui peuvent exister en dessous de celle-ci dans la chaîne. Cette extension est critique : sans elle correctement configurée, un certificat d'entité finale compromis pourrait théoriquement servir à forger de nouveaux certificats.

CRL Distribution Points

Indique les URL où la partie utilisatrice peut télécharger la Certificate Revocation List (CRL) publiée par la CA émettrice. Lorsqu'un client doit vérifier si un certificat a été révoqué, il récupère la CRL à l'emplacement indiqué dans cette extension et y recherche le numéro de série du certificat.

Authority Information Access (AIA)

Fournit deux URL importantes : l'adresse du répondeur OCSP (pour la vérification de révocation en temps réel) et l'URL de la CA émettrice (où le certificat de CA intermédiaire peut être téléchargé). AIA permet à un client de construire dynamiquement la chaîne de confiance complète, même quand le serveur ne présente que son propre certificat.

Composants clés

Version

Indique la version de X.509 utilisée par le certificat. La quasi-totalité des certificats actuels sont en version 3 (v3), qui a introduit le mécanisme des extensions qui rend la PKI moderne possible.

Numéro de série

Un entier unique attribué par la CA émettrice. La combinaison du nom de l'émetteur et du numéro de série doit être unique au niveau mondial. Elle sert également à identifier les certificats dans les listes de révocation.

Algorithme de signature

Spécifie l'algorithme cryptographique utilisé par la CA pour signer le certificat (par exemple SHA-256 avec RSA, ou ECDSA avec SHA-384). Ce champ apparaît deux fois : dans la partie TBS (`to-be-signed`) et à côté de la signature proprement dite.

Émetteur

Un Distinguished Name (DN) identifiant la CA qui a émis et signé le certificat. Ce champ est essentiel pour reconstruire la chaîne de certificats jusqu'à une racine de confiance.

Période de validité

Deux horodatages, `notBefore` et `notAfter`, qui définissent quand le certificat devient valide et quand il expire. Les parties utilisatrices doivent rejeter les certificats hors de cette fenêtre.

Sujet

Un Distinguished Name identifiant l'entité à qui le certificat a été émis. Pour un certificat TLS, il inclut typiquement le nom de domaine. Pour une organisation, il inclut le nom de l'entreprise, le pays et l'unité organisationnelle.

Subject Public Key Info

Contient la clé publique du sujet et identifie l'algorithme qu'elle utilise (RSA, ECDSA, Ed25519, etc.). C'est la clé qui servira au chiffrement ou à la vérification de signature dans les protocoles qui s'appuient sur le certificat.

Extensions (v3)

Champs optionnels introduits en version 3 qui ajoutent des contraintes et des métadonnées. Les extensions peuvent être marquées comme critiques (la partie utilisatrice doit les comprendre) ou non critiques (elles peuvent être ignorées sans risque si elles ne sont pas reconnues).

Evertrust & La norme X.509 expliquée

Visibilité X.509 complète — Evertrust CLM analyse chaque champ et chaque extension de vos certificats, vous offrant une vue claire et interrogeable des sujets, SAN, usages de clé, périodes de validité et relations de chaîne, à travers toute votre infrastructure.

Application de politiques sur le contenu des certificats — Définissez des règles sur les algorithmes de clé autorisés, les tailles de clé minimales, les extensions obligatoires et les conventions de nommage. Evertrust signale les certificats non conformes avant qu'ils n'atteignent la production, garantissant que chaque certificat X.509 de votre environnement respecte vos standards.

Gestion indépendante du format — Que vos équipes travaillent avec PEM, DER, PKCS#7 ou PKCS#12, Evertrust CLM prend en charge l'import, la conversion et la distribution des certificats dans n'importe quel format d'encodage standard.

Émission de certificats conformes aux normes — Evertrust PKI émet des certificats X.509 v3 avec des extensions précisément configurées, garantissant que votre hiérarchie de CA, vos usages de clé et vos contraintes respectent les bonnes pratiques du secteur et vos exigences de conformité spécifiques.

PKI

CLM

Cas d'usage

Secteurs

Conformité

Apprendre

Outils & Analyses

Événements & Communauté