Errors such as unable to get local issuer certificate, unable to verify the first certificate, and UNABLE_TO_GET_ISSUER_CERT_LOCALLY mean a client cannot build a trusted path from the server certificate to a trusted certificate authority.

In an AI system, the failure may sit between a user and an API gateway, a gateway and a model provider, an agent and an MCP server, or two internal services. Disabling certificate verification hides that boundary and exposes credentials and model data to interception.

Identify which TLS hop fails

Map the full route:

client → CDN/load balancer → AI gateway → model or MCP service

Test each hostname from the same container, runner, or server that failed:

curl -v https://ai.example.com/health
openssl s_client -connect ai.example.com:443 -servername ai.example.com -showcerts

Check the requested hostname, leaf certificate, intermediate certificates, issuer, expiry, and the trust store used by that specific runtime.

Fix an incomplete certificate chain

A server normally presents its leaf certificate plus required intermediates. A common misconfiguration serves only the leaf certificate, so some browsers work through cached intermediates while containers and CI fail.

Configure the proxy or load balancer with the CA-provided full chain. Do not add the leaf certificate itself to every client trust store as a workaround. After reloading the service, test from a clean environment.

Private CA and service-to-service TLS

Internal inference, gateway, and MCP services may use a private CA. Distribute the CA certificate through an approved trust mechanism and mount it read-only into workloads. Keep CA trust separate from application secrets, and rotate it with an overlap period.

Avoid application-specific NODE_TLS_REJECT_UNAUTHORIZED=0, verify=False, curl -k, or equivalent production bypasses. If temporary diagnosis requires a bypass, never send real API keys, prompts, or customer data through that connection.

Proxies, containers, and CI runners

TLS inspection proxies create a new certificate chain. The corporate root must be installed in the runner or container trust store; adding it only to the host may not affect the container. Minimal images can also lack current CA bundles.

Confirm that:

• the image contains a maintained CA bundle;
• the runtime uses the expected system or custom trust store;
• proxy variables are intentional;
• staging and production trust roots match their policies;
• the proxy forwards the complete upstream chain.

For the protocol foundation, read How HTTPS and TLS work. Connect service identity and credentials through the AI Security hub and API authentication guide.

Production verification

1. Test every public and internal hostname with SNI.
2. Verify the complete chain from the actual workload.
3. Exercise streaming AI responses through proxies and load balancers.
4. Monitor TLS errors by upstream service.
5. Test certificate rotation before the old chain expires.
6. Keep a rollback path for proxy and trust-store changes.

AI Operations covers production monitoring, while AI Deployment & Hosting covers the infrastructure boundary.

The safe fix restores a verifiable trust chain. It does not teach each client to ignore identity.