An HTTPS proxy means two TLS connections, not one
The proxy hop and the website are separate TLS relationships with separate trust. Read which endpoint failed before changing any certificate setting.
The label HTTPS proxy describes the transport between your client and the proxy, and nothing more. It does not say the website behind it is encrypted by that same connection, and it does not say the proxy can read the page. Once you separate the two connections, certificate errors stop being mysterious and the comparison with a VPN becomes concrete.
Two endpoint pairs, two verifications
In ordinary tunnel mode there are two TLS relationships. The first runs from your client to the proxy and authenticates the proxy. The second runs from your client to the website inside the tunnel, and authenticates the website. They fail independently and they are configured independently.
They have separate trust decisions, separate certificate chains and separate failure messages. A proxy using an organizational CA and a public website using a public chain can legitimately need different verification configuration, and that is not a misconfiguration.
Treat them as two connections that happen to share a socket, because that is what they are.
What CONNECT actually tunnels
The client sends a CONNECT request naming the host and port, and the proxy opens a TCP connection to that target. After the proxy answers, the bytes that follow are relayed without interpretation, which is why the website's TLS handshake travels through the proxy untouched. The proxy therefore learns the destination name and the connection metadata, and it does not receive decrypted pages from that arrangement.
That distinction is the whole security argument for tunnel mode, and it is also its limit.
An HTTP proxy without TLS on the proxy hop still carries an HTTPS website through CONNECT. The client-to-proxy exchange is in the clear while the website connection is not, and calling the whole thing an HTTPS proxy hides that difference.
Which certificate failed
When verification fails, read the endpoint named in the error before changing any trust setting. The two failures look similar in a terminal and point at completely different fixes, which is why the first question is always which connection refused.
curl separates the options for exactly this reason. The proxy CA file configures verification of the proxy, while the CA file configures verification of the server, and the applicable trust store behaviour also depends on how curl was built.
curl -v --proxy https://proxy.example.net:443 \
--proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/Suppressing a check is not a repair. It establishes nothing about either endpoint.
Inspection is a different arrangement
TLS inspection is not tunneling. An inspecting intermediary terminates the website-facing trust relationship and presents its own certificate to the client, so the client verifies the intermediary rather than the site. That can be legitimate under an approved design, and it is a materially different claim from byte-for-byte relaying. Do not assume every proxy inspects, and do not assume an encrypted proxy hop rules it out.
An organizational CA in your trust store is a hint about which arrangement you are in, not proof. Ask for the design rather than inferring it from a certificate chain.
Those two arrangements produce different answers to the question of who can read the page.
Compare proxy and VPN on the same four lines
The comparison only becomes useful when both deployments are described the same way.
| Line | What to state |
|---|---|
| Protected segments | Which hops are encrypted, and between which endpoints |
| Verified identities | What each end proves, and against which trust anchor |
| Trusted intermediaries | Who can read or alter traffic by design |
| Traffic included | Which processes and destinations the policy actually covers |
A proxy configured for one request covers that request. It does not send every process on the device through it, and the example command is exactly that narrow. A VPN's coverage depends on its routing and application policy, which also has to be inspected rather than assumed. Neither option covers everything simply because it was installed.
Write the four lines for each option and the argument usually resolves itself. The useful comparison is not which label sounds more encrypted. It is which segments are protected, who is verified at their ends, which intermediaries you trust, and what traffic the policy actually includes.