☰

openssl：无法获取 accounts.google.com 的本地颁发者证书

tag-icon • tag-icon ssl ssl-certificate openssl
openssl：无法获取 accounts.google.com 的本地颁发者证书

我正在获取unable to get local issuer certificateSSL accounts.google.com。我从以下网址下载了更新 CA 文件：https://curl.haxx.se/ca/cacert.pem并使用openssl s_client来渲染：

➜  ~ openssl s_client -connect accounts.google.com:443 -CAfile ~/certs/cacert.pem
CONNECTED(00000003)
depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=accounts.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEoTCCA4mgAwIBAgIIZMJyEcZ8LIAwDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE
BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbnRl
cm5ldCBBdXRob3JpdHkgRzIwHhcNMTcwMzE2MDkxNjU0WhcNMTcwNjA4MDg1NDAw
WjBtMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwN
TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEcMBoGA1UEAwwTYWNj
b3VudHMuZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AI53MUFYpFrV3J+B6ZbblEh+MlLsVbDqwMwFNEG4c+IjVXGDuUDGp+C7jkdVmIn2
T8skXutZj6E14D7WZvakq4pvSMBRkmkuWZk4+nWUY2/+TXuMYZXV0fnKBcDXTUxm
Bbc7a9gKVPD/dUHjJFWfkGznyq9lP0taT2MYsYE8+am4GAykSEgF2e4dEE4TrqWM
BP0+M/QfreykfpO/BF0UyqWXwzp4oYUWUyv2g8TU+i5hlELnVLU/0/jxaDA01ucH
+z0IRXxLxZW3/HXGNxr3wd24fvBD0PBe45ftUIM1Hq5x0kf0iv18aFR9Uy1yDl5W
ie4V8cRNq1m8h+b+IDiiuWsCAwEAAaOCAWcwggFjMB0GA1UdJQQWMBQGCCsGAQUF
BwMBBggrBgEFBQcDAjA1BgNVHREELjAsghNhY2NvdW50cy5nb29nbGUuY29tghUq
LnBhcnRuZXIuYW5kcm9pZC5jb20waAYIKwYBBQUHAQEEXDBaMCsGCCsGAQUFBzAC
hh9odHRwOi8vcGtpLmdvb2dsZS5jb20vR0lBRzIuY3J0MCsGCCsGAQUFBzABhh9o
dHRwOi8vY2xpZW50czEuZ29vZ2xlLmNvbS9vY3NwMB0GA1UdDgQWBBQ1jLhJdsYE
BiSt2vOb6DCTV5y+EjAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFErdBhYbvPZo
tXb1gba7Yhq6WoEvMCEGA1UdIAQaMBgwDAYKKwYBBAHWeQIFATAIBgZngQwBAgIw
MAYDVR0fBCkwJzAloCOgIYYfaHR0cDovL3BraS5nb29nbGUuY29tL0dJQUcyLmNy
bDANBgkqhkiG9w0BAQsFAAOCAQEAi2c6nKtNZ5bHAG7mbBuqS2OA093euznd+d0q
0DG+LvgSFwOHeSZn0VHGDiQ8nGhvA/3W7cva+p2zO29zQDiFTUW3+Ni+vFLl1yY+
JXiTBqStVAihau9BLitvsFXT/3+NjxJ/TgDz9EkoDlEAnsofZ7amH2mA4+cMdN5P
eAMUjJgKc7iJdxgZMLYXC7oYoHDz2PqgKy+lgk4+mIxxLWfiYWRqMFVvIwFlY1eC
ORulBjAOdRkm1yLpMfmHcXxA4C7jtoxrtr1vJs7i061JF78grhuqYdKvSc5TEhD+
II5MNcN2ArQgWbA92Pv1YVk0COEDcJoVSZ4bJtOH+iEpLg7fRg==
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=accounts.google.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---
No client certificate CA names sent
---
SSL handshake has read 3273 bytes and written 456 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES128-SHA
    Session-ID: 50C97032E3B74D2CC706CA939CC7FF5EFD40C8D590E8F2B084CD36F092721547
    Session-ID-ctx:
    Master-Key: 1F4565E7707F318C872DA80E1544501E2DA5E0F1508193762D8E61EFB69C2683AE7914D2117E150746F328FAA01CC499
    Key-Arg   : None
    Start Time: 1490708489
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

不确定如何解决

答案1

阿松格正确的是，问题是由于证书链中的第三个证书GeoTrust Global CA) 是由 颁发的，Equifax Secure Certificate Authority而该证书在从 Curl 网站下载的文件中未列为受信任的 CA 证书。我想补充一下他/她的回答——并保证贝卡达雷拉– 解释为什么会出现这种情况。

Curl 网站上的受信任 CA 证书列表实际上是从 Mozilla 使用的根证书生成的。Equifax 证书未列在其中的原因是：Equifax 和其他 CA 证书2016 年 10 月从 Mozilla 的受信任 CA 证书列表中删除。请参阅导致此更改的以下错误报告：从 NSS 中删除未经审核的 Symantec 根证书。

交叉签名证书

GeoTrust 证书实际上是交叉签名证书。这意味着有两个版本的 GeoTrust 证书由同一个私钥（用于签署证书Google Internet Authority G2）生成。

  • 自签名证书（目前大多数 CA 根存储都列出）
  • Equifax 签署的一份

第二个证书在 GeoTrust CA 刚开始的时候很有用。当时，客户会信任它，因为他们信任用于签署它的 Equifax 证书。这样的证书被称为过渡证书。

对于交叉签名证书，有多种可能的验证路径：

1. 使用自签名证书

这是 OpenSSL 最新版本的默认行为。

$ echo | openssl s_client -connect accounts.google.com:443 -CAfile cacert.pem >/dev/null
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = accounts.google.com
verify return:1
DONE

2. 使用“桥梁”证书

以下是中间证书的较长链的演示。我使用了 OpenSSL 1.0.2k，并模拟了其不遵循替代证书链的旧默认行为。由于 Equifax 根 CA 证书不再存在于我的系统证书存储中，因此我明确指定将其用作此命令的 CA 根存储：

$ echo | openssl s_client -connect accounts.google.com:443 -CAfile Equifax_Secure_CA.pem  -no_alt_chains >/dev/null
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = accounts.google.com
verify return:1
DONE

OpenSSL 行为

旧版本的 OpenSSL 构建中间证书链的方式是从远程服务器发送的证书构建最长的链，然后寻找签署该链的可信证书。如果在其信任存储中未找到此类证书，则会抛出验证错误。

这导致了问题，因为桥接证书逐渐从根 CA 信任存储中删除，OpenSSL 必须改变这种行为。请参阅OpenSSL 拒绝交叉签名证书，因为根证书不是链的基础

这个具体问题

在这种情况下，s_client使用该-showcerts选项运行表明 Google Web 服务器仍会发送由 Equifax 私钥签名的旧版桥接证书。我怀疑您使用的是旧版 OpenSSL（1.0.2b 之前的版本），并且它在构建中间证书链时使用了所有这些证书。

解决方案

以下是一些可能的解决方案，以确保s_client信任链中的所有证书都得到正确验证：

  1. 升级到较新的版本（1.02b 以上），检查是否可以构建替代（更短）链来验证 - 如果无法验证第一个（长）链。

  2. 一些较旧版本的 OpenSSLs_client会接受一个-trusted_first选项，该选项会导致 OpenSSL 检查是否可以使用其受信任的根 CA 证书列表中的证书构建更短的证书链 (前尝试构建一个长链）

  3. 将 导入Equifax Secure Certificate Authority到您的证书存储区 – 或将其保存为文件并使用-CAfile或-CApath选项引用它s_client。

答案2

这实际上不是一个错误。这在受信任的证书（具有主题的证书s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA）中处于最低限度，但该受信任证书的颁发者i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority不在受信任列表中。这实际上完全没问题。如果您查看底部的最终验证状态，则表明您已正确验证。

有时，根 CA 可能是自签名的（颁发者 == 主体），但事实并非如此。只要链中的一个证书在信任范围内，它就被正确认证了。

相关内容