L'erreur de certificat qui apparaît après la configuration d'un proxy peut signaler deux choses radicalement différentes : soit une couche d'inspection s'intercale, soit il s'agit d'une simple lacune de configuration. Les distinguer est essentiel pour votre sécurité.
Que devrait-il se passer normalement ?
Dans un tunnel CONNECT correctement configuré, le proxy ne touche jamaisau certificat. La poignée de main TLS s'effectue directement entre le client et le serveur cible ; le proxy ne transporte que des octets chiffrés. Le certificat est donc le véritable certificat du site cible.
Dans ce flux, aucune erreur de certificat n'est attendue. S'il y en a une, soit il y a interception, soit le magasin de certificats du client est incomplet.
Causes des erreurs
La deuxième ligne est un signal d'alerte : si la chaîne contient un certificat auto-signé, votre trafic est peut-être lu.
Comment détecter une SSL inspection ?
Si les valeurs issuer des deux sorties diffèrent, le proxy applique une interception TLS et peut lire votre trafic.
Faire taire l'erreur de certificat avec -k ou verify=False ne résout rien — cela la rend seulement invisible. Cela revient à laisser tout intermédiaire lire votre trafic. À ne jamais utiliser en production.
Les bonnes solutions
Mettez à jour le magasin de certificats racine
C'est la cause la plus fréquente. Sous Linux, update-ca-certificates, en Python, un connecteur personnalisé avec certifi mettez le paquet à jour.
Ajoutez le certificat racine de l'entreprise après vérification
Si vous êtes sur un réseau d'entreprise et que la politique l'exige, ajoutez au magasin de confiance de votre client le certificat racine fourni par votre service informatique. N'ajoutez jamais un certificat téléchargé sur Internet.
Vérifiez l'horloge système
Une horloge système incorrecte fait apparaître des certificats valides comme « expirés ». C'est fréquent sur les machines virtuelles.
Utilisez un canal sans interception TLS
Les applications qui recourent à l'épinglage de certificat n'acceptent pas l'interception. Dans ce cas, il faut passer par les données mobiles ou une connexion directe.
Magasin de certificats propre à chaque application
Toutes les applications n'utilisent pas le magasin de confiance du système. C'est l'explication du fameux « ça marche dans le navigateur mais pas dans mon script » :
| Environnement | Magasin de certificats | Méthode d'ajout |
|---|---|---|
| Outils système Linux | /etc/ssl/certs | update-ca-certificates |
| Python (requests) | paquet certifi | REQUESTS_CA_BUNDLE variable |
| Node.js | Magasin intégré | NODE_EXTRA_CA_CERTS variable |
| Java | keystore cacerts | keytool -import |
| Firefox | Magasin propre | Paramètres → Certificats |
| Chrome | Magasin système | Réglage du système d'exploitation |
Ajouter un certificat à l'échelle du système le rend fiable pour toutes les applications. Ne le faites que pour des certificats dont vous connaissez la provenance avec certitude.
Épinglage de certificat (pinning)
Certaines applications mobiles et clients bancaires épinglent le certificat du serveur à l'intérieur de l'application. Dès qu'ils voient un certificat intercalé, ils refusent la connexion — aucun ajout de certificat racine ne change ce comportement.
C'est la raison de la plainte « l'application ne s'ouvre pas sur le Wi-Fi de l'entreprise, mais s'ouvre en données mobiles ». La seule solution consiste à utiliser, pour cette application, un canal sans interception TLS.
Résumé
Dans un tunnel CONNECT sain, le proxy ne touche pas au certificat ; si vous voyez une erreur, c'est soit que le magasin racine de votre client est incomplet, soit qu'une couche d'inspection s'intercale. Pour distinguer les deux cas, comparez avec une connexion directe la valeur issuer de la chaîne de certificats. Désactiver la vérification n'est pas une solution : cela rend simplement le risque invisible. Pour voir ce que votre connexion laisse réellement fuiter, vous pouvez utiliser test d'anonymat notre outil.