An HTTPS Proxy Needs to Send Its Certificate Chain Too

If clients reject the HTTPS proxy before reaching a website, inspect the chain sent by the proxy listener. A valid leaf certificate alone may not supply the intermediate certificates the client needs.

1. Identify the checked endpoint. Read the hostname in the configured proxy URL and the error for that connection. The listener certificate must cover that name. A website certificate or certificate for another IP alias cannot replace it.
2. Check the listener's chain configuration. Squid's supported OpenSSL configuration can include intermediates in the certificate file. Confirm the arrangement in the listener reference for the installed Squid release and TLS backend; package behavior is not uniform. The Squid 6.13 TLS-listener example keeps listener trust separate from destination TLS.
3. Check client trust separately. Sending intermediates helps build the chain, but the client still needs the intended root trust anchor. Importing the entire server chain into a root store indiscriminately is a different change from correcting what the server sends.

Keep verification enabled. It identifies the HTTPS proxy the client intended to use. After that connection verifies, a later website certificate error belongs to the destination TLS session through the proxy, with its own hostname and trust investigation.