HTTPS Proxy TLS Chain Audit: Verify Both Trust Layers Before Production

An HTTPS request sent through a proxy can involve more than one trust decision. With an HTTPS proxy, the client first authenticates the proxy over TLS. It can then create a CONNECT tunnel and authenticate the destination inside that tunnel. If an approved enterprise inspection gateway terminates destination TLS, the certificate presented to the client changes again.

Treating all of this as one “SSL works” checkbox hides the failure layer. A proxy CA error is different from an origin CA error. An unexpected issuer is different from an expired certificate. A successful status code is not proof that the intended hostname, route or response was authenticated.

This guide builds a repeatable audit for authorized proxy deployments without disabling peer or hostname verification.

Model the four paths first

Document which path each application is expected to use:

1. Direct HTTPS: one TLS connection from client to destination.
2. HTTP proxy plus CONNECT: the client sends CONNECT to the proxy, then establishes end-to-end destination TLS through the tunnel.
3. HTTPS proxy plus CONNECT: an outer TLS connection authenticates the proxy; destination TLS runs inside the tunnel and is verified independently.
4. Approved TLS inspection: a managed intermediary terminates destination TLS and presents a replacement certificate chained to an enterprise trust anchor.

Do not label the fourth path “transparent” in the test plan. It is a materially different security architecture and requires explicit organizational approval, data-handling controls and managed trust distribution.

Keep the two trust stores separate

Use separate configuration and ownership for:

• the CA store that authenticates an HTTPS proxy;
• the CA store that authenticates the destination;
• any enterprise CA that is authorized to sign inspected destination certificates.

curl exposes this separation through proxy-specific and destination-specific CA options. Equivalent controls exist in many runtimes, but names and native-store behavior vary by operating system and TLS backend.

For a controlled diagnostic, a command can make the separation visible:

curl --verbose \
  --proxy "$PROXY_URL" \
  --proxy-cacert proxy-ca.pem \
  --cacert origin-ca.pem \
  "$TARGET_URL"

Provide credentials through a protected secret mechanism, not command history, process arguments or log output. Never publish proxy passwords, tokens, cookies, private keys or complete customer payloads.

Do not use insecure verification flags as a production fix. Turning verification off can make a request complete while removing the identity guarantee the audit is supposed to test.

Build a deterministic certificate fixture

Use a destination you own or are explicitly authorized to test. The fixture should provide:

• a valid hostname and certificate chain;
• a small response with a known digest;
• a semantic completion marker;
• controlled IPv4 and IPv6 records if both are required;
• documented TLS versions and application protocols;
• a maintenance record for planned certificate rotation.

Avoid using an unrelated public website as the only certificate oracle. Its certificate, CDN edge, supported protocol or routing can change without notice.

Capture evidence for each TLS leg

Record one sanitized row per attempt and distinguish peer roles:

trial_id
client_build
tls_backend
proxy_route_alias
requested_market
observed_market
address_family
peer_role
subject_name
san_match
issuer_name
chain_depth
valid_from
valid_until
spki_digest
tls_version
alpn_result
sni_name
verification_result
failure_phase
response_digest
time_to_useful_result_ms

The public-key digest helps compare observations, but do not hard-code a single value forever unless the service has a deliberate pinning policy and a tested rotation procedure. Certificate renewal, key rotation and CDN changes can be legitimate.

Run a one-variable matrix

Keep the target, method, headers, browser or runtime build and test payload fixed. Change only one dimension at a time:

Repeat the matrix for required route classes, markets and address families. If SOCKS5 is in scope, test local and remote DNS modes separately because the resolver path changes even though destination certificate hostname validation must remain correct.

Classify failures by phase

Before CONNECT

Investigate proxy DNS, TCP reachability, outer TLS, proxy hostname validation and proxy authentication. An HTTPS proxy certificate failure belongs here.

During CONNECT

Record the proxy response and target authority in sanitized form. A refused tunnel, authentication challenge or disallowed port is not a destination TLS failure.

During destination TLS

Check destination SNI, hostname match, certificate chain, validity period, supported TLS version and ALPN negotiation. If direct succeeds while every proxy route fails with the same destination certificate error, inspect client trust configuration and any approved intermediary.

After TLS

Validate HTTP status, final destination, response digest, semantic completion, language and market. A trusted certificate does not guarantee correct content.

Detect unexpected certificate substitution

Compare the direct and proxy observations for the same fixture and time window. Escalate when:

• the destination issuer changes only on a route that is not approved for inspection;
• the subject alternative name no longer matches the requested hostname;
• a private or enterprise root appears outside its documented environment;
• certificate validity or key properties fall outside policy;
• SNI or ALPN differs without an approved reason;
• the response digest changes together with the certificate path;
• only one market or exit group presents an unexplained chain.

Do not automatically call every difference an attack. CDNs can present different valid chains, and certificate rotation is normal. The correct response is to compare against the owned fixture, route inventory and approved trust architecture.

Test rotation and expiry before they become incidents

Use a staging fixture to rehearse:

1. destination certificate renewal with the same trust anchor;
2. destination key rotation;
3. proxy certificate renewal;
4. enterprise intermediate-CA rotation where inspection is approved;
5. removal of an obsolete root;
6. clock skew near validity boundaries;
7. client images with stale and current CA bundles;
8. rollback to the last known-good trust package.

The acceptance test must prove both continuity and rejection. A client should accept the new approved chain and reject an untrusted, mismatched or expired fixture.

Watch SNI, ALPN and protocol fallback

Capture the negotiated application protocol for both applicable TLS legs. Do not assume that HTTP/2 or another protocol is available merely because the direct path uses it. Proxy type, client library and gateway policy can change negotiation.

Measure fallback explicitly:

• expected protocol versus negotiated protocol;
• connection and handshake time;
• CONNECT latency;
• first-byte and complete-response time;
• reuse behavior after the first request;
• error class when negotiation fails.

Protocol fallback can be valid, but it should be visible and capacity-tested. A silent downgrade may increase connection count and tail latency even when correctness remains intact.

Regional rollout gate

For Global, North America, Europe and APAC, test only authorized markets. Start with one route per class and low concurrency, then widen gradually.

Require all of the following before production:

• proxy peer verified where the proxy uses TLS;
• destination hostname and chain verified;
• any certificate substitution matches an approved inspection policy;
• expected market and address family observed;
• response digest and semantic assertions pass;
• no secrets appear in logs;
• failure phase is classified;
• p95 time to useful result remains within budget;
• rollback has been exercised.

Do not solve a trust failure by rotating exits until one accepts. Quarantine the affected route, preserve minimal evidence and repair the CA, hostname, clock or gateway configuration.

Audit checklist

• [ ] Direct, HTTP proxy, HTTPS proxy and inspection paths are named correctly.
• [ ] Proxy and destination CA stores have separate owners and configuration.
• [ ] Peer and hostname verification remain enabled.
• [ ] Test fixtures are owned or explicitly authorized.
• [ ] Proxy and destination certificate evidence is stored separately.
• [ ] SNI, ALPN, TLS version and address family are captured.
• [ ] Planned certificate and intermediate-CA rotations are rehearsed.
• [ ] IPv4, IPv6 and DNS modes are tested where required.
• [ ] Response integrity is checked after TLS succeeds.
• [ ] Route differences are compared against approved architecture.
• [ ] Secrets, private keys and customer payloads are excluded.
• [ ] Quarantine and rollback procedures have passed a drill.

FAQ

Does CONNECT mean the proxy can read HTTPS content?

An ordinary CONNECT tunnel relays bytes while destination TLS remains between client and destination. A separately approved TLS-inspection gateway terminates that TLS and can inspect content. Document which architecture is actually deployed.

Why can an HTTPS proxy need two CA configurations?

The outer TLS leg authenticates the proxy; the inner TLS leg authenticates the destination. They are different peers and should be verified independently.

Is a changed certificate fingerprint always suspicious?

No. Legitimate renewal, key rotation or CDN routing can change it. Investigate the chain, hostname, timing, route and owned-fixture baseline together.

Can disabling verification confirm that the network path works?

It can remove one failure signal, but it also removes peer authentication and can hide the real defect. Use controlled fixtures and correct CA configuration instead; never treat an insecure run as production acceptance.

Should every application import an enterprise root?

Only applications and environments covered by an approved inspection architecture should trust it. Scope distribution narrowly, protect the private key, document ownership and rehearse removal.

Compliance and safe operation

Use only trusted, authorized proxies and destinations. TLS inspection can expose sensitive content and must follow organizational approval, privacy law, contractual limits and data-minimization policy. Do not intercept third-party or personal traffic without explicit authority, and do not weaken verification to conceal configuration errors.

Continue with the proxy response-integrity test, idle-timeout and keep-alive test, and residential proxy session-stickiness test.

Source note: IETF, RFC 9110 HTTP Semantics, June 2022; curl project, SSL CA Certificates and command-line documentation, reviewed September 13, 2026; Node.js project, HTTP proxy security considerations, reviewed September 13, 2026.