cURL PHP SSL-无法验证服务器端，但并非总是如此

Question

我在使用Mandrill PHP API 时遇到了一些问题

SSL certificate problem: unable to get local issuer certificate

我在网上挖了一些关于为cURL配置cacarts文件的信息。所以我有当前证书的摘录http://curl.haxx.se/docs/caextract.html，以及PHP.ini中该文件的配置(VALID)路径

curl.cainfo=somelocalpath\certscacert.pem

现在我正在测试多个HTTPS网站(此处为测试的src)

$this->nxs_cURLTest("https://mandrillapp.com/api/1.0/users/ping.json", "TestApiCALL", "Mandrill API CERT");
$this->nxs_cURLTest("https://www.google.com/intl/en/contact/", "HTTPS to Google", "Mountain View, CA");
$this->nxs_cURLTest("http://www.google.com/intl/en/contact/", "HTTP to Google", "Mountain View, CA");
$this->nxs_cURLTest("https://www.facebook.com/", "HTTPS to Facebook", 'id="facebook"');
$this->nxs_cURLTest("https://www.linkedin.com/", "HTTPS to LinkedIn", 'link rel="canonical" href="https://www.linkedin.com/"');
$this->nxs_cURLTest("https://twitter.com/", "HTTPS to Twitter", 'link rel="canonical" href="https://twitter.com/"');
$this->nxs_cURLTest("https://www.pinterest.com/", "HTTPS to Pinterest", 'content="Pinterest"');
$this->nxs_cURLTest("https://www.tumblr.com/", "HTTPS to Tumblr", 'content="Tumblr"');

得到了不一致的结果，如：

Testing ... https://mandrillapp.com/api/1.0/users/ping.json - https://mandrillapp.com/api/1.0/users/ping.json
....TestApiCALL - Problem
SSL certificate problem: unable to get local issuer certificate
Array
(
[url] => https://mandrillapp.com/api/1.0/users/ping.json
[content_type] => 
[http_code] => 0
[header_size] => 0
[request_size] => 0
[filetime] => -1
[ssl_verify_result] => 0
[redirect_count] => 0
[total_time] => 0.14
[namelookup_time] => 0
[connect_time] => 0.062
[pretransfer_time] => 0
[size_upload] => 0
[size_download] => 0
[speed_download] => 0
[speed_upload] => 0
[download_content_length] => -1
[upload_content_length] => -1
[starttransfer_time] => 0
[redirect_time] => 0
[certinfo] => Array
(
)
[primary_ip] => 54.195.231.78
[primary_port] => 443
[local_ip] => 192.168.2.142
[local_port] => 63719
[redirect_url] => 
)
There is a problem with cURL. You need to contact your server admin or hosting provider.Testing ... https://www.google.com/intl/en/contact/ - https://www.google.com/intl/en/contact/
....HTTPS to Google - OK
Testing ... http://www.google.com/intl/en/contact/ - http://www.google.com/intl/en/contact/
....HTTP to Google - OK
Testing ... https://www.facebook.com/ - https://www.facebook.com/
....HTTPS to Facebook - OK
Testing ... https://www.linkedin.com/ - https://www.linkedin.com/
....HTTPS to LinkedIn - OK
Testing ... https://twitter.com/ - https://twitter.com/
....HTTPS to Twitter - OK
Testing ... https://www.pinterest.com/ - https://www.pinterest.com/
....HTTPS to Pinterest - Problem
SSL certificate problem: unable to get local issuer certificate
Array
(
[url] => https://www.pinterest.com/
[content_type] => 
[http_code] => 0
[header_size] => 0
[request_size] => 0
[filetime] => -1
[ssl_verify_result] => 0
[redirect_count] => 0
[total_time] => 0.078
[namelookup_time] => 0
[connect_time] => 0.016
[pretransfer_time] => 0
[size_upload] => 0
[size_download] => 0
[speed_download] => 0
[speed_upload] => 0
[download_content_length] => -1
[upload_content_length] => -1
[starttransfer_time] => 0
[redirect_time] => 0
[certinfo] => Array
(
)
[primary_ip] => 23.65.117.124
[primary_port] => 443
[local_ip] => 192.168.2.142
[local_port] => 63726
[redirect_url] => 
)
There is a problem with cURL. You need to contact your server admin or hosting provider.Testing ... https://www.tumblr.com/ - https://www.tumblr.com/
....HTTPS to Tumblr - OK

正如您所看到的，在总体SSL配置中是有效的，但由于某些原因，2次调用

1. https://www.pinterest.com/
2. https://mandrillapp.com/api/1.0/users/ping.json

我得到了同样的错误。以上链接在浏览器中打开得很好，而且它们的CA链证书也是有效的。这里的原因是什么？

编辑：

我花了大约6个小时试图解决这个问题，并在SO上发布问题大约2分钟后找到了关于发生了什么的线索。所以我在http://curl.haxx.se/docs/caextract.html关于那里提供的摘录。是什么咳嗽了我的眼睛(现在，但我以前读过不到100次)

RSA-1024删除

2014年9月初，Mozilla从他们的CA捆绑包中仍然使用RSA 1024位密钥的证书。这可能导致TLS库很难验证某些站点，如果有问题的库不正确地支持"路径发现"，因为根据RFC 4158。(包括OpenSSL和GnuTLS。)

在清理之前，我们转换的最后一个CA捆绑包：来自github的ca捆绑包。

所以我拍了一张照片，从"清理之前"开始就累了——现在所有的测试都通过了！因此，另一个问题是，是我的mashine上的过时软件，如OpenSSL、PHP、cURL等，还是测试失败的网站根据RFC 4158具有过时的证书格式，这就是造成问题的原因？

Answer 1

所以另一个问题是-是我的mashine上的过时软件，如OpenSSL、PHP、cURL等，还是测试失败的网站的证书格式根据RFC 4158过时，这就是造成问题的原因？

可能没有。删除的证书中只有1024位密钥的旧根CA。这些证书以某种方式被更新的证书取代，但不在同一个位置，即如果您经常有多个可能的信任路径：

host-cert -> intermediate.1 -> 2048bit intermediate.2 -> 1024bit root-CA
host-cert -> intermediate.1 -> 2048bit new root

2048bit new root的公钥与2048bit intermediate.2的公钥相同，因此intermediate.1的签名仍然匹配，因此链验证将成功。但是，尽管大多数TLS堆栈都试图找到最好的链，但OpenSSL坚持使用最长的链。这意味着如果服务器发送链

host-cert -> intermediate.1 -> 2048bit intermediate.2

则OpenSSL将坚持找到签署intermediate.2的根CA(即使它具有签署intermediate.1(即2048bit new root)的根CA)。如果旧的1024bit root-CA不再在信任存储中，则验证将失败。如果服务器只发送

host-cert -> intermediate.1

则CCD_ 9的验证将成功。但许多服务器仍将发送较长的链，以保持与没有2048bit new root的旧客户端的兼容性。

所有这些都非常丑陋，2012年和2015年都报告了这个错误。OpenSSL 1.0.2(最新发布)至少有一个选项X509_V_FLAG_TRUSTED_FIRST来解决这个问题，OpenSSL git中的一些更改似乎解决了这个问题，但尚不清楚他们是否将每个后端口都移植到1.0.2或更低版本：(

现在，您最好将旧的1024bit证书保存在信任存储中。