我们在Windows 2013服务器上托管了一个.NET WCF服务。通过HTTPS暴露的服务的SSL证书即将到期。生成了更新的证书并将其应用于服务器。
我们的所有.NET客户端应用程序继续正常运行，但是我们的基于Java的应用程序开始出现故障。有人告诉我，服务器管理员必须手动进入这些框并使用新更新的证书更新Java密钥库。
如果是真的，这会让我震惊。所有Web浏览器，.NET应用程序等...处理SSL证书更改而没有问题。将来，当证书最终再次更新时，您将如何防止使用Java密钥库这样的问题？在这方面，有什么方法可以让密钥库更"动态"？
Java客户端未能很好地处理新服务器证书的可能原因是这些客户端的Java版本已过时。
Java运行时环境（JRE）的每个安装都带有称为cacerts（在<java-home>/lib/security/cacerts）的 Trust Store 文件，其中包括所有运行的SSL/TLS客户端的所有证书授权（CA）和中间证书在JVM中将自动信任。如果您的新服务器证书是由不在客户端JRE的cacerts文件中的CA认证撰写/签名的，则客户端无法信任服务器并设置SSL/TLS连接将失败。
我假设.NET客户端直接使用基础Windows操作系统的受信任证书；如果启用了自动Windows更新，则很少努力将为客户提供新的CA证书。Web浏览器也是如此：它们经常通过自动更新保持最新。但是，在许多环境中，需要手动安装新的JRE版本（尤其是在Java应用程序服务器安装中），这意味着如果没有额外的努力，最新和最出色的CA证书可能不会立即获得。
您的服务器也有可能使用CA撰写的证书，该证书甚至最新的JRE版本的cacerts文件中都包含。在这种情况下，除了手动导入sysadmin外，别无选择。
您必须确保，用于签署证书的根证书已经在Java默认密钥库中受到信任。所有证书提供者可能并非如此。您可以使用命令
列出所有根证书keytool -list -keystore /path/to/your/keystore
然后将该列表与您的证书链进行比较。