Corporate TLS interception in WSL — “self signed certificate in chain”

The corporate quirk

The network runs a TLS-intercepting proxy. Every intercepted connection is re-signed on the fly:

leaf   CN=<the site you asked for>
  issued by  CN=proxy.<corp-domain>        (intermediate)
    issued by  CN=<CORP-ROOT-CA>           (self-signed root, not publicly trusted)

Because <CORP-ROOT-CA> is not in any trust store, every TLS client reports “self signed certificate in certificate chain” (OpenSSL verify code 19, Node SELF_SIGNED_CERT_IN_CHAIN).

So npm install and git clone work fine while opencode is dead. Do not conclude “the network is fine” from a working npm/git — always probe the host that is actually failing.

Everything in the left column shares one cause. Three separate-looking symptoms turned up over this investigation — opencode failing, the MCP server not connecting, and the Claude Code CLI erroring — and all three were this same proxy. Suspect one root cause before theorising about three.

Three traps that make the obvious fix fail

1. Exporting CAs from the Windows cert store may not contain the proxy CA

The intuitive route — dump the Windows Root/CA stores, import into WSL — silently produced only public CAs and none of the corporate ones. Filtering with “exclude Windows built-in roots” does not guarantee the interception CA is present in the store at all.

2. opencode is a Bun-compiled binary and ignores the system trust store

Its stack traces show /$bunfs/…. Bun does not read /etc/ssl/certs and does not honour SSL_CERT_FILE. It honours only NODE_EXTRA_CA_CERTS.

Consequence: update-ca-certificates alone fixes curl/git/python but not opencode. The CA must land in both places:

Claude Code ships as a native compiled binary too and had NODE_EXTRA_CA_CERTS in its environment. Which of the two stores it actually reads was never determined — both were updated within two seconds of each other, so the observation cannot separate them. Install to both and the question does not matter.

3. A process already running keeps the OLD trust store

Both the system bundle and NODE_EXTRA_CA_CERTS are read once, when a process first builds its TLS trust store. Replacing those files afterwards does nothing for anything already running.

Symptom to recognise: on one network, some tools work and others fail, with identical env vars. Compare process start time against the bundle’s mtime:

ps -o pid,lstart -p <pid>
stat -c '%y %n' /usr/local/share/corp-bundle.pem /etc/ssl/certs/ca-certificates.crt

If the process is older than the file, restart it — that is the whole fix. It also explains the confusing “works on mobile hotspot, fails on corporate” pattern: an unfiltered network needs only the public roots the stale bundle already had, so the staleness stays invisible until you hit the proxy.

Procedure

# 1) ON the corporate network — diagnose + capture. Read-only, no sudo.
bash check-ssl.sh
#    -> ssl-report-<timestamp>/{report.txt,captured-cas/,captured-bundle.pem}

# 2) Install. Works on any network, needs sudo.
bash install-captured-ca.sh ssl-report-<timestamp>

# 3) Reload the shell AND restart every long-running client
#    (opencode, Claude Code, editors, language servers, dev servers).
#    See trap 3 - a running process keeps the trust store it started with.
exec $SHELL -l

# 4) Verify ON the corporate network
curl -sSI https://models.opencode.ai/api.json | head -1
opencode run 'hi'
opencode mcp list          # remote MCP servers go through the same proxy

install-captured-ca.sh skips public CAs by issuer-name match and installs only the corporate ones, so the trust store does not get polluted with redundant copies of public roots.

Reading check-ssl.sh output

Per host it prints four client results. The important one:

node (builtin roots)   : FAIL SELF_SIGNED_CERT_IN_CHAIN   <- what Bun/opencode roughly sees

node (builtin roots) runs with NODE_EXTRA_CA_CERTS/SSL_CERT_FILE stripped, approximating Bun’s embedded-roots-only view. If curl passes but that row fails, the problem is the runtime’s trust store, not the network.

MCP servers behind the proxy

A remote MCP server ("type": "remote" in the opencode config) is just an HTTPS endpoint, so it is subject to the same interception — plus proxy URL/category filtering, which the CA fix does not address.

check-ssl.sh discovers MCP URLs from the opencode config at runtime (it greps "url" values), so no private hostname is hard-coded. For each it reports DNS A/AAAA, TCP/443 reachability, an unauthenticated GET, and a JSON-RPC initialize POST.

No credentials are ever sent. An HTTP 401 with a JSON auth error is the success signal — it proves TLS and the HTTP round-trip completed end to end. Distinguish the failure modes by what comes back:

Keep a known-good run from an unfiltered network and diff against the corporate run — the difference localises the fault immediately.

Note getent hosts prints the AAAA record first on dual-stack hosts, which looks like “IPv6 only” at a glance. Check getent ahostsv4 before blaming IPv6.

Gotchas

• /etc/profile.d/*.sh only runs for login shells. The first attempt set the CA env vars there; scripts and non-login shells got nothing, so behaviour differed depending on how the shell was started. install-captured-ca.sh also appends a source line to ~/.bashrc.
• Env vars are inherited. After removing an export from ~/.bashrc, the current session still has it. Check with env -u VAR bash -ic 'echo $VAR', not a plain child shell.
• Do not “fix” this by disabling verification. NODE_TLS_REJECT_UNAUTHORIZED=0, npm config set strict-ssl false, git config http.sslVerify false, PYTHONHTTPSVERIFY=0 all mask the problem and disable verification globally. (Note: PYTHONHTTPSVERIFY=0 is a no-op on modern CPython, and HTTPS_VERIFYPEER is not read by anything standard — both are cargo-culted.)
• Certs expire. The proxy intermediate had a ~5-year life, the root ~40. When the intermediate rolls over, re-run the capture + install.

Security note

Trusting the corporate root means the proxy can decrypt TLS traffic to the intercepted hosts. That is a property of how the network is operated — these scripts only make the existing interception explicit rather than fatal. The alternative (disabling verification) is strictly worse: it accepts any certificate, not just the proxy’s.

Files