OpenSSL で HTTP プロキシ経由の Web サイト証明書を確認する
HTTP CONNECT プロキシ経由で OpenSSL s_client を使い、接続先名、SNI、証明書検証を一致させます。
s_client に対応したインストール済みの OpenSSL -proxy を使います。承認された HTTP CONNECT エンドポイントでは、次のようにします。
openssl s_client -proxy proxy.example:3128 -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error -showcertsプロキシアドレスを置き換え、意図した接続先名を一貫して使います。選択可能なプロキシ経由で公開接続先を試す場合は、HTTP プロキシ一覧から候補を選びます。-connect は対象を選び、-servername は TLS 仮想ホスト向けに SNI を送り、-verify_hostname は識別情報を確認します。SNI だけではホスト名検証になりません。オプションを調整するときは インストール済みリリースのマニュアルを確認してください。
-showcerts はサーバーが送信した内容を表示しますが、チェーンが信頼されるとは宣言しません。-verify_return_error は検証エラーで handshake を終了させます。そうでなければ診断クライアントはエラー後も続行できます。プライベートサービスには、任意にダウンロードした証明書を信頼するのではなく、承認済みの CA マテリアルを使います。
| 結果 | 段階 |
|---|---|
| 407 | 宛先 TLS 前のプロキシ認証。 |
| 拒否された CONNECT 宛先 | プロキシの宛先ポリシー。 |
| 証明書を受信し、検証を試行 | 受け入れられたトンネルを通じた宛先 TLS 交換。 |
OpenSSL 3.x と Basic 認証を使う HTTP プロキシでは、宛先検証を維持しながら s_client のプロキシアカウントオプションを使います。
SOCKS 専用のエンドポイントは、このコマンドが使う HTTP プロキシインターフェイスを提供しません。承認された TLS 介入では、表示された証明書がその中間者によって発行されている場合があります。違いを壊れた Web サイトのせいにする前に、発行者と意図した信頼構成を比較してください。