java google reCaptcha端点有多少HTTPS证书？我在哪里可以下载？

Question

我们有一个java web应用程序，它在docker的一个微服务中对URL https://www.google.com/recaptcha/api/siteverify执行reCaptcha验证，这已经工作了将近2年，但本周二2021年6月8日，该应用程序开始抛出此异常：

Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
        at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:439)
        at java.base/sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:306)
        at java.base/sun.security.validator.Validator.validate(Validator.java:264)
        at java.base/sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:313)
        at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:222)
        at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:129)
        at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1340)
        ... 89 common frames omitted
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
        at java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
        at java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
        at java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
        at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:434)
        ... 95 common frames omitted

我们发现JVM 11中的证书是GlobalSign之一，但名称以“R2”结尾：

Certificate R2 in truststore

在某些情况下，返回的“Ender1”与“Ender1”的名称相同：

Certificate R1 not in Truststore

添加此证书R1后，应用程序开始正常工作，但同一个端点返回两个不同的证书是否正常？我如何在我的信任库中获取或添加所有这些可能的证书？我们是否需要添加证书池

提前谢谢

Answer 1

还没有答案对于真正的问题，不仅要“这很正常”，而且评论太长了

一个SSL/TLS服务器可能有多个证书，并在连接请求时提供不同的证书，尽管对于同一域名这样做会很奇怪；这在支持多个域的服务器上更常见，这些域可以用于一个实体的不同部分或服务，也可以用于CDN或Cloudflare或Fastly之类的前端（！）它处理多个实体的连接。然而，在www.google.com的具体情况下，这不是一个单一的服务器，而是全世界成百上千的服务器，而且很可能不同的服务器有不同的证书，或者是有意的（可能是为了测试），或者是因为它们正在进行一种不会在任何地方立即发生的更改

根据我最近的笔记www.google.com从我的位置访问时使用了GTS CA 1O1下的this intermediate cert和GlobalSign Root CA - R2下的this intermediate cert证书，如第一张图片所示。请注意，中间证书将在6个月后过期，它所在的根证书也将过期，这是停止使用它的一个很好的理由。（https://crt.sh/?caid=10确实显示了GlobalSign Root CA（见下文）下R2的两个过期时间较长的“交叉”证书，但它们都被撤销。）

从今天起，我在GTS CA 1C3下得到了一个证书，在GTS Root R1下得到了一个证书，就像你的第二个数字一样，但是在GlobalSign Root CA下没有R1的交叉。具体地说，我得到了this intermediate cert代表GTS CA 1C3和this cross cert代表GTS Root R1，它们的有效期到2027年和2028年，分别以GTS CA 1C3和GTS Root R1 Cross的形式出现。以及this cert对于实际上是R1的GlobalSign根，因为目前已知的其他GlobalSign根是R2-6，但是没有命名R1至少已经在Java和Mozilla/Firefox信任库中存在很长时间了；我不能轻易查到别人的历史crt.sh doesn't know of ANY cert named with R1。我要指出的是，Firefox的信任库中确实有一个GTS Root R1（以及R2-R4）的根证书，这意味着它可以缩短链，但没有；AFAICS任何Java都没有这些GTS根

此外，我得到的叶证书既有CommonName，也有SubjectAltName www.google.com而不是*.google.com。这几乎证实了你得到的服务器与我的不同

如果你能提取你在某个信任库中明显拥有的“GlobalSign R1”证书，并将其发布以供查看或搜索，以及你可以通过keytool -printcert -rfc -sslserver www.google.com和/或如果你能识别哪个谷歌地址，这可能会有所帮助你可以从其他人（比如我）那里获得这个证书链，尽管即使是一个地址也可能向多个物理服务器进行任意广播