Which Side of the Inspection Proxy Rejected the Certificate?

The client trusts the approved inspection proxy. The request still fails because of a certificate error. Both facts can be true: that proxy has another TLS relationship to verify.

client -- TLS to approved intermediary -- proxy -- TLS to website -- destination

In an interception arrangement, the intermediary terminates the client's TLS and creates its own connection onward. The client can accept the certificate presented on its side while the proxy rejects the certificate it receives from the website.

Read the verifier's error

Determine which process reported the failed chain or hostname. A proxy-generated error page can reach the client successfully over a valid connection. Changing the client's CA file again does not update the proxy's upstream trust configuration.

Mitmproxy, for example, documents separate upstream trust options, including ssl_verify_upstream_trusted_ca. The appropriate administrator can configure approved trust for the upstream service while preserving verification. Another proxy product needs its corresponding interface.

Check the actual destination name and chain too. A private service missing an intermediate, an expired certificate, and an unrecognized private issuer require different repairs. An intended exception for one private service should not silently become a global acceptance of every certificate.

A plain CONNECT tunnel is different

An opaque forward tunnel does not split destination TLS in this way. The application ordinarily negotiates and verifies that end-to-end TLS session itself. First establish whether interception is actually part of the route, rather than applying inspection-proxy settings to any intermediary.

Record the two verification results separately. “The proxy certificate is trusted” answers the client-side question; it does not certify what the proxy saw when it connected onward.