如果中间证书的有效期比根证书更长，证书是否有效？

Question

我遇到了一个奇怪的问题，即 java 客户端无法连接到网络服务器，因为证书无效或在某种程度上不受信任，即使证书的有效性很好（至少我是这么认为的）：

CertificateException - java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors

经过一番谷歌搜索后，它说这是某些 JAVA 版本中的一个错误，如果中间版本的有效期比根 ca 的有效期长，就会发生这种情况。像下面这样的证书链有效吗？

  Issuer: O = Digital Signature Trust Co., CN = DST Root CA X3
        Validity
            Not Before: Jan 20 19:14:03 2021 GMT
            Not After : Sep 30 18:14:03 2024 GMT
        Subject: C = US, O = Internet Security Research Group, CN = ISRG Root X1
    
   Issuer: C = US, O = Internet Security Research Group, CN = ISRG Root X1
        Validity
            Not Before: Sep  4 00:00:00 2020 GMT
            Not After : Sep 15 16:00:00 2025 GMT // longer than the root ca
        Subject: C = US, O = Let's Encrypt, CN = R3
    
   Issuer: C = US, O = Let's Encrypt, CN = R3
        Validity
            Not Before: Aug 16 14:00:00 2023 GMT
            Not After : Nov 14 14:00:00 2023 GMT

Answer 1

Meta：不一定是编程或开发，但评论太长，我们已经有很多关于这个主题的内容了。

是的，根据 RFC5280，这是允许的；它要求每个证书的有效期包括验证时间（即 TLS 握手的“现在”），但不同证书的有效期不以特定方式相关。是的，某些 Java 版本中存在错误，错误地拒绝了这种情况（子期未“嵌套”在父期中），但那是在 2012 年（我知道，因为我仍然有一些在开发测试中使用的虚拟证书，我必须由于这个错误，然后重新发布）；我非常怀疑你现在会遇到它。

但是 DST X3 root （您不会显示；根通常不会在 TLS 握手中发送，而是从客户端的信任库提供）已于 2021 年 9 月过期；许多其他实现（不是 Java）要求根未过期，因此他们立即开始拒绝这个（LetsEncrypt）链，从那时起，我们在包括 SO 在内的多个堆栈上有很多 Q 和 As。 而且因为它过期了，大多数实现（也）将其从信任库中删除（包括 Java），这（显然！）阻止了该特定链的验证。 LetsEncrypt 从 DST/Identrust 获得了不寻常的过期桥证书，并继续使用它来支持旧的 Android 设备，这些设备 (1) 早于 LE/ISRG 的创建，并且无法添加其根，因为它们不再更新，并且 (2 ) 忽略 DST X3 过期（因为 Java）；请参阅 https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/ 。但他们计划明年最终放弃这一点，请参阅 https://letsencrypt.org/2023/07/10/cross-sign-expiration.html . 另一方面，

大多数实现，包括 Java，自 2017 年左右以来，都在其信任库中拥有 ISRG X1 的

root 证书（而不是使用 DST X3 的 bridge 证书），并且始终允许 TLS 客户端忽略服务器发送的除叶/EE 证书之外的链，并构建一个不同的链，在这种情况下到达有效（且未过期）的 ISRG 根 - 和 Java，或更具体地说 JSSE 的默认值 TrustManager ，这样做，所以它应该使用 LE 证书验证

 TLS 服务器并呈现仍然默认的“兼容性”LE 链，如您所示，我的所有 Java 应用程序都为我这样做。 （顺便说一句，您可能会注意到，StackExchange 本身（包括 SO）目前在这条链上使用 LE 证书。）

您的具体例外也令人惊讶。对于使用无效证书/链的服务器，JSSE 通常会失败，最终原因是 ... SunCertPathBuilderException: unable to find valid certification path to requested target

而不是

CertPathValidatorException: Path does not chain with any of the trust anchors

 ；它们在语义上相似但绝对不一样。看起来您正在以某种方式修改标准信任逻辑，并且很可能是该修改导致了错误。在这种情况下，为了获得帮助，您应该展示问题的最小可重现示例。