这可以帮助你控制暴饮暴食:

$client = new Client(env('API_HOST'));
$client->setSslVerification(false);

测试在guzzle/guzzle 3.*

关于“SSL证书问题:无法获得本地颁发者证书”错误。需要注意的是，这适用于发送CURL请求的系统，而不是接收请求的服务器。

Download the latest cacert.pem from https://curl.se/ca/cacert.pem Add the '--cacert /path/to/cacert.pem' option to the curl command to tell curl where the local Certificate Authority file is. (or) Create or add to a '.curlrc' file the line: cacert = /path/to/cacert.pem See 'man curl', the section about the '-K, --config <file>' section for information about where curl looks for this file. (or if using php) Add the following line to php.ini: (if this is shared hosting and you don't have access to php.ini then you could add this to .user.ini in public_html).

卷毛。cainfo = " - path / to / downloaded cacert pem。”

请确保将路径用双引号括起来!!

默认情况下，FastCGI进程将每300秒解析一次新文件(如果需要，您可以通过添加几个文件来改变频率https://ss88.uk/blog/fast-cgi-and-user-ini-files-the-new-htaccess/)。

我的情况不同。我在防火墙后面托管一个网站。错误是由pfSense引起的。

Network layout: |Web Server 10.x.x.x| <-> |pfSense 49.x.x.x| <-> |Open Internet|

多亏了这个答案，我意外地找到了原因。

当我从广域网访问我的网站时，一切都很好。

然而，当从局域网内访问站点时(例如，当Wordpress向其自己的服务器发出curl请求时，尽管使用WAN IP 49.x.x.x)，它被提供pfSense登录页面。

我将证书标识为pfSense webConfigurator自签名证书。难怪curl抛出一个错误。

原因:发生的事情是curl正在使用站点的WAN IP地址49.x.x.x。但是，在web服务器的上下文中，广域网IP是防火墙。

调试:我发现我正在获得pfSense证书。

解决方案:在托管该站点的服务器上，将其自己的域名指向127.0.0.1

通过应用该解决方案，web服务器正确地处理了curl的请求，并且没有转发到防火墙，防火墙通过发送登录页面进行响应。

在windows上-如果你想从cmd运行

> curl -X GET "https://some.place"

下载cacert。pem从 https://curl.haxx.se/docs/caextract.html

永久设置环境变量:

CURL_CA_BUNDLE = C:\somefolder\cacert.pem

并通过重新打开任何您想要的cmd窗口来重新加载环境 使用旋度;如果安装了Chocolatey，您可以使用:

refreshenv

现在再试一次

故障原因: https://laracasts.com/discuss/channels/general-discussion/curl-error-60-ssl-certificate-problem-unable-to-get-local-issuer-certificate/replies/95548

您必须将服务器证书从cert.pem更改为fullchain.pem 我有同样的问题与Perl HTTPS守护进程: 我已经改变了: SSL_cert_file => '/etc/letsencrypt/live/mydomain/cert.pem' : SSL_cert_file => '/etc/letsencrypt/live/mydomain/fullchain.pem'

我在Wordpress安装上试图通过ElasticPress和AWS ACM PCA管理的自签名根CA与内部ElasticSearch服务通信，已经为这个问题困扰了几天。

在我的特殊情况下，我从默认的cURL传输以及预期的正文中收到了200 OK响应，但Wordpress返回了一个WP_Error对象，ElasticPress由于这个证书问题而获得，但从未记录。

说到Wordpress，有两件事值得注意:

The default cURL Transport for all wp_remote_* calls will look to a CA Bundle located in wp-includes/certificates/ca-bundle.crt. This bundle serves largely the same purpose as what's found under https://curl.haxx.se/docs/caextract.html, and will cover most use-cases that don't typically involve more exotic setups. Action/Filter order matters in Wordpress, and in ElasticPress' case, many of its own internal functions leverage these remote calls. The problem is, these remote calls were being executed during the plugins_loaded lifecycle, which is too early for Theme logic to be able to override. If you're using any plugins that make external calls out to other services and you need to be able to modify the requests, you should take careful note as to WHEN these plugins are performing these requests.

这意味着，即使在主题中定义了正确的服务器设置、钩子、回调和逻辑，你仍然可能以一个坏的设置结束，因为底层插件调用在主题加载之前执行得很好，并且永远无法告诉Wordpress关于新证书的信息。

在Wordpress应用程序中，我知道只有两种方法可以在不更新核心或第三方代码逻辑的情况下规避这个问题:

(推荐)添加一个“必须使用”插件到您的安装，调整您需要的设置。MU插件是Wordpress生命周期中最早加载的，可以让你在不直接改变它们的情况下覆盖你的插件和核心。在我的例子中，我用下面的逻辑建立了一个简单的MU插件:

// ep_pre_request_args is an ElasticPress-specific call that we need to adjust for all outbound HTTP requests
add_filter('ep_pre_request_args', function($args){
    if($_ENV['ELASTICSEARCH_SSL_PATH'] ?? false) {
        $args['sslcertificates'] = $_ENV['ELASTICSEARCH_SSL_PATH'];
    }
    return $args;
});

(不推荐)如果你实在没有其他选择，你也可以将根CA附加到wp-includes/certificates/ CA -bundle.crt。这似乎会“纠正”潜在的问题，你将得到正确的SSL证书验证，但这种方法将失败每次更新Wordpress，除非你添加额外的自动化。

我添加这个答案是因为在我甚至懒得深入研究插件源代码之前，我已经认为我在我的设置中做了一些错误或不稳定的事情。希望这可以为正在做类似事情的人节省一些时间。