使用Java标准密钥存储库是不好的做法

我们一直在使用java标准密钥存储库（$JAVA_HOME/jre/lib/security/cacerts）作为tomcat的可信存储区。那个tomcat服务器会和其他服务器通信。最近的一次操作系统（AIX）升级显然覆盖了文件$JAVA_HOME/jre/lib/security/cacerts，导致丢失的证书以及tomcat中托管的应用程序的许多问题。使用Java标准密钥存储库是不好的做法

看着这是在$ JAVA_HOME/jre/lib/security/cacerts上转发的坏习惯吗？什么是替代（更好|标准）的方法来解决这种情况？

来源

2011-10-25 ring bearer

java_home可能会因平台而异，您将需要注意这一点。我个人会搜索不同的配置单元文件夹。 – Tim

对于cacerts文件中的内容，与使用安装在操作系统或浏览器中的默认CA证书相比，这不一定是糟糕的做法，但这并不意味着它很好。

太阳/ Oracle的有一点点的“重要提示”中的JSSE Reference Guide about this中间的某个位置：

重要说明：JDK附带受信任的根证书的/ lib/security中的有限数量/ cacerts文件。由于keytool中记录了，因此如果您将此文件用作信任库，则您有责任维护（即，添加/删除）此文件中包含的证书。

根据您联系的服务器的证书配置，您可能需要添加其他根证书。从相应的供应商处获取所需的特定根证书。

在配置方面，对于我已经安装的“本地” CA证书的具体应用，我觉得它更稳定，使用本地信任存储（例如，与javax.net.ssl.trustStore指定）。

来源

2012-01-18 02:32:57 Bruno

不确定，但假设您的假设是正确的，请注意放置密钥库的位置。我强烈建议将它放在Apache文件夹中。

默认情况下，在WebSphere密钥库以这种方式工作，因为它带来了它自己的JVM :)

来源

2011-10-25 20:31:29

GlassFish也拥有自己的密钥仓库和cacerts。 – Hiro2k

如果你有一个构建过程将重复进口这不是一个不好的做法。

来源

2011-10-25 23:13:28 EJP

是的，这样做是不好的做法。

最好的做法是必须根据需要限制您的可信证书。
所以你应该使用你自己的密钥库，只有你的应用程序信任的证书。

来源

2011-10-28 20:05:40 Cratylus

这违反了PKI的全部目的。这个想法是，信任根的存在允许形成一个信任链，以便您可以信任由受信任的CA签名的任何证书。您正在认证中，这是PKI和证书的用途，授权是一个应用程序域问题。将这两个单独的功能结合起来基本上被打破了。 – EJP

@EJP：当你有一个端点仅与网络中的特定实体进行通信时，为什么我会允许被我系统中配置的任何* CA信任的证书信任（无论是linux，java的ca证书，Windows证书等等）？ – Cratylus

AIX升级是一个补丁。任何补丁都不得删除/覆盖用户数据。我建议受此类数据丢失影响的用户请IBM修复修补程序。相比之下，httpd服务器的补丁即使在程序目录中也不会覆盖/删除配置。

来源

2016-02-21 23:09:00 user250343

使用Java标准密钥存储库是不好的做法

回答

相关问题