オンデマンドで複数の ID セットを処理するときに、クライアント側の ID ストアで SSL をあまり一般的ではない方法で使用するベスト プラクティスを探しています。
はっきりさせておきますが、この質問はクライアント側のキーストア (Java) の処理に関するものです。
SSL を扱うのはこれが初めてなので、調査の結果、次のような一般的なベスト プラクティスの方向に進みました。
- 信頼のために別のキーストアを用意してください。(例
truststore.jks) - ID 用の別のキーストア。(例
keystore.jks- 秘密鍵)
この部分は非常に明確であり、サーバーの証明書を受け入れ、同時にサーバーが証明書 (ID) を認識するブラウザー証明書のしくみを考えると、完全に理にかなっています。提示する証明書を選択します。
コードを通じて、 (apache)Keystore.load(FileInputStream)をビルドする前に使用するトラストとキー ストアを実際に選択できるように、の使用に依存していました。SSLSocketFactory
すべてがうまくいっていますが、ここに複雑さがあります。ビジネス用語では、私の webapp は常に N-Identities をサポートしています。これらの ID は、1 回のセッションで切り替えることもできます。ここで ID を指定しているのは、これらの ID がホスティング サイトとの異なるprivateKey + certコントラクトを持つ可能性があるためです。それらの有効性 (例: 350 日まで有効) が異なり、間違いなくRDN (例:CN=Foo, OU=Fooなど) が異なるという意味で異なります。
したがって、私の最初の試みは、1 つの巨大なキーストアを作成し、そこにすべてをインポートすることでした (一意のエイリアスがある場合)。これは最初は問題ありませんでしたが、新しいコントラクトを持つ新しいホストごとに、異なるキーを再度リロードする必要があり、エイリアス マッピングの問題が発生しています。
ここに別の方法があります。IDごとに個別のファイルストアパスを作成することを考えています。本質的IdentityAにはD:\security\<b>A</b>\keystore.jks、B行ったり来たりします。AおよびBの追加の秘密鍵は、それぞれのキーストアにロードできます。もちろん、トラストストアはすべての ID で同じですが、キーストアは必要に応じて検索およびロードされます。
私が取っている方向がこれらのシナリオに対処するための最良の方法であるかどうかは 100% 確信が持てませんが、おそらくすでに似たようなことに遭遇した可能性が高い他の人々からいくつかの意見を得たいと思います.