プロキシ利用時の証明書エラーを切り分ける
証明書の設定を変える前に、検証に失敗したのがプロキシ自体のTLS接続なのか、接続先サイトなのかを見極めます。
CAバンドルを変更する前に、どのTLSハンドシェイクが失敗したかを確認してください。プロキシの証明書とWebサイトの証明書は、別々の接続で検証されることがあります。
| プロキシと接続先 | TLSの検証 |
|---|---|
| HTTPプロキシ経由でHTTPSの接続先にアクセス | CONNECTの後、トンネルを通じて接続先の証明書を検証する。 |
| HTTPSプロキシ経由でHTTPSの接続先にアクセス | まずプロキシへのTLS接続を検証し、トンネルが開いた後、別の接続先TLSセッションを検証する。 |
詳細トレースで、要求されたホスト名と最後に完了したハンドシェイクを確認します。HTTPSプロキシの証明書検証は、Webサイトに接続する前に失敗する場合があります。その接続で意図している名前、証明書の有効期間、ローカルの時計、想定する証明書チェーン、承認されたトラストストアを調べてください。意図的に設定したTLSインターセプトや追加したルート証明書も調査に含めます。
curlには、これらの接続に対する個別のCAオプションがあります。
curl --proxy https://proxy.example:8443 --proxy-cacert proxy-ca.pem --cacert site-ca.pem https://example.com/--proxy-cacertはプロキシの信頼設定を、--cacertは接続先の信頼設定を指定します。例のエンドポイントとファイルを、意図する信頼構成に合わせて置き換えてください。システムの信頼設定で十分なら、独自のバンドルは不要です。
ホスト名を適当なIPに置き換えると、証明書の照合条件が変わります。検証を省略するとエラーを隠せても、接続相手の身元は確認できません。よく知らないプロキシからルートCAのインストールを求められても、それだけでは信頼する理由になりません。
ポートでの接続拒否やCONNECTの拒否は、それより前の段階の問題で、証明書を変更しても直りません。逆に接続先のTLS検証が済んだ後のWebサイトのHTTPエラーは、受信したレスポンスの問題です。CAをさらに調整する場面ではありません。