Question

我正在PHP中使用Rackspace API，它刚刚停止工作（三天前一切正常）。它使用食人狂，使用卷曲。卷曲刚停止工作。

[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)

该错误的重要部分如下：

[卷曲] 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

----编辑----

所以，我的问题是由于卷发证书的变化。来自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

但是，我不知道，总有一天，我会看到系统停止正常运行，我要在计算机中运行此命令，仅此而已？其他人怎么办？用这个命令？还是什么？

Answer 1

如果某天我又有旧证书，则我的站点将停止工作。 Curl应该自己下载一个新证书吗？是吗？

TLS的概念是服务器将其证书发送给客户端，显示证明它确实拥有属于证书的私钥，然后客户端检查该证书是否被认为是可信的。受信任是指证书是由本地信任的CA（证书颁发机构）颁发的。

通常，客户端具有一组它信任的CA，即像Let's Encrypt这样的CA。如果证书是由这样一个已经受信任的CA颁发的，则只要更改了证书，只要颁发者CA仍然受信任，并且服务器已正确配置为提供所需的所有中间CA证书，则无需对客户端进行任何更改}}。

如果相反，您具有自签名证书或由某些专用CA签名的证书，则客户端没有可用于验证证书的信任锚。在这种情况下，您需要为客户端提供必要的信任锚。如果是专用CA，则只需用该专用CA设置一次客户端就足够了，并且它还将接受此CA以后发布的证书。但是，对于自签名证书，这意味着每当您在服务器上更新证书时，都需要在客户端上更新期望的证书。没有自动的方法-因为客户应该如何在不对提供新证书的一方建立信任的情况下验证它是否获得了正确的新证书？

Answer 2

较早版本的Guzzle使用了与Guzzle库捆绑在一起的自己的CA文件。它将使用该文件而不是系统（/etc/pki/tls/certs）。

如果您可以从命令行使用cURL进行操作，但是在Guzzle中得到此错误，很可能是罪魁祸首。

在2014年末，更改为默认使用系统CA捆绑包。

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

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

here（参见verify配置标志）描述了较新版本（> 3.0吗？）的行为：

检查您的php.ini文件中是否设置了openssl.cafile。

检查您的php.ini文件中是否设置了curl.cainfo。

检查是否存在/etc/pki/tls/certs/ca-bundle.crt（Red Hat，CentOS，Fedora；由ca-certificates软件包提供）

检查是否存在/etc/ssl/certs/ca-certificates.crt（Ubuntu，Debian；由ca-certificates软件包提供）

检查是否存在/usr/local/share/certs/ca-root-nss.crt（FreeBSD；由ca_root_nss软件包提供）

检查是否/usr/local/etc/openssl/cert.pem（OS X；由自制软件提供）

检查C:\windows\system32\curl-ca-bundle.crt是否存在（Windows）

检查C:\windows\curl-ca-bundle.crt是否存在（Windows）

Answer 3

此问题是由卷曲证书的更改引起的。来自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

考虑一下如果再次更新证书，将来可能需要再次使用这些命令中的任何一个。

如何在不下载证书的情况下修复Curl错误60

3 个答案: