プロキシ経由でクライアント証明書を送信するのは誰か？
宛先の mTLS 資格情報を、プロキシの資格情報や Apache が独自の上流 TLS セッションを作成するときに使う証明書とは分けて管理します。
通常の CONNECT 経由の HTTPS では、アプリケーションが宛先との TLS ハンドシェイクの中で Web サイトのクライアント証明書を送信します。プロキシはバイトを中継するだけで、自動的に Web サイトの TLS クライアントになるわけではありません。
| 資格情報 | 所有者／接続 |
|---|---|
| プロキシのユーザー名／パスワード | クライアントからプロキシへのアクセス。 |
| Web サイトのクライアント証明書と秘密鍵 | アプリケーションと宛先の TLS セッション。 |
| プロキシサーバーの上流クライアント証明書 | プロキシ自身が開始する TLS セッション。 |
これらの役割は共存できます。宛先への mTLS を機能させるために、Web サイトの秘密鍵を単純なトンネリングプロキシへアップロードする必要はありません。CONNECT の引き渡しの後は、アプリケーションの通常の宛先クライアント証明書設定を使い、Web サイトのサーバー証明書の検証を続けてください。
Apache の SSLProxyMachineCertificateFile は、Apache が独自の上流 TLS セッションを作成するときに資格情報を提供します。このファイルに関する助言は、不透明なフォワードトンネルを使うすべてのクライアントがそれを設定しなければならないことを証明するものではありません。
TLS 傍受は中間者でセッションを終了させ、この所有関係を変えます。証明書をコピーすれば端から端までの認証が保たれると仮定するのではなく、必要なクライアント ID がその構成を通り抜けられるかを確かめてください。
障害が起きたら、リクエストがプロキシのログイン、宛先の TLS、その後のアプリケーション交換のどこで止まったかを記録します。資格情報は、実際にそれを要求する接続に置いてください。