Java 相同的JKS文件具有密钥存储和信任存储的优点

应用程序A调用webservice应用程序B

相互认证

我们有申请证书。由名为C的CA签名的证书。这是jks文件中唯一的单个证书内容

我们使用了相同的jks文件作为应用程序密钥库和信任库。它工作得很好

我的理解是，当应用程序A调用appB时，appB将发送其证书，该证书也由名为C的CA签名。 appA接受此证书，因为在appA TrsStore中，我们有另一个证书，该证书由同一个名为C的CA签署

然后，当appA向appB发送证书作为客户端身份验证的一部分时，同样的情况也会发生

---

对SSL的这种理解正确吗。你们能给点建议吗。谢谢

这是正确的理解，但用法不正确。密钥库是私有的。它包含您的私钥。信任库只包含公共证书。您不应将同一文件用于两个目的。你的身份和你信任的人是两个完全不同的问题。

Hi@EJP，谢谢你的回复，这是我不清楚的地方。我在其他线程中也看到了类似的私钥问题。因为jks只包含一个证书。根据我的学习理解，证书仅包含公钥。所以，我们这里不应该有任何安全问题，对吗？keystore和trustore jks都只有公钥，因为它只是证书。在我看来这是错的吗。读我写的。密钥库包含您的私钥。您首先创建了一个密钥对，然后生成了一个CSR，然后对其进行了签名，然后导入了已签名的证书。您好@EJP，谢谢，我对SSL还有一个疑问。在某种程度上，SSL向客户端提供了服务器证书，客户端验证证书上的CAname是trustore的一部分。如果这是真的，请验证，不管服务器B是否真的是B，这都是通过DigitalSignature完成的。这是我的疑问。谁的私钥用于进行数字签名？是CA的私钥还是服务器B的私钥。因为如果使用了CA的私钥，它只能验证CA是否真的是声称它是的人。只有使用了serverB的私钥，我们才能说，文档来自serverB，对吗？服务器的私钥。服务器没有CA的私钥。私钥是，呃，私钥。这就是系统的工作原理。这就是为什么服务器不应该拥有客户端的私钥，客户端也不应该拥有服务器的私钥。这就是为什么你不应该共享密钥库。谢谢@EJP的澄清