Certificate Errors When Using a Proxy
Identify whether the proxy's own TLS connection or the destination website failed verification before changing certificate settings.
Find which TLS handshake failed before changing a CA bundle. A proxy certificate and a website certificate can be checked on different connections.
| Proxy and target | TLS checks |
|---|---|
| HTTP proxy carrying an HTTPS target | After CONNECT, verify the destination certificate through the tunnel. |
| HTTPS proxy carrying an HTTPS target | First verify TLS to the proxy; after the tunnel opens, verify the separate destination TLS session. |
Use the verbose trace to identify the requested hostname and last completed handshake. An HTTPS-proxy certificate failure can occur before the website is contacted. Check that connection's intended name, certificate validity period, local clock, expected chain and approved trust store. Include any deliberately configured TLS interception or added root certificate in the investigation.
curl exposes separate CA options for the two connections:
curl --proxy https://proxy.example:8443 --proxy-cacert proxy-ca.pem --cacert site-ca.pem https://example.com/--proxy-cacert supplies trust for the proxy; --cacert supplies trust for the destination. Replace the example endpoint and files with values from the trust arrangement you intend. Custom bundles are unnecessary when system trust already suffices.
Replacing a hostname with an arbitrary IP changes certificate matching. Skipping verification can conceal the failure without establishing the other end's identity. For an unfamiliar proxy, a request to install its root CA is not enough reason to trust it.
A refused port or rejected CONNECT belongs to an earlier stage; changing certificates cannot fix it. Conversely, after destination TLS verifies, a website HTTP error belongs to the received response rather than another CA adjustment.