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

Question

我收到unable to get local issuer certificate了accounts.google.com超过SSL。我从https://curl.haxx.se/ca/cacert.pem下载了一个更新的 CA 文件并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)
---

不知道如何解决

Answer 1

asonge是正确的，该问题是由于证书链中的第三个证书GeoTrust Global CA) 的颁发者Equifax Secure Certificate Authority没有在从 Curl 网站下载的文件中列为受信任的 CA 证书。我想我会通过解释为什么会这样来补充他/她的回答——并让bcardarella放心。

来自 Curl 网站的可信 CA 证书列表实际上是根据 Mozilla 使用的根证书生成的。其中没有列出 Equifax 证书的原因是：Equifax 和其他 CA 证书已于2016 年 10 月从 Mozilla 的可信 CA 证书列表中删除。请参阅以下导致此更改的错误报告：从 NSS 中删除未经审核的赛门铁克根证书。

交叉签名证书

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 网络服务器仍然发送由 Equifax 的私钥签名的旧桥证书。我怀疑您使用的是旧版本的 OpenSSL（在 1.0.2b 之前），并且在构建其中间证书链时它会使用所有这些。

解决方案

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

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

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

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