OpenSSL s_client Proxy 403 Happens Before Destination TLS
Interpret an OpenSSL proxy CONNECT 403 as a tunnel-stage failure and avoid diagnosing a destination certificate from a handshake that never started.
If openssl s_client receives HTTP 403 in response to its proxy CONNECT request, start with that refusal. The requested tunnel has not been established.
With -proxy, s_client first asks the HTTP proxy to connect to the destination specified by -connect. Only a successful CONNECT response switches that exchange into a tunnel for the destination TLS handshake.
This ordering explains an otherwise confusing output: a proxy error followed by TLS-related headings, no peer certificate, or an apparently reassuring verification line. Those fields do not establish that the destination's certificate was received and verified. The operation stopped at an earlier stage.
Record the proxy response and requested destination host and port. A 403 directs attention toward the proxy's access decision; a 407 requests proxy authentication. Neither is repaired by disabling verification of the destination certificate.
When permitted to inspect the exchange, s_client's -debug output can help expose the refusal. Keep any proxy credentials out of shared traces. A successful tunnel would still need its own TLS and certificate assessment afterward, but there is no target certificate chain to diagnose until that stage has actually been reached.