【问题标题】:Is it a bad practice to use Java standard keystore使用 Java 标准密钥库是一种不好的做法吗
【发布时间】:2011-12-15 06:21:06
【问题描述】:

我们一直使用 java 标准密钥库 ($JAVA_HOME/jre/lib/security/cacerts) 作为 tomcat 的可信存储。该tomcat服务器将与其他一些服务器通信。最近的 OS(AIX) 升级显然覆盖了$JAVA_HOME/jre/lib/security/cacerts 的文件,导致证书丢失以及托管在 tomcat 中的应用程序出现许多问题。

看看这是不是在 $JAVA_HOME/jre/lib/security/cacerts 上中继是一种不好的做法? 解决这种情况的替代(更好|标准)方法是什么?

【问题讨论】:

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

标签: java tomcat ssl truststore


【解决方案1】:

如果您有一个会重复导入的构建过程,这不是一个坏习惯。

【讨论】:

    【解决方案2】:

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

    默认情况下,在 Websphere 中,密钥库以这种方式工作,因为它带有自己的 JVM :)

    【讨论】:

    • GlassFish 也有自己的密钥库和 cacerts。
    【解决方案3】:

    cacerts 文件中的内容而言,这不一定比依赖安装在您的操作系统或浏览器中的默认 CA 证书更糟糕,但这并不意味着它很好。

    Sun/Oracle 在JSSE Reference Guide about this 中间的某处有一点“重要说明”:

    重要提示:JDK 附带有限数量的受信任根 /lib/security/cacerts 文件中的证书。作为 记录在 keytool 中,您有责任维护(即, 添加/删除)如果您使用此文件中包含的证书 文件作为信任库。

    根据您联系的服务器的证书配置, 您可能需要添加额外的根证书。获取所需 来自相应供应商的特定根证书。

    在配置方面,对于必须安装“本地”CA 证书的特定应用程序,我发现使用本地信任存储(例如,使用javax.net.ssl.trustStore 指定)更稳定。

    【讨论】:

      【解决方案4】:

      是的,这样做是一种不好的做法。

      最佳做法是根据需要限制您的受信任证书。
      因此,您应该使用自己的密钥库,其中仅包含应用程序信任的证书。

      【讨论】:

      • 这违反了 PKI 的全部目的。这个想法是可信根的存在允许形成信任链,以便您可以信任由可信 CA 签名的任何证书。您将身份验证(PKI 和证书的用途)与授权(应用程序域问题)混为一谈。将这两个独立的功能结合起来从根本上被破坏了。
      • @EJP:当您有一个仅与网络中的特定实体通信的端点时,为什么我会允许信任我系统中配置的 any CA 信任的证书(是linux、java的ca证书、windows证书等)?
      【解决方案5】:

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

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2011-12-12
        • 1970-01-01
        • 2010-12-22
        • 2018-10-03
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多