Question

我正在尝试实现一个自定义X509TrustManager，告诉用户该证书，并让他们能够在问题出现时继续使用服务器。

我已将几乎所有内容联系在一起，并开始针对badssl.com上的各种证书进行测试。

当我在Safari中访问expired.badssl.com时，我看到三个证书：

* COMODO RSA Certification Authority
    * COMODO RSA Domain Validation Secure Server CA
        * *.badssl.com

我的应用程序获得了完整的链条。

当我访问wrong.host.badssl.com时，Safari仍显示三个证书，但我的应用程序只看到两个：

* DigiCert Global Root CA (Not in the array passed to the method!)
    * DigiCert SHA2 Secure Server CA
        * *.badssl.com

我假设我可以使用“DigiCert SHA2安全服务器CA”证书中的“颁发者”名称以某种方式查找根证书，但我在哪里找到它？

Answer 1

用于验证服务器链（或通常任何收到的链）的根证书应该在本地信任库中找到。这正是默认TrustManager所做的 - 它在本地信任库中查找，或者更确切地说它实例化了CertPathValidator，其中{通常}默认为PKIXValidator truststore（包含证书条目的KeyStore）通常从默认为JRE/lib/security/cacerts的本地文件初始化，然后通过使用HashMap按主题名称查找来自所述信任库的根来执行验证。 / p>

虽然简短地说明了in RFC 5246 for TLS 1.2（1.1分为4346分，1.0分为2346分）。

如果你仔细观察，你会发现这些案件实际上与你想象的不同。

wrong.host.badssl.com提供由以下内容组成的证书链：
* https://crt.sh/?id=205900989 leaf * .badssl.com由DigiCert SHA2 SecServerCA发布 * https://crt.sh/?id=1262388由DigiCert GlobalRootCA发布的中间体它使用带有SHA1指纹A8985D3A65E5E5C4B2D7D66D40C6DD2FB19C5436的根https://crt.sh/?id=853428，您可以在大多数（如果不是所有）通用信任库中找到它们，包括Java（至少Oracle / Sun Java，OpenJDK可能因其构建方式而异）。请注意，对*.badssl.com wrong.host.badssl.com有效的此证书对expired.badssl.com失败，因为证书通配符 - 名称匹配仅使一个（最左侧）DNS标签不多（这需要两个）。

static提供由以下内容组成的证书链：
* COMODO RSADomainValCA发布的https://crt.sh/?id=7176112 leaf * .badssl.com 由COMODO RSACertAuth发布的https://crt.sh/?id=3509153中间体 * https://crt.sh/?id=1044348桥梁由AddTrust ExternalRoot发布2000年（直到2020年）发送时使用带有SHA1指纹的AddTrust根https://crt.sh/?id=1 02FAF3E291435468607857694DF5E45B68851868。但是，COMODO RSA现在拥有自己的根https://crt.sh/?id=1720081，日期为2010年（直到2038年），SHA1指纹AFE5D244A8D1194230FF479FE2F897BBCD7A8CB4被广泛接受 - 包括Oracle Java开头8u51。（AddTrust External可以追溯得更远，至少6u07这是我能够轻松查看的最旧版本。）我敢打赌如果你看到你会发现Safari 替换了顶部COMODO RSA的桥接证书收到的链与（COMODO RSA）根;允许任何relier做这种快捷方式，我的（几乎是当前的）Firefox，IE和Chrome / Windows都在这种情况下。（后两者共享Windows信任库; Firefox使用Mozilla。）

（PS用于检查单元：我使用SHA1指纹，因为它们更容易切割和粘贴，并且仍然足够好 - 已经找到了一些数据的SHA1冲突，但没有找到因为签名相关性，无论如何只有第二张图像实际上是一个问题而AFAIK根本就没有任何进展。）

由于上面引用的RFC，您的标题中的问题，“仅给出叶子证书”，不应该在TLS中出现。但如果确实如此，这几乎是OpenSSL generate certificate chain的重复，并且适用相同的逻辑：跟随CAIssuers，或者（在运气时）连接CT日志 - 就像我手动完成上述操作一样！

如何获得可能只提供叶证书的证书链？

1 个答案: