cURL PHP SSL - 无法验证服务器端，但并非始终

时间：2015-04-29 12:35:51

标签： php ssl curl zend-framework2 mandrill

我使用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=some\local\path\\certs\cacert.pem

现在我正在测试多个HTTPS网站（测试here的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

    3. 我得到了同样的错误。上面的链接在浏览器中打开很好，他们的CA链证书也是有效的。这可能是什么原因？

    修改

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

      

    删除了RSA-1024

         

    2014年9月初，Mozilla从中删除了信任位   CA捆绑中仍使用RSA 1024位密钥的证书。这个   如果可能导致TLS库难以验证某些站点   有问题的图书馆没有正确支持路径发现＆＃34;如   根据RFC 4158.（包括OpenSSL和GnuTLS。）

         

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

    所以我在清理之前从＃34;中抽出了一个镜头和疲惫的萌芽＆＃34; - 所有测试现在都已经过了！ 所以另一个问题是 - 它是关于我的mashine上的过时软件，如OpenSSL，PHP，cURL等，还是测试失败的网站有过时的证书格式 RFC 4158，这是导致麻烦的原因吗？

1 个答案:

答案 0 :(得分：1)

  

所以另一个问题是 - 它是关于我的mashine上的过时软件，如OpenSSL，PHP，cURL等，还是根据RFC 4158和测试失败的网站有过时的证书格式和那是什么导致了麻烦？

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

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将坚持找到根CA签名intermediate.2，即使它具有root-CA签名intermediate.1（即2048bit new root）。如果旧1024bit root-CA不再位于信任库中，则验证将失败。如果相反，服务器只发送

host-cert -> intermediate.1

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

所有非常丑陋以及bug was reported in 2012中的again和2015。 OpenSSL 1.0.2（最新发布）至少有一个选项X509_V_FLAG_TRUSTED_FIRST来解决这个问题，OpenSSL git中有一些变化似乎解决了这个问题，但是目前还不清楚它们是否每个都向后移植到1.0.2或更低:(

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

相关问题
最新问题