Démarrage rapide Tarifs

Accueil → Aide

SSL certificate verify failed lors d'un appel à une API IA

Quelque chose entre vous et le fournisseur termine la connexion TLS et la re-signe avec un certificat auquel l'environnement d'exécution de votre langage ne fait pas confiance. Le certificat du fournisseur est correct ; il manque à votre magasin de confiance la racine de l'intercepteur.

Ce que vous voyez

Pourquoi cela arrive

Les proxies d'entreprise, certains antivirus et la plupart des équipements d'inspection VPN déchiffrent le HTTPS pour regarder à l'intérieur, puis émettent leur propre certificat. Les systèmes d'exploitation reçoivent cette racine de manière centralisée ; Python, Node et Go embarquent ou utilisent souvent leur propre magasin de confiance et ne la voient jamais. C'est exactement l'écart où curl réussit et votre code échoue.

L'erreur apparaît aussi sans aucun proxy quand la liste de CA intégrée à un environnement est périmée, typiquement sur une vieille image de conteneur ou une VM de longue durée jamais mise à jour.

Ce n'est pas un problème d'authentification. La requête ne termine jamais la négociation TLS, donc aucune clé n'est envoyée et rien n'atteint les journaux du fournisseur.

Vérifiez si c'est bien la cause

Regardez qui a signé le certificat que vous recevez réellement :

openssl s_client -connect YOUR_DOMAIN:443 -servername YOUR_DOMAIN </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -subject

Si l'émetteur est une CA publique, le magasin de confiance de votre environnement est périmé. S'il porte le nom de votre entreprise, d'un équipement de sécurité ou d'un éditeur d'antivirus, le trafic est intercepté et vous devez installer cette racine là où votre environnement la cherche.

Comment le corriger

  1. Indiquez à l'environnement le bon paquet de CAExportez la racine de l'intercepteur et définissez REQUESTS_CA_BUNDLE ou SSL_CERT_FILE pour Python, NODE_EXTRA_CA_CERTS pour Node. La vérification reste active, et c'est tout l'intérêt.
  2. Mettez à jour les certificats intégrésRéinstallez ou mettez à jour le paquet certifi, ou reconstruisez le conteneur sur une image de base récente. Les paquets périmés échouent face aux certificats intermédiaires plus récents.
  3. Ne désactivez pas la vérificationverify=False et NODE_TLS_REJECT_UNAUTHORIZED=0 font disparaître l'erreur en acceptant n'importe quel certificat, y compris celui de quiconque se trouve sur votre réseau. Or vous envoyez une clé d'API sur cette connexion.
Tout se passe côté client, donc rien dans votre journal d'utilisation APICLAN ne montrera une négociation échouée : la requête n'est jamais arrivée. Un journal vide accompagné d'une erreur TLS est la combinaison attendue, pas un second problème.

Voir aussi

Unexpected token '<' lors d'un appel à une API compatible OpenAI401 invalid API key : quand la clé semble correcte mais échoue quand même

Dernière vérification le 2026-10-01. Rédigé à partir de problèmes diagnostiqués sur une passerelle compatible OpenAI en production, pas compilé à partir d'autres sites.