サーバーに到達するロードバランサーを構成するためにSSL秘密キーを必要とするクライアント。理にかなっていますか？
異常な状況に直面しています。これを明確にしていただければ幸いです。
サーバーXのポート443でHTTPSリクエストを介してアクセスできるいくつかのアプリケーションを管理します。
サーバーXの443ポートを介して到達するはずの新しいクライアントがあります。ただし、クライアントは、ある種のロードバランサー（プロキシ+ snatに従って）を使用してこれを行います。
ロードバランサーが私たちに接続できるようにするためクライアントは公開証明書+秘密キーのペアを必要とします。そうでない場合、ロードバランサーはキーペアの不一致のために私たちとの接続をリセットします。
プライベートは単にプライベートである必要があるため、これは完全にナンセンスです。共有することはできません。これは、私が知っているすべてのセキュリティポリシーに違反しています。
興味深い点は、彼らがこれを正確に述べているように見えるいくつかのドキュメントを提供したことです。これはリンクです：
https://support.f5.com/csp/article/K1339
彼らはBig IPと呼ばれるいくつかの技術を使用しているようであり、上記のリンク上のこの声明によると秘密鍵が必要です：
推奨されるアクションこのエラーを修正するには、影響を受けるSSLプロファイルを、宛先サーバー。これを行うには、次の手順を実行します...
これに似た状況に直面した人はいますか？
彼らのテクノロジーでも本当にそれが必要ですが、以前はロードバランサーによって暗号化されていたトラフィックを処理するHTTPSによって提供される「API」については知らないので、かなり混乱しています。
あらゆる種類の説明が役に立ちます。みんな、ありがとう。
F5のSSLプロキシ機能を使用しているようです。つまり、F5アプライアンスはアプリケーションのクライアントではなく（アプライアンスで終了せず、通過する）、代わりにトラフィックを復号化する機能を提供します。パフォーマンスを改善するためにキャッシュして再利用できるかどうかを判断します。たとえば、エッジで何かをキャッシュできる場合、Originサーバーに追加の完全なラウンドトリップを行わなくても、ユーザーにそれを提供できます。トラフィックを解読できない場合は、キャッシュできません。
これは、ご存じのとおり、セキュリティに影響を与えます。彼らがこのアーキテクチャを主張し、データとリスクが彼らと彼らのものだけである場合、共有されないアプリケーションに固有の証明書が必要です他の顧客のデータを保護します。次に、ホストするアプリケーションサーバーに証明書をインストールし、F5にインストールできます。他の顧客が誤って証明書を使用する機会がない限り、リスクはほとんどありません。君は。
[〜＃〜] if [〜＃〜]ただし、アプリケーションはではないそのような方法で分離されており、証明書をそれらの使用のためだけに分離することはできません。その場合、私の意見では、あなたは拒否する必要があります。いかなる状況でも他の顧客のデータにアクセスする可能性のあるキーを顧客に与えることはできません。