Quickstart Pricing

Home → Help

SSL certificate verify failed when calling an AI API

Something between you and the provider is terminating TLS and re-signing it with a certificate your language runtime does not trust. The provider's certificate is fine; your trust store is missing the interceptor's root.

What you are seeing

Why it happens

Corporate proxies, some antivirus products and most VPN inspection appliances decrypt HTTPS to look inside it, then issue their own certificate. Operating systems get that root installed centrally; Python, Node and Go often ship or use their own trust store and never see it. That is the exact gap where curl succeeds and your code fails.

The error also appears with no proxy at all when a runtime's bundled CA list has gone stale, typically on an old container image or a long-lived VM that has never been updated.

It is not an authentication problem. The request never completes the handshake, so no key is ever sent and nothing reaches the provider's logs.

Confirm it is this

Look at who signed the certificate you are actually receiving:

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

If the issuer is a public CA, your runtime's trust store is stale. If it names your company, a security appliance or an antivirus vendor, traffic is being intercepted and you need that root installed where your runtime looks.

How to fix it

  1. Point the runtime at the right CA bundleExport the interceptor's root and set REQUESTS_CA_BUNDLE or SSL_CERT_FILE for Python, NODE_EXTRA_CA_CERTS for Node. This keeps verification on, which is the point.
  2. Update the bundled certificatesReinstall or upgrade the certifi package, or rebuild the container on a current base image. Stale bundles fail against newer intermediate certificates.
  3. Do not disable verificationverify=False and NODE_TLS_REJECT_UNAUTHORIZED=0 make the error go away by accepting any certificate — including one from whoever is on your network. You are sending an API key over that connection.
This is entirely client-side, so nothing in your APICLAN usage log will show a failed handshake — the request never arrived. An empty log alongside a TLS error is the expected combination, not a second problem.

Related

Unexpected token '<' when calling an OpenAI-compatible API401 invalid API key — when the key looks right but still fails

Last checked 2026-10-01. Written from problems diagnosed on a live OpenAI-compatible gateway, not collected from other sites.