Start → Hilfe

SSL certificate verify failed beim Aufruf einer KI-API

Irgendetwas zwischen Ihnen und dem Anbieter terminiert TLS und signiert neu, mit einem Zertifikat, dem Ihre Laufzeitumgebung nicht vertraut. Das Zertifikat des Anbieters ist in Ordnung; Ihrem Trust Store fehlt das Stammzertifikat des Abfangenden.

Was Sie sehen

Warum das passiert

Firmen-Proxys, einige Virenschutzprodukte und die meisten VPN-Inspektionsgeräte entschlüsseln HTTPS, um hineinzuschauen, und stellen dann ihr eigenes Zertifikat aus. Betriebssysteme bekommen dieses Stammzertifikat zentral installiert; Python, Node und Go bringen oft einen eigenen Trust Store mit oder nutzen ihn und sehen es nie. Genau in dieser Lücke funktioniert curl und Ihr Code scheitert.

Der Fehler tritt auch ganz ohne Proxy auf, wenn die mitgelieferte CA-Liste einer Laufzeitumgebung veraltet ist – typischerweise bei einem alten Container-Image oder einer langlebigen VM, die nie aktualisiert wurde.

Es ist kein Authentifizierungsproblem. Die Anfrage schließt den Handshake nie ab, also wird nie ein Schlüssel gesendet und nichts erreicht die Logs des Anbieters.

Prüfen, ob es daran liegt

Schauen Sie, wer das Zertifikat signiert hat, das Sie tatsächlich erhalten:

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

Ist der Aussteller eine öffentliche CA, ist der Trust Store Ihrer Laufzeit veraltet. Nennt er Ihre Firma, ein Sicherheitsgerät oder einen Antivirenhersteller, wird der Verkehr abgefangen, und Sie müssen dieses Stammzertifikat dort installieren, wo Ihre Laufzeit sucht.

So beheben Sie es

  1. Die Laufzeit auf das richtige CA-Bundle zeigen lassenExportieren Sie das Stammzertifikat des Abfangenden und setzen Sie REQUESTS_CA_BUNDLE oder SSL_CERT_FILE für Python, NODE_EXTRA_CA_CERTS für Node. So bleibt die Prüfung aktiv – und darum geht es.
  2. Die mitgelieferten Zertifikate aktualisierenInstallieren oder aktualisieren Sie das Paket certifi neu oder bauen Sie den Container auf einem aktuellen Basis-Image neu. Veraltete Bundles scheitern an neueren Zwischenzertifikaten.
  3. Die Prüfung nicht abschaltenverify=False und NODE_TLS_REJECT_UNAUTHORIZED=0 lassen den Fehler verschwinden, indem sie jedes Zertifikat akzeptieren – auch das von wem auch immer in Ihrem Netz. Sie senden über diese Verbindung einen API-Schlüssel.
Das spielt sich vollständig auf Client-Seite ab, daher zeigt Ihr APICLAN-Nutzungslog keinen gescheiterten Handshake – die Anfrage ist nie angekommen. Ein leeres Log zusammen mit einem TLS-Fehler ist die erwartete Kombination, kein zweites Problem.

Verwandte Themen

Unexpected token '<' beim Aufruf einer OpenAI-kompatiblen API401 invalid API key – wenn der Schlüssel richtig aussieht und trotzdem scheitert

Zuletzt geprüft am 2026-10-01. Geschrieben aus Problemen, die auf einem laufenden OpenAI-kompatiblen Gateway diagnostiziert wurden – nicht von anderen Seiten zusammengetragen.