Relier une clé à une identité: certificats et PKI

Relier une clé à une identité: certificats et PKI

Une clé publique est un nombre, ou une poignée de nombres. Elle permet de vérifier une signature, mais ne dit rien de son propriétaire : rien, dans ses octets, n’indique qu’elle appartient à une banque plutôt qu’à l’escroc qui l’imite. Le certificat comble ce manque en liant une identité à une clé, sous la signature d’un tiers. La PKI (Public Key Infrastructure, infrastructure de gestion de clés) organise ces tiers, leurs règles et leurs erreurs. Ce chapitre explique comment lire un certificat, comment la chaîne de confiance se construit, et pourquoi elle cède quand on la confond avec une propriété mathématique.

Explication de la marmotte

Une carte d’identité n’a de valeur que parce qu’une mairie reconnue l’a délivrée et que chacun fait confiance à cette mairie. Un certificat joue ce rôle pour les sites et les machines : il atteste qu’un moyen de vérification appartient bien à un nom donné. Ce chapitre explique comment on le lit, qui le délivre, et pourquoi cette confiance cède parfois.

→ Lire l’explication complète de la marmotte

TortueTech

À quoi sert un certificat

Un certificat contient au minimum un sujet (à qui l’on parle : un nom de domaine, un service, une personne), une clé publique, une période de validité, des usages autorisés, et la signature d’un émetteur, l’autorité de certification ou AC. Le client qui reçoit ce document vérifie la signature avec la clé publique de l’émetteur. Or cette clé publique pose la même question que la première : à qui appartient-elle ? Elle figure à son tour dans un certificat, signé par une autorité supérieure, et ainsi de suite jusqu’à une racine, certificat auto-signé que personne ne vérifie, puisqu’on a décidé de lui faire confiance.

Cette décision n’a rien de cryptographique. La racine est présente dans le magasin de confiance du système ou du navigateur, parce qu’un éditeur l’y a installée selon son programme d’admission. La confiance est donc déléguée : l’utilisateur fait confiance à son navigateur, qui fait confiance à quelques dizaines d’autorités racines, qui font confiance à leurs intermédiaires, qui ont vérifié, selon des règles publiques, que le demandeur contrôlait bien le domaine. Chaque maillon peut céder, et le premier est un réglage d’administration.

Lire X.509 sans se noyer

Le format des certificats est X.509, dans sa version 3, profilé pour Internet par la RFC 5280. Le contenu est encodé en ASN.1 (Abstract Syntax Notation One) selon les règles DER (Distinguished Encoding Rules), format binaire. Le format PEM (Privacy-Enhanced Mail, nom hérité d’un projet abandonné) n’est que ce DER encodé en base64 entre deux lignes -----BEGIN CERTIFICATE----- et -----END CERTIFICATE-----. Autour gravitent les normes PKCS (Public-Key Cryptography Standards) : PKCS#1 pour les clés RSA, PKCS#8 pour une clé privée quel que soit l’algorithme, PKCS#10 pour la demande de certificat ou CSR (Certificate Signing Request), PKCS#12 pour un paquet chiffré réunissant clé privée et certificats (fichiers .p12 ou .pfx).

La commande suivante affiche les champs utiles d’un certificat :

openssl x509 -in site.pem -noout -subject -issuer -dates \
  -ext subjectAltName,keyUsage,extendedKeyUsage,basicConstraints

Le Subject décrit le titulaire, l’Issuer l’émetteur ; c’est l’égalité entre l’Issuer d’un certificat et le Subject du suivant qui dessine la chaîne. notBefore et notAfter bornent la validité. L’extension SAN (Subject Alternative Name) liste les noms couverts : DNS:www.exemple.fr, DNS:*.exemple.fr, parfois IP: ou URI:. C’est elle, et elle seule, que les navigateurs consultent pour le nom : le champ CN (Common Name) du sujet est ignoré par Chrome depuis 2017. Un joker *.exemple.fr couvre api.exemple.fr, pas exemple.fr, ni v2.api.exemple.fr.

Key Usage restreint les opérations de la clé : digitalSignature, keyEncipherment, keyCertSign pour une autorité. Extended Key Usage précise le contexte applicatif : serverAuth pour un serveur TLS (Transport Layer Security), clientAuth pour un client, codeSigning. Basic Constraints dit si le certificat appartient à une autorité (CA:TRUE) et limite éventuellement la profondeur de la chaîne sous elle (pathlen). Chaque extension peut enfin être marquée critique : un logiciel qui ne la comprend pas doit alors rejeter le certificat. Oublier ces extensions donne au certificat des pouvoirs flous : des clients laxistes ont déjà accepté qu’un certificat feuille en signe d’autres.

WebPKI opérationnelle

Racines, intermédiaires et chaîne

La WebPKI désigne la PKI publique du Web : autorités soumises aux exigences du CA/Browser Forum et aux programmes de racines de Mozilla, Google, Apple et Microsoft. Les racines restent hors ligne, dans des modules matériels, et signent quelques intermédiaires qui émettent au quotidien. Le serveur doit envoyer son certificat et les intermédiaires ; il n’envoie pas la racine, que le client possède déjà. Un intermédiaire manquant est l’erreur classique du serveur qui « fonctionne dans mon navigateur » : le navigateur avait l’intermédiaire en cache ou savait le télécharger, curl ou une application mobile non.

Pour vérifier une chaîne hors navigateur :

openssl s_client -connect www.exemple.fr:443 -servername www.exemple.fr -showcerts </dev/null
openssl verify -CAfile racine.pem -untrusted intermediaire.pem feuille.pem

La première commande affiche ce que le serveur envoie réellement et termine par Verify return code: 0 (ok) si la chaîne aboutit à une racine connue. La seconde reproduit la vérification avec des fichiers locaux. Le guide Diagnostiquer les erreurs de validation TLS recense les codes d’erreur courants.

Certificate Transparency

Depuis 2018, Chrome exige que les certificats publics soient inscrits dans des journaux CT (Certificate Transparency), registres publics en ajout seul ; le certificat porte la preuve d’inscription, appelée SCT (Signed Certificate Timestamp). Un titulaire peut ainsi surveiller les certificats émis pour ses domaines, par exemple via crt.sh. CT n’empêche pas l’émission : il la rend visible, ce qui suffit à décourager une autorité tentée par la discrétion. Le mécanisme est détaillé dans Certificate Transparency.

Révocation

La révocation retire un certificat avant son expiration : clé compromise, domaine cédé, erreur d’émission. Deux mécanismes existent. La CRL (Certificate Revocation List) est une liste signée des numéros de série révoqués, que le client télécharge. L’OCSP (Online Certificate Status Protocol) interroge l’autorité pour un certificat précis, au prix d’une fuite de vie privée (l’autorité apprend quel site est visité) et d’une dépendance à sa disponibilité. Les navigateurs ont longtemps ignoré les échecs OCSP, ce qui revenait à ne rien vérifier face à un attaquant capable de bloquer la requête. Le mouvement récent va vers les CRL agrégées par les navigateurs (CRLite chez Mozilla) : le CA/Browser Forum a rendu l’OCSP facultatif et les CRL obligatoires, et Let’s Encrypt a arrêté son service OCSP en 2025. La comparaison est développée dans CRL ou OCSP.

Révocation et expiration ne se confondent pas : l’expiration est prévue, inscrite dans le certificat et vérifiée par tous les clients ; la révocation est un événement, et sa vérification dépend du client. D’où la tendance à raccourcir les durées de vie, qui rend la révocation moins décisive : le CA/Browser Forum a adopté en 2025 une réduction progressive de la durée maximale des certificats publics, de 398 jours à 200 jours en mars 2026, puis 100 jours en mars 2027 et 47 jours en mars 2029.

ACME et renouvellement

À ces durées, le renouvellement manuel n’est plus une option, c’est un pari perdu d’avance. Le protocole ACME (Automatic Certificate Management Environment, RFC 8555), popularisé par Let’s Encrypt, automatise la preuve de contrôle du domaine et l’émission. Le client ACME (certbot, acme.sh ou le module du serveur web) répond à un défi : http-01 (fichier publié sous /.well-known/acme-challenge/), dns-01 (enregistrement TXT, seul défi qui permet un joker) ou tls-alpn-01. Let’s Encrypt émet des certificats de 90 jours ; le client les renouvelle typiquement au tiers restant. L’automatisation ne dispense pas de surveiller : un renouvellement qui échoue silencieusement depuis deux mois produit la même panne qu’un oubli humain, avec l’excuse en moins.

PKI privée

mTLS et identité de service

À l’intérieur d’un système d’information, des services s’authentifient mutuellement par mTLS (mutual TLS) : le client présente lui aussi un certificat, et le serveur le vérifie. Il faut pour cela une AC interne, dont la racine n’est installée que sur les machines concernées. Les programmes de racines des navigateurs poussent les autorités publiques vers des hiérarchies dédiées à l’authentification de serveurs, et l’usage clientAuth disparaît progressivement des certificats publics : une PKI de mTLS n’a pas à s’appuyer sur la WebPKI, et ne le devrait pas.

L’identité portée n’est plus un nom de domaine, mais un service. Le cadre SPIFFE (Secure Production Identity Framework For Everyone) normalise cette identité sous la forme d’une URI placée dans le SAN, par exemple spiffe://prod.exemple.fr/ns/paiement/sa/api, et SPIRE, son implémentation de référence, délivre des certificats de quelques heures après avoir attesté la charge de travail. Un certificat mTLS identifie une machine ou un service, jamais la personne qui l’utilise ; l’authentification des utilisateurs reste un sujet distinct. Le détail est dans mTLS.

Atelier : une PKI interne minimale

Une PKI interne raisonnable pour une dizaine de services tient en quelques décisions. Une racine hors ligne, valable dix ans, dont la clé est conservée dans un module matériel ou au minimum chiffrée hors réseau, et qui ne sert qu’à signer un intermédiaire. Un intermédiaire en ligne, contraint par pathlen:0 et si possible par l’extension Name Constraints, qui limite les noms qu’il peut certifier (par exemple .interne.exemple.fr). Une racine distincte par environnement : un certificat de recette ne doit jamais être accepté en production. Des certificats feuilles courts, de quelques jours à quelques semaines, émis automatiquement par ACME interne ou par l’orchestrateur, avec extendedKeyUsage explicite. La génération d’une demande illustre le point de départ :

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes \
  -keyout api.key -out api.csr -subj "/CN=api.interne.exemple.fr" \
  -addext "subjectAltName=DNS:api.interne.exemple.fr"

Reste la distribution de la racine : c’est elle qui fonde tout. Un certificat auto-signé accepté « parce qu’il faut bien que ça marche », sans canal sûr pour l’installer, accepte du même coup celui de n’importe quel intermédiaire réseau. La mise en œuvre est développée dans Autorité de certification privée interne.

Rotation et épinglage prudent

L’épinglage (pinning) fige dans le client la clé ou l’autorité attendue. Il protège contre une autorité compromise, et casse l’application au premier renouvellement imprévu. Le mécanisme HPKP (HTTP Public Key Pinning) a d’ailleurs été retiré des navigateurs en 2018, des sites s’étant rendus inaccessibles à eux-mêmes. Épingler sans plan de rotation, c’est-à-dire sans clé de secours déjà publiée et sans procédure de mise à jour du client, est une panne programmée. Si l’on épingle, on épingle la clé publique d’une autorité ou d’un intermédiaire, avec au moins une clé de réserve ; voir les risques opérationnels du pinning.

Diagnostiquer une erreur de SAN

Une application appelle https://api.exemple.fr et obtient dans curl SSL: no alternative certificate subject name matches target host name, ou dans Chrome NET::ERR_CERT_COMMON_NAME_INVALID. La démarche : récupérer le certificat réellement servi avec openssl s_client -servername api.exemple.fr, puis lister ses SAN. Trois causes reviennent. Le nom manque dans le SAN, souvent parce qu’il n’était présent que dans le CN. Le serveur sert un autre certificat parce que l’indication de nom (SNI, Server Name Indication) n’est pas envoyée ou pas reconnue, et c’est le certificat par défaut qui répond. Ou le joker ne couvre pas le niveau demandé. Aucune ne se corrige en désactivant la vérification, remède si répandu qu’il mériterait sa propre fiche de vulnérabilité.

Où les PKI échouent

Une autorité compromise peut émettre pour n’importe quel nom : DigiNotar, en 2011, a émis de faux certificats pour Google, utilisés pour intercepter des utilisateurs, et a été retirée de tous les magasins avant de faire faillite. Un serveur compromis livre sa clé privée, et seule la révocation, puis l’expiration, en limitent l’usage. Un client compromis se voit ajouter une racine dans son magasin, et tout devient légitime à ses yeux. Enfin, les erreurs TLS les plus fréquentes ne viennent d’aucune attaque : chaîne incomplète, nom absent, certificat expiré, horloge du client décalée.

À ne pas confondre

Un certificat n’est pas une clé publique : il contient une clé publique, plus une identité et une signature qui les lient. Une autorité de certification n’est pas une autorité applicative : elle atteste qu’une clé appartient à un nom, pas que son titulaire a le droit de faire quoi que ce soit dans une application. La révocation n’est pas l’expiration. Et le mTLS n’authentifie pas un utilisateur : il authentifie la machine ou le service qui détient la clé.

🐝 Ce qui arrive si on s’en passe

Sans chaîne de confiance correctement vérifiée, une clé publique n’est qu’une clé, et celui qui la présente peut prétendre être n’importe qui. Un client qui accepte un certificat auto-signé distribué sans canal sûr accepte du même coup celui que glissera un intermédiaire sur le réseau. Un magasin de racines que personne n’administre conserve des autorités dont nul ne sait plus pourquoi elles y figurent, chacune capable d’émettre pour n’importe quel nom. Et un renouvellement manuel oublié ne compromet rien, mais coupe le service à la date exacte inscrite depuis des mois dans le certificat, que tout le monde pouvait lire et que personne n’a lue.

🦫 Explication de la marmotte 🍫

Une clé publique permet de vérifier une signature ou d’établir une connexion chiffrée, mais elle ne dit pas à qui elle appartient. Un certificat ajoute cette information : c’est un document électronique qui contient un nom, par exemple un nom de domaine, une clé publique, une période de validité et les usages autorisés, le tout signé par une autorité de certification. Pour vérifier un site, le navigateur remonte une chaîne : le certificat du site est signé par une autorité intermédiaire, elle-même signée par une autorité racine. Les racines de confiance sont préinstallées dans le magasin de la machine qui vérifie ; la confiance ne se démontre donc pas, elle se configure. Le navigateur contrôle aussi les dates, la présence du nom demandé dans la liste des noms du certificat, et les usages permis. Les certificats publics sont inscrits dans des journaux publics, ce qui permet de repérer ceux émis par erreur. Pour retirer un certificat avant sa fin, il existe des listes de révocation et des services de consultation. Le renouvellement est souvent automatisé par un protocole appelé ACME. Dans une entreprise, une autorité interne peut délivrer des certificats aux services pour qu’ils s’identifient mutuellement. Les échecs viennent d’une autorité compromise, d’un certificat auto-signé accepté sans précaution, d’un renouvellement oublié, ou d’un épinglage, qui fige la clé attendue, sans plan de changement.

À lire aussi

• Cycle de vie d'une autorité de certification intermédiaireÉmettre, renouveler et révoquer en cascade une autorité de certification intermédiaire, avec les extensions, les échéances et les pièges d'exploitation qui font tomber une PKI entière.
• Gestion du cycle de vie des certificats à grande échelleMettre en place une gestion complète du cycle de vie des certificats pour découvrir, renouveler, déployer et superviser des milliers de certificats.
• PKI expliqueePoint d'ancrage editorial pour introduire la chaine de confiance, les certificats et les autorites de certification.
• Quels risques pour un certificat wildcard TLSLes certificats wildcard couvrent plusieurs sous-domaines mais concentrent le risque de compromission et compliquent la révocation, l'exploitation et le cloisonnement.

Pages voisines

La citent

• PKI expliquee
• Courbes elliptiques : compacité, validation et pièges
• Créer, vérifier et utiliser les clés dès le départ
• Du chiffre manuel au chiffrement moderne
• Messageries, courrier sécurisé et groupes chiffrés

Relier une clé à une identité: certificats et PKI

Elle cite

• Diagnostiquer les erreurs de validation TLS en production
• Certificate pinning : risques et rotation des certificats
• Construire une autorité de certification privée interne
• CRL ou OCSP pour révoquer un certificat
• Extensions X.509 v3 Key Usage EKU et Basic Constraints
• Pourquoi un certificat diffère selon le navigateur
• Sécuriser la validation de domaine HTTP-01 et DNS-01