【问题标题】:Need help setting up a truststore's chain of authority (in Tomcat)需要帮助设置信任库权限链(在 Tomcat 中)
【发布时间】:2010-05-29 15:21:18
【问题描述】:

引入... 到目前为止,我不是 SSL 应用程序安全方面的专家,但我正在尝试建立一个测试环境,其中包括我们在生产中可能遇到的所有可能场景。为此,我有一个证书颁发机构 (CA) 树,它们是各种测试客户端证书和节点/服务器证书(代表各种已发布 Web 服务和我们与之集成的其他应用程序的复杂测试环境)的颁发者。

这些 CA 的结构如下: 根 CA,已签署/颁发 Sub CA1、Sub CA2 和 Sub CA3。这些潜艇随后签署/颁发了环境中这些不同节点和客户端的所有证书。

现在问题.... 在我的应用程序的信任库中,我想信任由 Sub CA1 和 Sub CA2 签名的所有内容,但不信任 Sub CA3(不受信任)。这是否意味着我的信任库应该 (1) 仅包含 Sub CA1 和 Sub CA2,或者 (2) 它应该包含 Root CA、Sub CA1 和 Sub CA2?

我不知道在信任库中表示此信任链的正确方法是什么。将来我还想添加一个 Sub CA4(也由根 CA 签名/颁发),但将其添加到证书撤销列表 (CRL) 以进行测试。

提前感谢您对此提供的任何帮助。非常感谢。

【问题讨论】:

    标签: java tomcat ssl certificate-authority truststore


    【解决方案1】:

    CAVEAT:我不打算对此进行测试,所以我希望我的答案是正确的。

    我认为你的基本假设是正确的。我不相信您可以在不编写自定义代码的情况下选择性地撤销信任,因此您的信任库应该只包含完全受信任的证书。所以离开根 CA 并选择您的选项 (1)。

    如您所见,试图强制执行这种细粒度的访问控制并不适合 Java(以及大多数其他系统的)基于 X509 证书的身份验证模型。它们基本上旨在将身份验证外包给 Verisign、Thawte、GoDaddy、GlobalSign 等,用于 SSL 证书和代码签名证书。它可以支持其他模型,包括自签名证书,但并非没有相当大的前期痛苦和持续的维护难题。

    【讨论】:

      猜你喜欢
      • 2014-09-28
      • 2012-10-10
      • 1970-01-01
      • 2011-09-18
      • 2012-11-06
      • 1970-01-01
      • 1970-01-01
      • 2021-12-13
      • 2010-12-08
      相关资源
      最近更新 更多