我们最近遇到了这个错误。事实证明，这与根证书没有正确安装在CA存储目录有关。我使用了一个curl命令，其中我直接指定了CA目录。Curl——cacert /etc/test/server。—capath /etc/test…此命令每次都失败，curl: (60) SSL证书问题:无法获得本地颁发者证书。

在使用strace curl…根据openssl哈希命名约定，curl正在查找名称为60ff2731.0的根证书文件。所以我发现这个命令可以有效地导入根证书:

Ln -s rootcert。pem的openssl x509散列-noout——rootcert.pem ' 0

哪个会创建软链接

60f2731.0 ->找到脚

卷曲，在被子下读取服务器。pem，确定根证书文件的名称(rootcert.pem)，将其转换为其哈希名称，然后进行操作系统文件查找，但无法找到它。

因此，结论是，当curl错误很模糊时，在运行curl时使用strace(这是一个巨大的帮助)，然后确保使用openssl命名约定正确安装根证书。

对我来说，简单地安装证书有帮助:

sudo apt-get install ca-certificates

仅仅更新证书列表可能就足够了

sudo update-ca-certificates -f

update-ca-certificates是一个更新/etc/ssl/certs目录以保存SSL证书并生成ca-certificates的程序。Crt，一个连接的证书单文件列表。

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

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

测试在guzzle/guzzle 3.*

这很可能是服务器上丢失的证书。

根- >中间- >服务器

服务器至少应该发送服务器和中间体。

使用openssl s_client -showcerts -starttls ftp -crlf -connect abc:21进行调试。

如果只返回一个证书(自签名或颁发)，那么您必须选择:

修复服务器 信任该证书并将其添加到您的CA证书存储(不是最好的主意) 禁用信任，例如curl -k(非常糟糕的主意)

如果服务器返回多个，但不包括自签名(根)证书:

在此链的CA存储中安装CA(根)证书，例如谷歌颁发者。(只有当你信任该CA时) 服务器是否将CA作为链的一部分发送 信任链中的证书 禁用的信任

如果服务器返回一个根CA证书，那么它不在您的CA存储中，您的选项是:

添加(信任)它 禁用的信任

我忽略了过期/撤销的证书，因为没有消息表明它。但是您可以使用openssl x509 -text检查certs

假设您正在连接到家庭版(https://www.cerberusftp.com/support/help/installing-a-certificate/) ftp服务器，我将说它是自签名的。

请发布更多细节，比如来自openssl的输出。

我在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，除非你添加额外的自动化。

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