Qu'est-ce qu'un certificat X.509 ?

X.509 en bref#

Un certificat X.509 est un document électronique qui associe une clé publique à une identité : une personne, un serveur, une application. Ce lien est garanti par la signature d’un tiers de confiance, l’autorité de certification (AC).

Vous en utilisez tous les jours sans le voir : le cadenas du navigateur signifie que le site a présenté un certificat X.509 valide pour son nom de domaine. Le même mécanisme fonctionne dans l’autre sens. L’utilisateur peut présenter un certificat au serveur pour prouver qui il est, par exemple avec une carte à puce professionnelle ou un certificat installé sur son poste.

X.509 est une recommandation de l’UIT-T publiée en 1988. Pour Internet, l’IETF en a fixé un profil, la RFC 5280, qui précise les champs, les extensions et la façon de valider un certificat.

Pourquoi s’authentifier par certificat#

Un mot de passe est un secret que l’utilisateur connaît et que le serveur doit vérifier, donc d’une certaine façon connaître aussi. Un certificat renverse la logique :

• la clé privée reste chez l’utilisateur, idéalement dans un composant matériel (carte à puce, jeton USB, puce TPM) d’où elle ne peut pas être extraite ;
• le serveur n’a besoin d’aucun secret : il vérifie une signature avec la clé publique contenue dans le certificat ;
• l’identité est attestée par l’organisation qui a délivré le certificat, et non déclarée par l’utilisateur.

L’authentification par certificat est courante dans les administrations, la santé, la défense et les grandes entreprises, où une carte agent sert à la fois à entrer dans les locaux, à ouvrir sa session et à se connecter aux applications. Elle sert aussi entre machines, quand un service doit prouver son identité à un autre sans intervention humaine.

Les acteurs#

L’anatomie d’un certificat#

Un certificat est une structure ASN.1, encodée en binaire (DER) ou en texte Base64 (PEM, entre les lignes -----BEGIN CERTIFICATE-----). La commande openssl x509 -text en donne une lecture humaine :

Version: 3 (0x2)
Serial Number: 4f:1a:9c:02:7e:b3:55:d1
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=FR, O=Example, CN=Example AC Utilisateurs
Validity
    Not Before: Sep  1 00:00:00 2026 GMT
    Not After : Aug 31 23:59:59 2027 GMT
Subject: C=FR, O=Example, CN=Claire Martin
Subject Public Key Info:
    Public Key Algorithm: id-ecPublicKey (256 bit)
X509v3 extensions:
    X509v3 Basic Constraints: critical
        CA:FALSE
    X509v3 Key Usage: critical
        Digital Signature
    X509v3 Extended Key Usage:
        TLS Web Client Authentication
    X509v3 Subject Alternative Name:
        email:claire.martin@example.fr
    X509v3 CRL Distribution Points:
        URI:http://pki.example.fr/crl/utilisateurs.crl
    Authority Information Access:
        OCSP - URI:http://ocsp.example.fr

La version 3 de X.509, la seule utilisée aujourd’hui, a introduit les extensions. Ce sont elles qui portent l’essentiel des informations utiles à l’authentification.

La chaîne de confiance#

Une partie de confiance ne connaît pas chaque certificat d’utilisateur. Elle fait confiance à quelques autorités racines (trust anchors), et vérifie que le certificat présenté en descend.

La chaîne compte le plus souvent trois niveaux : l’AC racine, conservée hors ligne, signe une ou plusieurs AC intermédiaires, qui signent à leur tour les certificats finaux des utilisateurs. Si une AC intermédiaire est compromise, on la révoque sans toucher à la racine.

La RFC 5280 décrit la validation du chemin de certification. Pour chaque maillon, de la racine vers le certificat final, la partie de confiance vérifie notamment :

• la signature, avec la clé publique du maillon supérieur ;
• la période de validité ;
• la concordance entre l’émetteur d’un certificat et le titulaire du maillon supérieur ;
• que chaque maillon intermédiaire est bien une autorité (CA:TRUE) autorisée à signer des certificats ;
• l’état de révocation, si la politique l’exige.

La révocation#

Un certificat peut devoir être invalidé avant sa date d’expiration : carte perdue, départ d’un agent, clé compromise. Deux mécanismes le permettent.

• La liste de révocation (Certificate Revocation List, CRL), définie par la RFC 5280, est un fichier signé par l’AC qui énumère les numéros de série révoqués. Elle est publiée à intervalles réguliers ; la partie de confiance la télécharge et la garde en cache.
• Le protocole OCSP (Online Certificate Status Protocol, RFC 6960) interroge en temps réel un répondeur qui renvoie l’état d’un certificat précis : good, revoked ou unknown.

Les CRL fonctionnent sans connexion permanente mais peuvent être volumineuses et datées de quelques heures. OCSP donne un état à jour, au prix d’un appel réseau à chaque vérification. Dans les deux cas, la politique doit prévoir quoi faire quand l’état est impossible à obtenir : refuser par prudence ou accepter pour préserver la disponibilité.

L’authentification TLS par certificat client#

L’usage le plus courant d’un certificat pour s’authentifier est le TLS mutuel : pendant la poignée de main TLS, le serveur demande un certificat au client, en plus de présenter le sien.

1. Le serveur envoie un message CertificateRequest, qui peut lister les autorités qu’il accepte. Le navigateur propose alors à l’utilisateur les certificats correspondants.
2. Le client envoie son certificat (Certificate), puis un message CertificateVerify : une signature, faite avec sa clé privée, de l’ensemble des messages échangés jusque-là.
3. Le serveur vérifie cette signature avec la clé publique du certificat. Elle prouve que le client détient la clé privée, et pas seulement une copie du certificat, qui est public.

Dans une architecture web, cette négociation est souvent assurée par un proxy inverse placé devant l’application, qui lui transmet ensuite le certificat du client. C’est le cas avec TOSIAM :

Le même mécanisme sert entre machines. Pour OAuth 2.0, la RFC 8705 l’utilise pour authentifier les clients et lier les jetons à un certificat : voir l’article mTLS.

Relier un certificat à un compte#

Un certificat valide prouve une identité, mais la partie de confiance doit encore trouver le compte correspondant dans son annuaire. Plusieurs stratégies existent :

• lire l’adresse e-mail (rfc822Name) ou l’UPN dans le Subject Alternative Name, puis chercher le compte qui porte cette valeur ;
• lire un élément du DN du titulaire : nom commun (CN), identifiant (UID), ou le DN complet ;
• comparer le certificat entier à celui qui a été enregistré dans le profil de l’utilisateur.

Le choix dépend de ce que l’AC garantit. Un attribut n’est utile comme clé que s’il est unique, stable, et contrôlé par l’AC plutôt que saisi librement lors de la demande de certificat.

Bonnes pratiques#

• Ne faites confiance qu’aux autorités qui émettent vos certificats d’utilisateurs, et non à toutes les AC publiques du web.
• Exigez l’usage clientAuth dans l’Extended Key Usage des certificats utilisés pour s’authentifier.
• Stockez les clés privées dans un composant matériel non exportable (carte à puce, jeton, TPM) chaque fois que possible.
• Vérifiez la révocation par CRL ou OCSP, et décidez explicitement du comportement quand le service de révocation ne répond pas.
• Choisissez des durées de validité raisonnables et automatisez le renouvellement.
• Quand un proxy transmet le certificat dans un en-tête HTTP, supprimez tout en-tête de même nom venant du client, et rendez l’application injoignable sans passer par le proxy.

X.509 dans TOSIAM#

TOSIAM authentifie les utilisateurs par certificat client dans un graphe d’authentification, avec deux nœuds décrits dans Nœuds : certificat / PKI. La négociation TLS mutuelle est confiée à un proxy inverse, par exemple Apache avec mod_ssl, qui transmet le certificat du client à TOSIAM au format PEM dans un en-tête HTTP.

Collecte. CertificateCollectorNode lit cet en-tête, SSL_CLIENT_CERT par défaut (propriété headerName), et place le certificat dans l’état du graphe. Sa sortie absent permet de proposer une autre méthode quand l’utilisateur n’a pas présenté de certificat. Le nœud fait confiance au contenu de l’en-tête : la règle sur les en-têtes transmis par le proxy, donnée plus haut, s’applique pleinement.

Validation. CertificateValidationNode valide le certificat par l’algorithme PKIX de Java, en prenant pour autorités de confiance le magasin de certificats de la JVM (cacerts, ou celui désigné par javax.net.ssl.trustStore). L’autorité qui émet les certificats des utilisateurs doit donc être importée dans ce magasin. La vérification de révocation se règle par deux propriétés, checkCrl et checkOcsp, toutes deux désactivées par défaut. Le nœud a trois sorties : valid, invalid (certificat non reconnu, expiré, mal formé, ou sans compte correspondant) et revoked.

Correspondance avec le compte. Par défaut, le nœud lit l’adresse e-mail dans le Subject Alternative Name (rfc822Name), ou à défaut dans l’attribut E du DN du titulaire. Il cherche ensuite dans l’annuaire le compte dont l’attribut mail porte cette adresse, et en fait l’utilisateur authentifié. La propriété sanExpectedValue permet en plus d’exiger une adresse précise.

Module legacy. Pour les chaînes d’authentification existantes, le module Certificate offre davantage d’options : correspondance du compte par DN, CN (par défaut), UID, adresse e-mail ou un autre champ du certificat, ou par l’adresse e-mail ou l’UPN du Subject Alternative Name ; comparaison avec un certificat stocké dans l’annuaire LDAP ; vérification par CRL, publiées dans l’annuaire ou récupérées depuis les points de distribution, et par OCSP. Il peut aussi limiter aux seules adresses IP de confiance la transmission d’un certificat par en-tête HTTP.

Pour aller plus loin#

• RFC 5280, le profil Internet des certificats X.509 et des CRL
• RFC 6960, le protocole OCSP
• RFC 8446, TLS 1.3 et l’authentification du client
• RFC 8705, l’authentification des clients OAuth 2.0 par TLS mutuel