【问题标题】:How to fix Curl error 60 without downloading cert如何在不下载证书的情况下修复 Curl 错误 60
【发布时间】:2018-06-21 16:21:12
【问题描述】:

我在 PHP 中使用 Rackspace API,但它刚刚停止工作(3 天前一切正常)。它使用 guzzle,谁使用 curl。而 curl 刚刚停止工作。

[Thu Jun 21 14:55:36 2018] [error] [client xxx.xx.xxx.xx] PHP Fatal error:  Uncaught exception 'Guzzle\\Http\\Exception\\CurlException' with message '[curl] 60:  [url] https://identity.api.rackspacecloud.com/v2.0/tokens' in 

/var/www/passline.com/vendor/guzzle/http/Guzzle/Http/Curl/CurlMulti.php:359\nStack trace:\n#0

/var/www/passline.com/vendor/guzzle/http/Guzzle/Http/Curl/CurlMulti.php(292): Guzzle\\Http\\Curl\\CurlMulti->isCurlException(Object(Guzzle\\Http\\Message\\EntityEnclosingRequest), Object(Guzzle\\Http\\Curl\\CurlHandle), Array)\n#1    

/var/www/passline.com/vendor/guzzle/http/Guzzle/Http/Curl/CurlMulti.php(257): Guzzle\\Http\\Curl\\CurlMulti->processResponse(Object(Guzzle\\Http\\Message\\EntityEnclosingRequest), 
Object(Guzzle\\Http\\Curl\\CurlHandle), Array)\n#2     

/var/www/passline.com/vendor/guzzle/http/Guzzle/Http/Curl/CurlMulti.php(240): Guzzle\\Http\\Curl\\CurlMulti->processMessages()\n#3    

/var/www/passline.com/vendor/guzzle/http/Guzzle/Http/Curl/CurlMulti.php(224): Guzzle\\Http\\Curl\\CurlMulti->executeHandles()\n#4

/var/www/passline.com/vendor/guzzle/http/Guzzle/Http/Curl/CurlMulti.php(111)

错误的重要部分如下:

[curl] 60: [url]https://identity.api.rackspacecloud.com/v2.0/tokens

我从 Curl 收到错误 60,这意味着是 SSL 证书错误。大多数答案说这个问题的解决方案是:停用 ssl 或下载新证书。

curl: (60) SSL certificate : unable to get local issuer certificate

https://es.stackoverflow.com/questions/174276/curl-60-ssl-certificate-problem-unable-to-get-local-issuer-certificate-url-h

我不会停用 SSL,我不能使用 http 代替 https,我想避免进入机器并下载新证书。

如果有一天我再次拥有旧证书,我的网站将停止工作。解决此问题的正确方法是什么?

此服务器有 CenOs 6,我们使用的是 PHP 5.3.3 和 curl 7.19.7

---- 编辑----

所以,我的问题是因为 curl 证书的变化。来自https://curl.haxx.se/docs/caextract.html

此捆绑包生成于格林威治标准时间 2018 年 6 月 20 日星期三 03:12:06。

在 linux 上有一个名为 update-ca-certificates 的工具可以解决这个问题,而且 curl 网站说你可以运行

curl --remote-name --time-cond cacert.pem https://curl.haxx.se/ca/cacert.pem

但是,我不知道,有一天我会看到系统停止正常工作,我会进入机器运行此命令,仅此而已?,其他人在做什么?,设置一个 cron用这个命令?还是什么?

【问题讨论】:

  • 1) 你在这里跑题了,因为这不是一个编程问题(所以请看Super UserServer FaultWebmasters),但更重要的是2)“我得到一个错误60卷曲。” 没有提供任何有用的信息....显示您完整使用的 curl 命令,以及完整的结果。尽管您可以阅读,但“停用 SSL(原文如此)”从不是个好主意。你最好使用 HTTP 查询而不是 HTTPS,因为远程身份验证比传输机密性更重要。
  • 我不拥有代码,所以我无法显示我正在使用的代码。 (我只是使用一个使用 guzzle 的 rackspace 库,他使用 curl)。结果就是那个“curl error 60”。我不会停用 SSL,这就是我问我不能进行 http 查询的原因,我不拥有我不知道 curl 是否自己下载证书的代码,或者所有这些是如何工作的。你确定这属于服务器故障吗?我宁愿避免在服务器中做任何事情。
  • 您至少应该提供您尝试访问的 URL... 事情可能还取决于 PHP 版本、openssl 版本、curl 版本、API 版本、操作系统类型和版本。 ..你没有给出数据点。否则,您将只能得到可能会或可能不会解决您的问题的通用回复。而且您的问题与编程无关...
  • 感谢您的帮助 Patrick,尝试将大部分请求信息添加到问题中。我应该更改其他内容吗?
  • 非常感谢@lcjury 今天这救了我...

标签: php ssl curl


【解决方案1】:

旧版本的 Guzzle 使用自己的 CA 文件,该文件与 Guzzle 库捆绑在一起。它将使用该文件而不是系统的 (/etc/pki/tls/certs)。

如果您可以从命令行使用 cURL 进行操作,但在 Guzzle 中出现此错误,这可能是罪魁祸首。

在 2014 年末,默认情况下更改为使用系统 CA 捆绑包。

https://github.com/guzzle/guzzle/issues/623

https://github.com/guzzle/guzzle/pull/800

较新 (> 3.0 ?) 版本的行为在 here 中描述(参见 verify 配置标志):

  1. 检查您的 php.ini 文件中是否设置了 openssl.cafile
  2. 检查您的 php.ini 文件中是否设置了 curl.cainfo
  3. 检查/etc/pki/tls/certs/ca-bundle.crt 是否存在(Red Hat、CentOS、Fedora;由 ca-certificates 包提供)
  4. 检查/etc/ssl/certs/ca-certificates.crt 是否存在(Ubuntu、Debian;由 ca-certificates 包提供)
  5. 检查/usr/local/share/certs/ca-root-nss.crt 是否存在(FreeBSD;由 ca_root_nss 包提供)
  6. 检查是否/usr/local/etc/openssl/cert.pem(OS X;由自制软件提供)
  7. 检查C:\windows\system32\curl-ca-bundle.crt 是否存在(Windows)
  8. 检查C:\windows\curl-ca-bundle.crt 是否存在(Windows)

【讨论】:

  • 哇,这是一个不错的提示,但我认为这并不能解决我的问题
  • 理论上 CA 将由系统更新 (ca-certificates RPM)。无需您从curl.haxx.se 手动更新。在代码存储库中使用静态文件的方法存在缺陷。不确定您的问题是否具体,希望答案对其他人有所帮助。
  • 系统自行更新证书?我使用的是 guzzle 3.9,因此,它带有您链接的拉取请求
  • 是的。 RHEL 和克隆应该使用ca-certificates 包来做到这一点。如果由于某种原因您没有获得更新,那么您可以手动进行。 More here
  • 这很奇怪。我不得不手动运行update-ca-certificates 来解决我的问题。无论如何很高兴知道,它应该自动完成
【解决方案2】:

如果有一天我再次拥有旧证书,我的网站将停止工作。 Curl应该自己下载新证书吗?不是吗?

TLS 的概念是服务器将其证书发送给客户端,证明它实际上拥有属于该证书的私钥,然后客户端检查该证书是否被认为是可信的。受信任意味着证书由本地受信任的 CA(证书颁发机构)颁发。

通常,客户端有一组它信任的 CA,即像 Let's Encrypt 这样的 CA。如果证书是由这样一个已经受信任的 CA 颁发的,则只要颁发者 CA 仍然受信任并且服务器配置正确以提供所需的所有中间 CA 证书to build the trust path,只要更改证书,就不需要更改客户端.

如果您拥有自签名证书或由某个私有 CA 签名的证书,则客户端没有可用于验证证书的信任锚。在这种情况下,您需要向客户端提供必要的信任锚。在私有 CA 的情况下,使用该私有 CA 设置一次客户端就足够了,并且它还将接受该 CA 以后颁发的证书。但是对于自签名证书,这意味着每当您在服务器上更新证书时,您都需要在客户端更新预期的证书。没有自动的方法来做到这一点 - 因为客户端应该如何验证它是否获得了正确的新证书,而无需对提供新证书的一方建立信任?

【讨论】:

    【解决方案3】:

    此问题是由于 curl 的证书更改引起的。来自https://curl.haxx.se/docs/caextract.html

    此捆绑包生成于格林威治标准时间 2018 年 6 月 20 日星期三 03:12:06。

    在 linux 上有一个名为 update-ca-certificates 的工具可以解决这个问题,而且 curl 网站说你可以运行

    curl --remote-name --time-cond cacert.pem https://curl.haxx.se/ca/cacert.pem

    请考虑如果再次更新证书,将来可能需要再次运行这些命令。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2019-10-27
      • 2013-09-28
      • 2021-08-15
      • 2017-11-21
      • 2017-12-11
      • 2017-04-22
      • 1970-01-01
      • 2017-03-21
      相关资源
      最近更新 更多