Validation des certificats dans TLS

Sans validation du certificat, une connexion TLS pourrait être établie avec un attaquant se faisant passer pour le serveur (attaque de l’homme du milieu). La validation du certificat garantit que vous communiquez avec le serveur légitime qui détient la clé privée.

Champs principaux : Sujet (qui possède le certificat), SubjectAltName (noms DNS/adresses IP), Émetteur (CA signataire), Validité (notBefore/notAfter), clé publique, signature. Le navigateur vérifie tous ces champs.

Certificat du serveur → certificat d’une CA intermédiaire → certificat d’une CA racine. La CA racine est auto-signée et préinstallée dans le magasin de confiance de l’OS ou du navigateur. Le serveur envoie son certificat ainsi que les certificats intermédiaires dans le message Certificate de la négociation TLS.

Chaque certificat est signé par l’émetteur situé au-dessus de lui. Le client vérifie : signature(cert_n) à l’aide de public_key(cert_{n+1}). Si une signature est invalide, la chaîne est rejetée. La racine est approuvée grâce à sa préinstallation, et non grâce à sa signature.

Le client vérifie que le nom d’hôte du serveur correspond au champ Subject ou à SubjectAltName du certificat (entrées DNS). Les caractères génériques (*.example.com) correspondent à un seul libellé. Depuis 2000, SAN est prioritaire sur CN pour la correspondance des noms d’hôte.

Le client vérifie notBefore ≤ now ≤ notAfter pour chaque certificat de la chaîne. Les certificats expirés sont rejetés même si leurs signatures sont valides. La durée de validité des certificats a diminué : les navigateurs la limitent désormais à environ 398 jours.

La CA publie une Certificate Revocation List (CRL), c’est-à-dire une liste signée des numéros de série des certificats révoqués. Le client télécharge l’URL de la CRL (depuis l’extension des points de distribution de CRL du certificat) et vérifie si le numéro de série y figure.

Online Certificate Status Protocol (OCSP) permet aux clients d’interroger le répondeur OCSP de la CA sur l’état d’un certificat donné. Cette méthode est plus rapide qu’une CRL, mais ajoute de la latence. L’agrafage OCSP demande au serveur d’inclure une réponse OCSP signée dans la négociation TLS.

CT (RFC 6962) impose aux CA d’enregistrer tous les certificats émis dans des journaux publics auxquels on ne peut qu’ajouter des entrées. Les navigateurs recherchent des horodatages de certificats signés (SCT) dans le certificat ou dans une extension TLS. Cela empêche qu’une émission incorrecte passe inaperçue.

L’épinglage de clé publique HTTP (HPKP, obsolète) et l’épinglage de certificats dans les applications mobiles associent une clé publique ou un hachage de certificat précis. Si le serveur présente un certificat différent, la connexion est rejetée même si celui-ci est valide : cela empêche les attaques exploitant la compromission d’une CA.

ERR_CERT_AUTHORITY_INVALID : racine non approuvée. ERR_CERT_DATE_INVALID : certificat expiré. ERR_CERT_COMMON_NAME_INVALID : nom d’hôte différent. NET::ERR_CERT_REVOKED : OCSP/CRL indique une révocation. Chacune correspond à l’échec d’une étape précise de la validation.

Que permet l’agrafage OCSP ?

La validation des certificats dans TLS comprend la vérification de la chaîne, la vérification des signatures, la correspondance des noms, le contrôle des périodes de validité et la révocation. Ensuite : les attaques historiques contre TLS et la manière dont TLS 1.3 les atténue.