検査プロキシのどちら側が証明書を拒否したのか

クライアントは承認済みの検査プロキシを信頼している。それでも証明書エラーでリクエストは失敗する。両方は成り立ちうる。そのプロキシには検証すべき別の TLS 関係がある。

client -- TLS to approved intermediary -- proxy -- TLS to website -- destination

傍受の構成では、中間者がクライアントの TLS を終端し、先方への独自の接続を作る。クライアントは自分の側で提示された証明書を受け入れられる一方、プロキシはウェブサイトから受け取った証明書を拒否する。

検証側のエラーを読む

失敗したチェーンまたはホスト名を報告したプロセスを特定する。プロキシが生成したエラーページは、有効な接続でクライアントに正常に届くことがある。クライアントの CA ファイルを再び変更しても、プロキシの上流信頼設定は更新されない。

たとえば Mitmproxy は、ssl_verify_upstream_trusted_ca を含む上流信頼の個別オプションを文書化している。適切な管理者は検証を維持したまま上流サービスに承認済みの信頼を設定できる。別のプロキシ製品には対応するインターフェースが必要だ。

実際の宛先名とチェーンも確認する。中間証明書が欠けたプライベートサービス、期限切れの証明書、認識されないプライベート発行者はそれぞれ別の修復を要する。あるプライベートサービス向けの意図的な例外が、いつのまにか全証明書の全面受け入れになってはならない。

不透明な転送トンネルはこのように宛先 TLS を分割しない。通常、アプリケーション自身がそのエンドツーエンドの TLS セッションを交渉し検証する。検査プロキシの設定を任意の中間者に適用するのではなく、まず傍受が本当に経路の一部かを確認する。

両方の検証結果を別々に記録する。「プロキシの証明書は信頼されている」はクライアント側の問いに答えるが、上流へ接続したときにプロキシが見たものを証明するものではない。