Comment un client valide-t-il une chaîne de certificats jusqu'à une racine de confiance ?
Réponse courte
Le client construit une chaîne du certificat serveur (feuille) en remontant par une ou plusieurs autorités de certification intermédiaires jusqu'à une autorité racine de son magasin de confiance. Il vérifie la signature de chaque certificat avec la clé publique de l'émetteur suivant, contrôle les dates de validité, la correspondance du nom/nom d'hôte, l'usage de la clé et la révocation (CRL/OCSP). La confiance se termine à une racine auto-signée pré-approuvée ; la chaîne n'est valide que si chaque maillon est correct.
C'est une question de niveau senior car la validation de chaîne est l'endroit où se logent beaucoup de pannes et mauvaises configurations TLS du monde réel. Le recruteur veut voir que vous comprenez que la confiance est transitive et ancrée, pas magique.
La chaîne de confiance
Un serveur présente un certificat feuille pour son nom d'hôte. Cette feuille est signée par une autorité de certification intermédiaire, elle-même signée par une autorité racine. La racine est auto-signée et réside dans le magasin de confiance du client (livré avec le système d'exploitation ou le navigateur). La validation fonctionne vers le haut : chaque certificat est vérifié à l'aide de la clé publique du certificat au-dessus de lui, jusqu'à atteindre une racine à laquelle vous faites déjà confiance. Si la chaîne ne se termine pas à une racine de confiance, la validation échoue.
Les racines signent les intermédiaires plutôt que les feuilles directement afin que la précieuse clé privée racine puisse rester hors ligne ; si un intermédiaire est compromis, il peut être révoqué sans brûler la racine.
Ce qui est vérifié à chaque maillon
- Signature — la clé publique de l'émetteur vérifie-t-elle la signature de ce certificat ?
- Dates de validité — le certificat est-il dans sa fenêtre not-before/not-after ?
- Correspondance du nom — le sujet/SAN de la feuille correspond-il au nom d'hôte demandé par le client ?
- Usage de la clé / contraintes — chaque autorité est-elle réellement autorisée à émettre (contraintes de base, longueur de chemin) ?
- Révocation — a-t-il été révoqué, via une CRL ou une requête OCSP ? L'agrafage OCSP permet au serveur de présenter un statut signé récent pour éviter un aller-retour côté client.
Modes de défaillance courants
La rupture la plus fréquente du monde réel est un intermédiaire manquant : le serveur n'envoie que la feuille, donc les clients qui n'ont pas l'intermédiaire en cache ne peuvent pas construire un chemin vers la racine. D'autres incluent des certificats expirés, des incohérences de nom d'hôte et des racines non approuvées (auto-signées ou privées).
Ce que recherchent les recruteurs
La remontée vers une racine auto-signée pré-approuvée ; la vérification de signature à chaque saut ; les contrôles de validité/nom d'hôte/révocation ; et la conscience de la raison d'être des intermédiaires et de la manière dont un intermédiaire manquant casse la chaîne.
Questions de suivi probables
- Pourquoi les autorités émettent-elles à partir de certificats intermédiaires plutôt que de signer directement avec la racine ?
- Quelle est la différence entre CRL et OCSP, et qu'est-ce que l'agrafage OCSP ?
- Que se passe-t-il si le serveur omet un certificat intermédiaire de la chaîne ?