Erreurs de vérification TLS selon les outils : unknown authority, CERTIFICATE_VERIFY_FAILED, certificat auto-signé dans la chaîne

Ce que c'est

Plusieurs clients TLS décrivent, chacun avec son propre vocabulaire, le même échec sous-jacent : ils n'ont pas réussi à construire une chaîne reliant le certificat du serveur à un certificat auquel ils font déjà confiance. Le paquet crypto/x509 de Go signale x509: certificate signed by unknown authority (depuis Go 1.20, le message est précédé de tls: failed to verify certificate:). Le module ssl de Python, qui s'appuie sur OpenSSL, lève [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate, une erreur documentée dans la référence du module. curl affiche curl: (60) SSL certificate problem: suivi de unable to get local issuer certificate ou de self-signed certificate in certificate chain, selon l'endroit exact où la chaîne est rompue, comme le décrit la documentation de curl sur les problèmes de certificats SSL ; OpenSSL 1.1.1 écrit ce dernier message self signed. Node.js et openssl s_client signalent par unable to verify the first certificate une chaîne réduite au seul certificat feuille et émise par une autorité inconnue.

Pourquoi c'est important

Le libellé donne une indication sur la cause racine, mais ne l'identifie pas de façon fiable, et procéder par supposition fait perdre du temps : un certificat intermédiaire manquant est une erreur de configuration du serveur ; une racine auto-signée en bout de chaîne correspond soit à une autorité de certification privée légitime, soit, dans de rares cas, à une interception en cours ; et désactiver la vérification ne résout ni l'un ni l'autre.

Comment l'appliquer

• Diagnostiquer d'abord : openssl s_client -connect host:443 -servername host </dev/null, documenté dans la page de manuel s_client d'OpenSSL, affiche la chaîne de certificats envoyée par le serveur (ajoutez -showcerts pour obtenir les blocs PEM complets) et, à la fin, une ligne Verify return code:. Si la chaîne s'arrête au certificat feuille, sans intermédiaire, le serveur n'envoie pas son lot de certificats intermédiaires. Si les champs émetteur et sujet du dernier certificat sont identiques, la chaîne se termine par un certificat auto-signé : soit votre propre autorité privée ou interne, que le client ne reconnaît pas encore, soit, si vous ne vous attendiez pas du tout à une racine auto-signée, un signe que le trafic est peut-être intercepté.
• Corrections, de la moins à la plus invasive :
  1. Intermédiaire manquant avec une autorité par ailleurs publique : corrigez le lot de certificats du serveur pour qu'il contienne la chaîne complète ; ce n'est pas un problème côté client.
  2. Autorité privée ou interne (fréquent derrière des proxys d'entreprise et sur certains runners de CI) : installez cette autorité dans le magasin de confiance que l'outil en échec lit réellement, car le cacerts de Java, le bundle certifi de Python, le magasin propre à Node et le magasin système de curl/OpenSSL sont tous distincts.
  3. Si la chaîne a changé de façon inattendue et qu'une interception est soupçonnée, traitez-le comme un événement de sécurité : vérifiez le certificat par un canal indépendant avant de poursuivre, et non en désactivant le contrôle.
• À proscrire : curl -k/--insecure, verify=False de Python, NODE_TLS_REJECT_UNAUTHORIZED=0 ou git -c http.sslVerify=false. Chacun désactive précisément le contrôle qui détecterait une véritable attaque de l'homme du milieu, et aucun ne doit devenir une solution permanente.

Pièges

• Corriger le magasin de confiance d'un outil (celui du système) alors qu'un autre outil (une JVM, un venv Python) conserve son propre bundle et continue d'échouer.
• Considérer une interception temporaire (un proxy d'entreprise qui inspecte le TLS) comme une autorisation de désactiver la vérification partout, au lieu de faire confiance uniquement à l'autorité propre à ce proxy.