Pour chaque certificat, en partant de l’ancre, un validateur contrôle que la signature se vérifie avec la clé de l’émetteur, que l’heure actuelle se situe entre notBefore et notAfter, que le nom de l’émetteur correspond au sujet du certificat précédent, que le certificat n’est pas révoqué, que basicConstraints et l’utilisation de la clé autorisent la signature de certificats, que les contraintes de noms sont respectées et que chaque extension critique est reconnue. Le traitement des politiques ajoute des contrôles de politiques de certificat, que peu d’applications utilisent. L’application vérifie ensuite le certificat d’entité finale par rapport au nom qu’elle voulait joindre (RFC 9525) et à l’utilisation étendue de la clé requise.
La construction du chemin vient d’abord : avec des signatures croisées et plusieurs intermédiaires, le client doit chercher un chemin quelconque qui aboutit à une racine de confiance, et les bibliothèques ne cherchent pas toutes aussi bien. Beaucoup d’échecs TLS qui diffèrent d’une bibliothèque à l’autre sont des échecs de construction du chemin, pas de validation.
Utilisez le vérificateur de la plateforme ou une bibliothèque maintenue plutôt que des contrôles écrits à la main ; l’absence de vérification des contraintes de base ou de l’EKU est à l’origine de nombreuses falsifications de certificats.