JDK 捆绑 TrustManager

Question

我想要一个加载了 JDK 捆绑信任材料的 TrustManager 实例 （指的是 JDK 更高版本中位于

lib/security/cacerts

文件中的材料）。 理想情况下，该解决方案应该适用于 JDK8 及更高版本。

我必须承认，我发现这个看似非常简单的请求实际上非常复杂。这让我怀疑我是否以正确的方式处理这件事。

这是我看到的障碍：

• 如上所述，我想要捆绑的信托材料。这意味着无论用户可能已将哪些系统属性添加到 JRE 执行中。
• 我相信

  cacerts

  文件的位置在不同的 JDK 之间发生了变化？
• 我相信

  cacarts

  文件的存储类型在不同的 JDK 之间发生了变化？
• 我相信

  cacerts

  文件的密码在不同的JDK之间已经改变了？

我真的不想处理 JDK 之间的所有这些差异。我相信我不应该。我相信我的要求是合理的。有人可能已经解决了这个问题，或者 JDK 提供了一种方法来解决我忽略的问题？

感谢您提供的任何指示或帮助。

Answer 1

退一步。任务是获取 JDK 捆绑的精选 CA 证书集。然而，根本目标实际上是让应用程序仅使用某种精选的 CA 证书集，类似于浏览器的做法。它不一定需要是 JDK 定义的集合。我们所说的“策划”是指有一个深思熟虑的持续流程，以确定哪些 CA 证书包含在集合中，并且该流程由值得信赖的组织管理。

在 Java 中获取 JDK 的 unmodified

cacerts

文件几乎是不可能的。这是 JDK 21 文档 对于

cacerts

文件的说法：

cacerts 证书文件

名为 cacerts 的证书文件位于安全属性目录中：

   Linux and macOS: JAVA_HOME/lib/security

   Windows: JAVA_HOME\lib\security

cacerts 文件代表具有 CA 证书的系统范围密钥库。系统管理员可以通过指定 jks 作为密钥库类型，使用 keytool 命令配置和管理该文件。 cacerts 密钥库文件附带一组默认的根 CA 证书。对于 Linux、macOS 和 Windows，您可以使用以下命令列出默认证书：

   keytool -list -cacerts

cacerts keystore 文件的初始密码为changeit。系统管理员应在安装 SDK 时更改该密码和该文件的默认访问权限。

注：

验证您的 cacerts 文件非常重要。由于您信任 cacerts 文件中的 CA 作为向其他实体签名和颁发证书的实体，因此您必须仔细管理 cacerts 文件。 cacerts 文件应仅包含您信任的 CA 的证书。您有责任验证 cacerts 文件中捆绑的受信任根 CA 证书并做出自己的信任决定。

要从 cacerts 文件中删除不受信任的 CA 证书，请使用 keytool 命令的 -delete 选项。您可以在 JDK 的 $JAVA_HOME/lib/security 目录中找到 cacerts 文件。如果您无权编辑此文件，请联系您的系统管理员。

这似乎是个坏建议：不应该更改 JDK 安装的内容。恕我直言，它应该被视为不可变。另外，我认为“changeit”密码注释不再正确。

底线是 - 如果有人接受这个建议 - Java 应用程序无法确定它使用什么

cacerts

文件，或者是否可以读取文件中的证书。

当然，在拥有容器等现代技术的今天，我可以非常确定我的应用程序运行在未经修改的 JDK/JRE 安装之上，因此我可以自信地处理

cacerts

。

但展望未来，我希望 JDK 能够提供一种方法来获取“未修改”的捆绑 CA 集。我还希望他们停止鼓励在安装后更改 JDK/JRE 安装树。即使没有人再关心了。 最后，应用程序的另一个选择是捆绑

其他人

策划的一组 CA 证书，例如 Mozilla CA 证书集。