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

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

SSL certificate problem: unable to get local issuer certificate

我在网上挖掘了一些关于为cURL配置cacarts文件的信息。 因此，我在

PHP.ini

curl.cainfo=some\local\path\\certs\cacert.pem

现在我正在测试多个HTTPS网站（测试的src）

结果不一致，比如：

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次调用

我也犯了同样的错误。上面的链接在浏览器中可以正常打开，而且它们的CA链证书也是有效的。这是什么原因

编辑：

我花了大约6个小时试图解决这个问题，并在发布问题2分钟后找到了一条线索。 所以我又读了一次关于这里提供的摘录的信息。什么让我咳嗽（现在，但我以前读过不到100次）

已删除RSA-1024

大约在2014年9月初，Mozilla从服务器上删除了信任位 CA捆绑包中仍使用RSA 1024位密钥的证书。这 可能导致TLS库难以验证某些站点，如果 有问题的库不正确地支持“路径发现” 根据RFC 4158。（包括OpenSSL和GnuTLS。）

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

所以我在“清理前”拍了一张疲惫的budle-现在所有的测试都通过了！ 因此，另一个问题是-是关于我的mashine上的过时软件，如OpenSSL、PHP、cURL等，还是测试失败的站点根据RFC 4158有过时的证书格式，这就是造成问题的原因

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

这些可能都没有。已删除的证书，其中旧根CA仅使用1024位密钥。这些证书以某种方式被较新的证书替换，但不在同一位置，即如果您经常有多个可能的信任路径：

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

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

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

然后OpenSSL将坚持查找根CA签名
中间.2
，即使它有根CA签名
中间.1
（即
2048bit新根
）。如果旧的
1024bit根CA
不再在信任存储中，验证将失败。相反，如果服务器只发送

host-cert -> intermediate.1

然后使用
2048bit新根验证将成功。但是许多服务器仍然会发送更长的链，以保持与没有
2048bit新根目录的旧客户端的兼容性

所有的一切都很丑陋，而且很丑陋。OpenSSL 1.0.2（最新发布）至少有一个选项
X509\u V\u FLAG\u TRUSTED\u FIRST
来解决这个问题，OpenSSL git中有一些变化似乎可以解决这个问题，但不清楚它们是否将每个后端口都移植到1.0.2或更低版本：（

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

host-cert -> intermediate.1