openssl s_client がプロキシへの CONNECT 要求に対して HTTP 403 を受け取ったら、まずその拒否から考えます。 要求したトンネルは確立されていません。

-proxy を付けると、s_client はまず HTTP プロキシに -connect で指定した宛先への接続を求めます。CONNECT が成功した応答だけが、このやり取りを宛先の TLS ハンドシェイク用のトンネルに切り替えます。

この順序を押さえると、そうでなければ紛らわしい出力が説明できます。プロキシのエラーに続いて TLS 関連の見出しが並ぶ、ピア証明書がない、あるいは安心させるように見える検証行が出る、といった場合です。これらの項目は、宛先の証明書を受信して検証したことを示しません。処理はもっと前の段階で止まっています。

プロキシの応答と、要求した宛先のホストおよびポートを記録します。403 はプロキシのアクセス判断に注意を向けさせ、407 はプロキシ認証を要求します。どちらも宛先証明書の検証を無効にしても直りません。

やり取りの調査が許されている場合、s_client の -debug 出力は拒否の内容を明らかにする助けになります。プロキシの資格情報は共有されるトレースに残さないでください。トンネルが成功しても、その後に独自の TLS と証明書の評価が改めて必要ですが、その段階に実際に到達するまでは診断すべき宛先証明書チェーンは存在しません。

関連記事