TLS interception and corporate root CAs

An intercepting proxy performs a deliberate machine-in-the-middle on TLS. It accepts the client's connection, reads the intended hostname (from the CONNECT request, or from SNI when the traffic is transparently redirected), opens its own TLS session to the real server, and then generates a leaf certificate for that hostname on the fly, signed by a CA whose root has been installed into the client's trust store. The client validates that forged certificate successfully, because from its point of view the chain is legitimate. Nothing in TLS is broken. A trust anchor was added, and the anchor's holder can now impersonate every site on the internet to that client.

The mechanism is the same one described in transparent and intercepting proxies, applied to encrypted traffic. What follows is what it enables, what it costs, and the trust store fixes developers actually need.

The handshake, step by step#

1. Client -> proxy    CONNECT api.example.com:443 HTTP/1.1
                      (or a transparent redirect; the proxy reads SNI instead)
2. Proxy  -> client   HTTP/1.1 200 Connection Established
3. Client -> proxy    ClientHello, SNI = api.example.com
4. Proxy  -> server   its own ClientHello (proxy's version and cipher preferences)
5. Server -> proxy    real certificate for api.example.com
6. Proxy              validates the real chain, then mints:
                        Subject:  CN=api.example.com
                        SAN:      DNS:api.example.com  (copied from the real cert)
                        Issuer:   CN=Acme Corp TLS Inspection CA
                        Validity: often days, not months
                        no SCTs, usually a fresh key or a shared per-proxy key
7. Proxy  -> client   forged certificate, signed by the corporate CA
8. Client             validates against its trust store, finds the corporate root, succeeds

Two independent TLS sessions now exist, and the proxy holds the plaintext of both. Step 6 is where the properties diverge from the real connection: the forged certificate is not in any Certificate Transparency log, its validity period is usually short, and its extensions are a subset of the original.

What interception buys, and what it costs#

Certificate pinning, HSTS and HPKP#

Pinning is the direct countermeasure to interception, and it works: an application that only accepts a specific public key or a specific issuer rejects the forged certificate outright. Mobile applications, package managers, some CLI tools and most agent software pin. The symptom is a hard failure with no bypass, often with an unhelpful message, and there is no way to fix it at the client. The only resolutions are to add the destination to the proxy's do-not-decrypt list (matched on SNI, or on destination IP when SNI is unavailable), or to stop pinning.

HSTS (RFC 6797) does not prevent interception when the corporate root is trusted, because the chain validates and no warning is shown. What HSTS does is remove the click-through: on an HSTS host, a browser presented with an untrusted certificate gives the user no option to proceed. That matters for the unmanaged device that never received the corporate root, which turns a nuisance into a hard failure. HSTS preloading extends this to the first visit.

HPKP (RFC 7469) was the web's attempt at pinning in a header, and it is dead: it was removed from Chrome in version 72 and was never widely deployed, largely because a misconfigured pin bricked a site for the pin's lifetime. Do not design around it. Its spirit survives in Expect-CT (also now deprecated) and, for applications, in in-app pinning.

The trust store table developers actually need#

The single most important fact: there is no such thing as "the" trust store. Installing a root into the OS store fixes browsers and OS-integrated tools, and does nothing for a JVM, a Python virtualenv, a Node process or a Go binary on macOS. One machine routinely has curl working and pip failing, and that is not a paradox.

The operational lesson: treat the corporate root as a build artefact. Bake it into base images, into the JDK provisioning step, and into developer machine setup, rather than fixing it per tool per incident. The wider tooling picture is covered in corporate proxies and developer tooling, and connectivity problems that look like TLS problems are often really proxy variable problems, which the no_proxy tester helps isolate.

Error strings, mapped to fixes#

Two of these deserve emphasis because they are misread constantly. unable to get local issuer certificate means the issuer is unknown, which is exactly what interception produces, and it is not a sign that the remote site's certificate is bad. And a name mismatch (certificate is valid for X, not Y) is a different class of fault from a trust failure: adding the CA will not fix it.

The downgrade risk nobody sees#

The client evaluates only the proxy leg. Whatever the proxy negotiates upstream is invisible to it, and there is no mechanism by which the client can learn about it. Concretely, an interception product can:

• negotiate TLS 1.2 upstream while presenting a TLS 1.3 connection to the client, so the client's own policy of "TLS 1.3 only" is satisfied while the traffic that leaves the building is not
• accept upstream cipher suites the client would have refused, including ones without forward secrecy
• skip hostname verification, revocation checking or CT enforcement on the upstream chain, which some products do by default for compatibility
• pool and reuse upstream connections across different internal users, which can carry session state further than intended

Meanwhile the client's own protections are neutralised: CT enforcement does not apply to locally trusted roots, and pinning is either bypassed by policy or the connection simply fails. The security posture of every intercepted connection is the interception product's posture, not the client's. If interception is in place, the upstream leg's TLS configuration is something to audit deliberately, on the same schedule as the edge configuration you do control.

Client certificate authentication does not survive interception#

If a destination requires mTLS, an intercepting proxy cannot complete the upstream handshake, because it does not hold the client's private key. The server sends a CertificateRequest, the proxy has nothing to present, and the connection fails. From the user's side this looks like a timeout or a generic handshake error, with no indication that a client certificate was ever involved.

There are only two workable arrangements:

1. Bypass. Add the destination to the do-not-decrypt list so the connection is tunnelled at layer 4. The proxy then routes on SNI alone, with the caveats in SNI-based routing, and the client's certificate reaches the real server.
2. Re-originate. Install a client certificate on the proxy and let the proxy authenticate as itself. This changes who the server sees, which is usually unacceptable for an audited system, and it puts the identity's private key on a shared device.

Bypass is the normal answer. Note that a bypass list keyed on SNI degrades when clients enable Encrypted Client Hello, since the visible name becomes the client-facing server's public name. The related problem of forwarding an already-verified identity to a backend is covered in mutual TLS through a proxy.

Privacy and legal considerations#

Stated neutrally, because the constraints are jurisdictional rather than technical:

• Decryption exposes credentials, session tokens, personal messages and health or financial data belonging to employees, not only corporate data. Whatever the proxy logs is now a repository of that material with the same protection requirements as the original.
• Many jurisdictions require notice, and some require consent or works council agreement, before employee communications may be inspected. The requirement usually attaches to the monitoring, not to the decryption, so a policy of "decrypt but do not retain" may still be in scope.
• Category-based do-not-decrypt lists (banking, healthcare, government, legal) are common practice and are usually driven by these obligations as much as by pinning failures.
• The interception CA's private key is the highest-value secret in the estate. Anyone who obtains it can impersonate any site to any device that trusts the root, and the compromise is undetectable by the client. It belongs in an HSM, with the root offline and an issuing CA doing the signing, and its distribution scope should be as narrow as the policy allows.
• Certificates minted by the proxy end up in browser caches, HSTS state and application logs, so evidence of interception persists on endpoints regardless of policy.

How to detect interception#

Three checks, in increasing order of certainty.

Compare the issuer chain. From the suspect machine:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -fingerprint -sha256

A public site should show a well-known public CA as issuer. An issuer naming your employer, your security vendor, or an unfamiliar internal name is interception. Short validity windows (days rather than months) and a missing SCT extension are corroborating signals.

Compare the fingerprint against a known-good vantage point. Run the same command from a machine outside the intercepted network, or from a mobile connection, and compare the SHA-256 fingerprints. They differ under interception, always, because the keys differ.

Use a pinned endpoint. Any tool that pins will fail loudly and immediately under interception, which turns a subtle question into a binary one. A quick equivalent is to fetch over HTTPS with a CA bundle containing only the public roots, for example curl --cacert /path/to/public-roots-only.pem https://example.com/: success means no interception on that path, failure with error 60 means the chain does not terminate in a public root. The mechanics of running curl through a proxy, including which variables affect it, are in curl through a proxy.

You can also inspect the certificate chain length and extensions. Interception products commonly copy the subject and SANs but drop AIA/OCSP URLs, certificate policies and SCTs, so a leaf with no OCSP responder URL for a site that normally has one is a strong hint.

Failure modes#

Frequently asked questions#

How does a proxy decrypt HTTPS without the site's private key?#

It does not decrypt the original session. It terminates the client's connection using a certificate it generates itself for that hostname, signed by a CA installed in the client's trust store, and opens a second, separate TLS connection to the real server. The client trusts the forged certificate because the signing CA is in its store, so verification succeeds and the proxy holds plaintext on both sides.

Why does curl fail with "unable to get local issuer certificate" but Chrome works?#

Because they use different trust stores. Chrome uses the operating system store (on most platforms), where the corporate root was installed, while curl uses its own compiled-in CA bundle, which was not updated. Point curl at a bundle containing the corporate root using --cacert or CURL_CA_BUNDLE, or add the root to the OS bundle and regenerate it.

What is the difference between CERTIFICATE_VERIFY_FAILED and "certificate signed by unknown authority"?#

Nothing, at the protocol level. They are Python's and Go's wordings for the same outcome: the presented chain does not terminate in a certificate that runtime trusts. The fix is identical, add the interception CA to that specific runtime's trust store, and the two errors appear on the same machine at the same time simply because two languages are involved.

Does certificate pinning stop TLS interception?#

Yes, for the pinned application. A pinned client compares the presented key or issuer against a hard-coded expectation, and the forged certificate does not match, so the connection is refused. The proxy operator cannot work around it from the network side; the destination has to be excluded from decryption, or the pin removed from the application.

Should I set NODE_TLS_REJECT_UNAUTHORIZED=0 to get past this?#

No. That disables certificate verification for the entire Node process, against every destination, which removes the protection TLS exists to provide. Use NODE_EXTRA_CA_CERTS to add the interception root instead, which keeps verification on and trusts exactly one additional anchor. The same reasoning applies to --trusted-host in pip, strict-ssl false in npm and http.sslVerify false in Git.

Can an intercepting proxy weaken the encryption I am using?#

Yes, and the client cannot detect it. The client only evaluates the connection to the proxy; the proxy independently chooses the TLS version, cipher suites and validation strictness for the upstream leg. A client enforcing TLS 1.3 and modern ciphers may be sitting in front of a proxy negotiating TLS 1.2 with an old cipher suite to the real server.

How do I tell whether my traffic is being intercepted?#

Inspect the certificate issuer with openssl s_client -connect host:443 -servername host piped into openssl x509 -noout -issuer -fingerprint -sha256. If the issuer is not a recognised public CA, or the SHA-256 fingerprint differs from what the same command returns on an unfiltered network, the connection is being intercepted. Certificate Transparency will not help, since locally installed roots are exempt from CT enforcement.

What happens to client certificate authentication under interception?#

It fails, because the proxy does not hold the client's private key and therefore cannot answer the server's CertificateRequest. The failure is usually reported as a generic handshake error or timeout with no mention of client certificates. Destinations requiring mTLS must be added to the proxy's do-not-decrypt list so the connection is tunnelled without decryption.