Home → Assistenza

SSL certificate verify failed chiamando un'API di IA

Qualcosa tra te e il provider termina la connessione TLS e la rifirma con un certificato di cui l'ambiente di esecuzione del tuo linguaggio non si fida. Il certificato del provider va bene; al tuo archivio di fiducia manca la radice dell'intercettatore.

Cosa vedi

Perché succede

I proxy aziendali, alcuni antivirus e la maggior parte dei dispositivi di ispezione VPN decifrano l'HTTPS per guardarci dentro, poi emettono un proprio certificato. I sistemi operativi ricevono quella radice installata centralmente; Python, Node e Go spesso includono o usano un proprio archivio di fiducia e non la vedono mai. È esattamente lo scarto in cui curl funziona e il tuo codice no.

L'errore compare anche senza alcun proxy quando l'elenco di CA incluso in un ambiente è obsoleto, tipicamente su una vecchia immagine di container o su una VM di lunga durata mai aggiornata.

Non è un problema di autenticazione. La richiesta non completa mai l'handshake, quindi nessuna chiave viene inviata e nulla arriva ai log del provider.

Verifica se la causa è questa

Guarda chi ha firmato il certificato che stai effettivamente ricevendo:

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

Se l'emittente è una CA pubblica, l'archivio di fiducia del tuo ambiente è obsoleto. Se riporta il nome della tua azienda, di un dispositivo di sicurezza o di un produttore di antivirus, il traffico viene intercettato e devi installare quella radice dove il tuo ambiente la cerca.

Come risolvere

  1. Indica all'ambiente il pacchetto di CA correttoEsporta la radice dell'intercettatore e imposta REQUESTS_CA_BUNDLE o SSL_CERT_FILE per Python, NODE_EXTRA_CA_CERTS per Node. Così la verifica resta attiva, ed è proprio questo il punto.
  2. Aggiorna i certificati inclusiReinstalla o aggiorna il pacchetto certifi, oppure ricostruisci il container su un'immagine di base aggiornata. I pacchetti obsoleti falliscono con i certificati intermedi più recenti.
  3. Non disattivare la verificaverify=False e NODE_TLS_REJECT_UNAUTHORIZED=0 fanno sparire l'errore accettando qualsiasi certificato, compreso quello di chiunque si trovi sulla tua rete. E su quella connessione stai inviando una chiave API.
Tutto avviene lato client, quindi nel log di utilizzo di APICLAN non comparirà alcun handshake fallito: la richiesta non è mai arrivata. Un log vuoto insieme a un errore TLS è la combinazione attesa, non un secondo problema.

Articoli correlati

Unexpected token '<' quando chiami un'API compatibile con OpenAI401 invalid API key: quando la chiave sembra giusta ma continua a fallire

Ultima verifica: 2026-10-01. Scritto a partire da problemi diagnosticati su un gateway compatibile con OpenAI in produzione, non raccolto da altri siti.