在按需处理多组身份时，我正在寻找在客户端身份存储中不太常见的 SSL 使用的最佳实践。
让我说清楚，这个问题是关于密钥库（Java）的客户端处理。
由于这是我第一次处理 SSL，我的研究使我更倾向于常见的最佳实践，例如：
- 有一个单独的密钥库供您信任。（例如。
truststore.jks） - 您身份的单独密钥库。（例如
keystore.jks- 私钥）
这部分很清楚，当我考虑浏览器证书如何在我接受服务器证书的情况下工作时，它完全有意义，同时服务器识别我的证书（身份），甚至在更酷的 Firefox 中，因为它允许我选择要出示的证书。
通过代码，我依赖于使用，Keystore.load(FileInputStream)因此我在构建我的SSLSocketFactory（apache）之前实际上选择了要使用的信任和密钥库。
所以一切都很好，但从商业角度来看，这就是复杂性，我的 web 应用程序在任何给定时间都支持 N-Identities。这些身份甚至可以在单个会话中切换。我在这里指定身份是因为这些身份可能与托管站点具有不同的privateKey + cert合同。从某种意义上说，它们的有效性（例如有效期至 350 天）会有所不同，并且RDN（例如CN=Foo, OU=Foo，等）肯定会有所不同。
所以我的第一次尝试是创建一个巨大的密钥库并在那里导入所有东西——只要它们有唯一的别名。起初这没问题，但是对于每个具有新合同的新主机，必须再次重新加载不同的密钥，现在我遇到了别名映射问题。
所以这是另一种选择，我正在考虑为每个身份创建单独的文件存储路径。所以本质IdentityA上去去去去D:\security\<b>A</b>\keystore.jks等等B等等。A和B的附加私钥可以加载到各自的密钥库中。当然，所有身份的信任库都是相同的，但它们的密钥库将在需要时进行查找和加载。
我不能 100% 确定我所采取的方向是否是处理这些情况的最佳方式，但我想从其他很可能已经遇到类似情况的人那里获得一些意见。