TLS Errors Only on the Corporate VPN: Fix the Right Trust Store

The Go build, the Composer install and the Python client all work at home and all fail inside the company VPN. That pattern is telling you about the path, not about the application. Something on the tunnel changed the certificate chain your process sees, or it reset the handshake before a chain arrived at all. The two faults look similar in a terminal and need completely different responses.

Three messages, three mechanisms

An x509 certificate signed by unknown authority error means a chain was built and its root is missing from the trust store that process uses. A self-signed certificate in certificate chain error usually means an inspection proxy answered with its own certificate, which is a chain your runtime does not recognise. An SSL EOF during the handshake means the connection closed before any usable certificate was sent, and that is a middlebox rejecting the ClientHello rather than a trust problem at all.

Adding an insecure flag makes all three messages disappear while leaving the interception in place, and it removes the check that would catch a genuine attacker.

Find the bundle that process actually reads

The corporate root installed in the Windows store fixes browsers and .NET applications that consult the system store. It does nothing for a build running inside a container, which carries its own CA bundle, and nothing for a Python process using certifi or a Node process using its bundled list. Go reads the system pool of the environment the binary runs in, which is the container, not the laptop. One machine therefore produces a working browser and a failing build tool at the same time.

Ask the tool rather than assuming. python3 -c "import ssl; print(ssl.get_default_verify_paths())" prints the files that Python will consult, and node -e "console.log(process.env.NODE_EXTRA_CA_CERTS)" shows whether an override is already set. For a container, run the same check inside the image, because that is the environment the build actually uses.

Install one root where the build runs

Get the inspection root from IT as a PEM file and verify its fingerprint through a separate channel before trusting it. On Debian-derived images, copy it into /usr/local/share/ca-certificates/ and run update-ca-certificates; RHEL-family images use update-ca-trust after dropping the file into /etc/pki/ca-trust/source/anchors/. In a container build, add those steps before the failing command so the layer is cached above the dependency install.

For a local devcontainer, mount the PEM and run the same update command at start rather than baking it into a personal image that nobody else can reproduce. Tools that ship their own bundle need their own documented override: pip has a certificate setting, npm has a cafile setting, and most others accept the standard environment variables.

This is not the same as accepting any certificate. You are adding one specific root, obtained from the party doing the inspection, to one environment, and verification stays on for every other chain. Record which file was added and when it expires, since an inspection root is renewed like any other CA.

When the handshake dies before a certificate

If nothing is presented, no trust store change will help. Compare the same request with the tunnel up and down, then inspect the chain directly with openssl s_client -connect host:443 -servername host -showcerts. A connection that completes outside the VPN and resets inside it is a policy decision made by the middlebox, and the remedy is an exception for that host rather than another certificate. Ask for the package registry or API endpoint to be allowed through unmodified.

Splitting the tunnel so the tool bypasses the VPN avoids inspection for that traffic, which may violate policy and does not make the tool trustworthy.

Write the outcome down per tool

A short note listing the binary, the trust file it reads, the environment variable in play and the approved exception saves the next person the entire diagnosis. Keep the note per tool rather than per laptop, because the laptop is rarely the thing that changed.

And keep two sentences separate in the ticket: we installed a specific corporate root, and we turned verification off. Only one of those is a support action.