Claude Code "SSL certificate verification failed (UNABLE_TO_GET_ISSUER_CERT)": how to fix it

You updated Claude Code, opened a session, and every request now dies with SSL certificate verification failed (UNABLE_TO_GET_ISSUER_CERT). Your company CA is configured, nothing changed on the network, and the same machine worked yesterday. If that is you, the problem is probably not your configuration. It is version 2.1.304.

What is the full error message?

It shows up on the very first request, with no retries, because Claude Code has not retried certificate failures since v2.1.199:

API Error: Unable to connect to API: SSL certificate verification failed (UNABLE_TO_GET_ISSUER_CERT). The certificate comes from an authority Claude Code doesn't trust, usually a TLS-inspecting corporate proxy or a gateway signed by a private CA: set NODE_EXTRA_CA_CERTS to that CA bundle, or add it to the system certificate store

The message itself tells you to set NODE_EXTRA_CA_CERTS. That fixes it when the CA was never configured. It does not fix it when the CA is already configured and the new version stopped using it, which is what issue #103680 in the official repository has described since October 20, 2026.

Is it my configuration or the version?

If it worked on 2.1.303 and broke after an update, with no change on your side, it is the version. If it never worked on that machine, it is configuration. The table splits the cases:

Symptom	Likely cause	What to do
New machine or CA never configured; the log does not show the CA loaded	Configuration	Point NODE_EXTRA_CA_CERTS to the CA bundle
Worked up to 2.1.303; the log shows the CA loaded and the connection fails anyway	2.1.304 regression (issue #103680)	Go back to 2.1.303 and lock the auto-updater
Error only on an HTTP MCP server with an emSign chain, code CERT_REJECTED on newer versions	New certificate blocklist in 2.1.304, according to reports	No confirmed workaround; follow the issue

How do I confirm Claude Code loaded my CA?

Run a session with debug logging and look for lines starting with CA certs:. If your CA is there and the connection still fails, you are hitting the regression.

claude --version
claude --debug

The log does not go to the terminal: it is written to ~/.claude/debug/<session-id>.txt (or to the path you pass with --debug-file). On Linux or macOS:

grep "CA certs" ~/.claude/debug/*.txt | tail -n 20

This is the excerpt the author of #103680 posted on 2.1.304, with the CA loaded and the connection failing right after:

CA certs: stores=bundled,system, extraCertsPath=C:/.../gateway-ca.pem
CA certs: Loaded 117 bundled root certificates
CA certs: Loaded 123 system CA certificates
CA certs: Appended extra certificates from NODE_EXTRA_CA_CERTS
[ERROR] Bedrock ListInferenceProfiles failed: unable to get issuer certificate

If the line Appended extra certificates from NODE_EXTRA_CA_CERTS is missing, Claude Code did not read your file. Then it is a configuration problem and the version section below does not apply.

The CA is missing from the log: how do I configure it properly?

Put the variable in the env block of ~/.claude/settings.json, not only in your shell. The official docs explain why: background agents run in a supervisor process that inherits the environment of whichever terminal started it first, and only settings reach every session.

{
  "env": {
    "NODE_EXTRA_CA_CERTS": "/path/to/ca-bundle.pem",
    "CLAUDE_CODE_CERT_STORE": "bundled,system"
  }
}

bundled,system is already the default: Claude Code trusts its bundled Mozilla set and the operating system certificate store. Set it explicitly only if someone changed it before. The bundle must be PEM and, for a gateway signed by a private CA, include the root and the intermediates.

How do I go back to 2.1.303 and pin the version?

Use the official installer with the version number, then turn off the auto-updater. Without the second step, Claude Code moves back to the broken version on its next check.

macOS, Linux and WSL:

curl -fsSL https://claude.ai/install.sh | bash -s 2.1.303

Windows PowerShell:

& ([scriptblock]::Create((irm https://claude.ai/install.ps1))) 2.1.303

Check it:

claude --version
# 2.1.303 (Claude Code)

Now lock the auto-updater in ~/.claude/settings.json:

{
  "env": {
    "DISABLE_AUTOUPDATER": "1"
  }
}

And confirm it took effect:

claude doctor
# Auto-updates: disabled (set by env: DISABLE_AUTOUPDATER)

Three details the docs make clear:

• DISABLE_AUTOUPDATER only stops the background check. Manual claude update and claude install still work, so nobody on the team should run claude update out of habit while the pin is in place.
• Homebrew and WinGet installs do not auto-update. If you installed through them and are still on 2.1.303 or earlier, just skip the upgrade.
• If you want less risk long term, "autoUpdatesChannel": "stable" stays about a week behind and skips releases with major regressions. It is not a guarantee for this specific bug: check the version after switching.

Why not just set NODE_TLS_REJECT_UNAUTHORIZED=0?

Because it turns off certificate validation entirely, for every host. The official Claude Code error reference says so explicitly. You trade a visible error for a connection that accepts any certificate, including one from whoever sits in the middle. Rolling back a version is reversible; an open TLS path is something you will not notice later.

Is there a fix yet?

As of October 24, 2026, no. The official CHANGELOG goes up to 2.1.310 with no entry about custom CAs on Bedrock or gateway connections. In the issue, one user confirmed the error persists on 2.1.306 and another posted a 2.1.307 log with the same problem.

To know when to remove the pin, follow #103680 and the CHANGELOG. When the fix ships, delete the DISABLE_AUTOUPDATER line and run:

claude update
claude --debug

Test a real request before rolling it out to the team. Staying on 2.1.303 has a cost too: 2.1.309, for example, shipped several sandbox and Bash permission-check fixes. The pin is for getting through the bug, not for living there.

What if the error only shows up on an HTTP MCP server?

It may be a different cause. In the same issue, a user showed an MCP server with "type": "http" whose chain goes through the emSign Root CA - G1 root and that stopped connecting on 2.1.304. The 2.1.307 log shows a Dropped blocked certificate line and the CERT_REJECTED code, and the number of bundled roots dropped from 121 (2.1.296) to 117.

According to that report, curl, Node and openssl on the same machine accept the chain, and pointing NODE_EXTRA_CA_CERTS at the root did not help. There is no confirmation that going back to 2.1.303 fixes this case, and no official word from Anthropic on the blocklist. If your failure is only on one MCP server and its chain goes through emSign, add that to the issue with your --debug log: that is the kind of data that separates the two bugs.