我unable to get local issuer certificate通过SSL获取accounts.google.com unable to get local issuer certificate 。 我从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) ---
不知道如何解决
这实际上不是一个错误。 这在可信证书（具有主题为s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA ）的证书的s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA ，但是该可信证书具有颁发者i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority不在受信任列表中的i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority 。 这实际上是完全正常的。 如果您查看底部的最终validation状态，则会进行正确validation。
有些时候，根CA可能是自签名的（发行人==主体），但是事实并非如此。 只要链中的一个证书在信任中，就可以正确authentication。
asonge是正确的，问题是由于证书链中的第三个证书GeoTrust Global CA ）是由Equifax Secure Certificate Authority颁发的，该证书在从Curl网站下载的文件中未被列为可信CA证书。 我想我会补充他/她的答案 – 并保证bcardarella – 解释为什么是这样的。
Curl网站上的可信CA证书列表实际上是从Mozilla使用的根证书生成的。 Equifax证书未在其中列出的原因是： 2016年10月 ，Equifax和其他CA证书已从Mozilla的可信CA证书列表中删除 。 查看导致此更改的以下错误报告： 从NSS中删除未经审核的Symantec根证书 。
GeoTrust证书实际上是一个交叉签名证书 。 这意味着从同一个私钥生成的GeoTrust证书有两个版本（用于签署Google Internet Authority G2证书）。
第二份证书在GeoTrust CA首次启动的那一天有用。 当时，客户会信任它，因为他们信任用于签署的Equifax证书。 这样的证书被称为桥接证书 。
使用交叉签名证书，有多个可能的validationpath：
这是最近版本的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
下面是一个由中间证书组成的较长链的示例。 我使用了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构build了一个中间证书链，从远程服务器发送的证书中构build出最长的链，然后查找签名该链的可信证书。 如果在其信任库中没有find这样的证书，就会出现validation错误。
这造成了问题，因为桥接证书逐渐从根CA信任存储中删除，OpenSSL必须改变这种行为。 请参阅由OpenSSL拒绝的交叉签名证书，因为root证书不是链的基础
在这种情况下，使用-showcerts选项运行s_client显示Google Web服务器仍然发送由Equifax的私钥签名的传统网桥证书。 我怀疑你使用的是旧版本的OpenSSL（在1.0.2b之前），并且在构build它的中间证书链时使用了它们。
以下是一些可能的解决scheme，以确保s_client显示正确validation的信任链中的所有证书：
升级到更新的版本（1.02b），检查是否可以构build替代（较短）的链来validation – 如果第一条（长）链不能被validation。
某些旧版本的s_client接受-trusted_first选项，导致OpenSSL检查是否可以使用可信根CA证书列表中的证书（ 在尝试构build长链之前）构build较短的链。
将Equifax Secure Certificate Authority导入您的证书存储区 – 或将其保存为文件，并使用s_client的-CAfile或-CApath选项对其进行-CApath 。