Validation du chemin de certification

Portail > La chaîne de certification

La validation du chemin (path validation, RFC 5280 §6) vérifie qu'un chemin candidat — assemblé lors de la construction — est réellement digne de confiance. Elle examine chaque maillon, de la racine vers la feuille, selon une série de contrôles.

Principe

À partir d'une ancre de confiance reconnue, on descend la chaîne maillon par maillon. À chaque étape, la clé publique du maillon courant sert à vérifier le maillon suivant, et un ensemble de contraintes est contrôlé. Si tous les maillons passent, le chemin est valide.

Contrôles effectués sur chaque maillon

Contrôle	Question posée
Signature	La signature du certificat est-elle valide avec la clé publique de son parent ? (Signatures numériques et fonctions de hachage)
Validité temporelle	L'instant courant est-il entre notBefore et notAfter ?
Chaînage	Le issuer correspond-il au subject du parent (et AKI↔SKI) ?
Basic Constraints	Les maillons intermédiaires portent-ils CA:TRUE ? Le pathlen est-il respecté ? (Contraintes de chemin)
Key Usage	Les CA portent-elles keyCertSign ? La feuille a-t-elle les usages requis ?
Extended Key Usage	L'EKU est-il cohérent le long de la chaîne (ex. serverAuth) ?
Name Constraints	Le sujet/SAN respecte-t-il les sous-arbres permis/exclus imposés par une CA ? (Contraintes de chemin)
Extensions critiques	Toute extension marquée critique est-elle comprise et satisfaite ?
Révocation	Le certificat est-il absent des CRL/OCSP applicables ?

Ancre de confiance : le point d'arrêt

La validation ne « réussit » que si le chemin se termine sur une ancre présente dans le magasin de confiance du vérificateur. La signature de la racine elle-même n'est pas « vérifiée par un parent » : c'est sa présence dans le magasin qui fait foi. D'où l'erreur récurrente « unable to get local issuer certificate » quand la racine n'y est pas.

Vérification du nom (côté application)

La validation de chemin RFC 5280 ne vérifie pas que le certificat correspond au serveur contacté. Cette étape est faite par l'application (TLS) : le nom d'hôte demandé doit figurer dans le SAN de la feuille. Une chaîne parfaitement valide pour un mauvais nom doit être rejetée. C'est une vérification distincte mais indispensable.

Ordre logique des vérifications

1. Construire le chemin jusqu'à une ancre de confiance.
2. Pour chaque maillon : signature, dates, chaînage, contraintes (Basic Constraints, Key Usage/EKU, Name Constraints), extensions critiques.
3. Vérifier la révocation des maillons concernés.
4. (Application) vérifier la correspondance du nom (SAN) pour la feuille.

L'échec d'un seul contrôle, sur un seul maillon, invalide l'ensemble.

Vérifier en pratique

# Validation complète d'une feuille avec intermédiaires et racine
openssl verify -CAfile racine.pem -untrusted intermediaires.pem feuille.pem

# Avec contrôle de révocation OCSP/CRL selon les outils, ou via s_client
openssl s_client -connect clipsy.tech:443 -servername clipsy.tech \
        -verify_return_error -status </dev/null

Messages fréquents : certificate has expired (dates), unable to get local issuer certificate (intermédiaire ou racine manquant), self-signed certificate in certificate chain (racine interne non installée), certificate verify failed (échec d'un contrôle). Voir Dépannage des chaînes de certificats.

Points clés à retenir

• Construire d'abord, valider ensuite : la validation contrôle chaque maillon de la racine à la feuille.
• Contrôles : signature, dates, chaînage, Basic Constraints/pathlen, Key Usage/EKU, Name Constraints, extensions critiques, révocation.
• La racine est crue par présence dans le magasin, non par signature.
• La correspondance du nom (SAN ↔ hôte) est une vérification applicative séparée, tout aussi obligatoire.
• Un seul contrôle en échec invalide toute la chaîne.

Voir aussi

• Construction du chemin de certification
• Contraintes de chemin
• Révocation des certificats
• Dépannage des chaînes de certificats