You ship something. It works on your machine, in CI, in staging, and for every user who tries it. Then one customer opens a ticket: it doesn't work for them. Same version, same config, same everything. It just hangs, or throws a certificate error, or fails in some way your error handling never anticipated.
They're on a corporate network. Somewhere between their machine and your server, a device is opening every TLS connection, reading it, and building a new one.
This is normal. Large organisations are often legally required to inspect traffic leaving their network, and they've been doing it for twenty years. The problem isn't that it happens. The problem is that from where you're standing, it's nearly invisible — and the failures it causes look like bugs in your code.
Here's what's actually happening, why five different things break in five different ways, and how to work out which one you're looking at without access to the customer's network team.
A normal TLS connection is between your client and your server. The server presents a certificate, the client checks it chains to a certificate authority it trusts, and the two negotiate keys that nobody in the middle can derive. That's the entire point.
An inspection proxy breaks this into two connections. It terminates the client's TLS session itself, then opens a separate one to the real server. In the middle, it holds plaintext.
For the client to accept this, the proxy has to present a certificate for the site the client asked for. It generates one on the fly, signed by a CA whose root certificate the organisation has installed on every managed machine. On a managed laptop, this works transparently. The browser sees a valid chain to a root it trusts, and shows a padlock.
One consequence is worth stating plainly, because a lot of developers get it backwards: this isn't a vulnerability being exploited. It works because an administrator deliberately installed a root certificate. Browsers make a specific exception for locally-installed roots — Certificate Transparency requirements and most key-pinning checks are enforced for publicly-trusted CAs but relaxed for locally-added ones. If they weren't, corporate inspection would break the web for a large fraction of enterprise users, so the exception is deliberate.
That exception is also the reason the failures are so confusing. Interception works fine for the browser, which is why the customer insists their internet is "working" — and breaks for everything else.
Five mechanisms, five different failure signatures Your language runtime doesn't use the system trust store
The corporate root CA gets installed into the operating system trust store. The browser picks it up. Your application might not, because several runtimes ship their own bundled list of certificate authorities and ignore the OS entirely: Node.js bundles its own root store. It does not read the system store by default. The escape hatch is NODEEXTRACACERTS, pointing at a PEM file. Python, when using requests or anything else built on certifi, uses the certifi bundle rather than the system store. REQUESTSCABUNDLE and SSLCERTFILE override it. Java uses its own cacerts keystore, managed with keytool, entirely separate from the OS. Go does read system roots on Linux and macOS, but any code that sets a custom tls.Config with its own RootCAs pool has opted out.
Signature: the site loads in the browser on the same machine, but your application throws a certificate verification error. That specific combination — browser fine, code broken — almost always means a trust store mismatch rather than anything wrong with the network.
Firefox is worth a special mention. It maintains its own trust store independently of the OS, so an environment where Chrome works and Firefox doesn't is the same problem wearing a different hat. Certificate pinning
If your application pins a specific certificate or public key — common in mobile apps and in anything handling payments — you've explicitly said you will only accept one identity, regardless of what the trust store says. An inspection proxy cannot satisfy that. It doesn't have the private key.
Signature: fails on every corporate network, works everywhere else, and no amount of installing certificates fixes it. Unlike the trust store problem, this one is unfixable from the client side. That's the point of pinning.
If you pin, you need a documented way for administrators to allow-list your domain from inspection, and your error message should say so. Most apps that pin fail with a generic network error, which turns a five-minute fix into a week of support tickets. Mutual TLS
If your server requires a client certificate, the proxy has to present one on the client's behalf. It doesn't have the client's private key, so it can't. Some proxies detect this and pass the connection through untouched; others don't, and the handshake dies.
Signature: the handshake fails after the server requests a certificate, often with an unhelpful message about a missing or bad certificate. The tell is that it fails at a specific handshake stage, not at verification. Protocol upgrades and long-lived connections