卷曲:修复卷曲 (51) SSL 错误:没有匹配的备用证书使用者名称

我是CURL世界的新手，来自Windows + .NET域。

尝试在 http://www.evercam.io/docs/api/v1/authentication 访问 Rest API 以进行基本身份验证。

curl -X GET https://api.evercam.io/v1/... 
-u {username}

不知道成功设置 CURL 后如何在 Windows 命令提示符下使用此命令。测试的卷曲如下所示：

C:>curl --version
curl 7.33.0 (x86_64-pc-win32) libcurl/7.33.0 OpenSSL/0.9.8y zlib/1.2.8 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp scp s
ftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate Largefile NTLM SSL SSPI libz

现在我以这个结束

C:>curl -u myuser:mypassword -X GET https://api.evercam.io/v1/
curl: (51) SSL: no alternative certificate subject name matches target host name 'api.evercam.io'

如何解决此SSL问题51错误？

当证书与主机名不匹配时，通常会发生这种情况。

解决方案是联系主机并要求其修复其证书。
否则，您可以关闭 cURL 对证书的验证，使用 -k（或--insecure）选项。
请注意，正如选项所说，这是不安全的。您不应该使用此选项，因为它允许中间人攻击并破坏 HTTPS 的目的。

更多内容可在此处找到：http://curl.haxx.se/docs/sslcerts.html

编者注：如果您使用的是足够旧的PHP版本，这是一种非常危险的方法。它会使您的代码受到中间人攻击，并删除加密连接的主要目的之一。执行此操作的功能已从现代版本的 PHP 中删除，因为它非常危险。这被点赞70次的唯一原因是因为人们很懒惰。不要这样做。

我知道这是一个（非常）古老的问题，它是关于命令行的，但是当我在谷歌上搜索"SSL：没有替代证书主题名称与目标主机名匹配"时，这是第一个命中。

我花了很长时间才找到答案，所以希望这可以为某人节省很多时间！在 PHP 中，将此添加到您的 cUrl setopts：

curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, FALSE);
curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, FALSE);

PS：这应该是一个临时解决方案。由于这是证书错误，最好的办法当然是修复证书！

证书中api.evercam.io的通用名称用于*.herokuapp.com证书，证书中没有备用使用者名称。这意味着，api.evercam.io的证书与主机名不匹配，因此证书验证失败。与 www.evercam.io 相同，例如，尝试使用浏览器 https://www.evercam.io，您收到错误消息，即证书中的名称与主机名不匹配。

所以这是一个需要 evercam.io 解决的问题。如果您不关心安全性，中间人攻击等，您可能会禁用证书验证（curl --insecure），但是您应该问问自己为什么使用https而不是http。

它

可能会为某人节省一些时间。

如果您使用 GuzzleHttp 并且遇到此错误消息 cURL 错误 60：SSL：没有替代证书使用者名称与目标主机名匹配，并且您对"不安全"解决方案（不建议在生产环境中使用）感到满意，那么您必须添加 GuzzleHttpRequestOptions::VERIFY => false客户端配置：

$this->client = new GuzzleHttpClient([
    'base_uri'                          => 'someAccessPoint',
    GuzzleHttpRequestOptions::HEADERS => [
        'User-Agent' => 'some-special-agent',
    ],
    'defaults'                          => [
        GuzzleHttpRequestOptions::CONNECT_TIMEOUT => 5,
        GuzzleHttpRequestOptions::ALLOW_REDIRECTS => true,
    ],
    GuzzleHttpRequestOptions::VERIFY  => false,
]);

在 CurlFactory::applyHandlerOptions() 方法中将 CURLOPT_SSL_VERIFYHOST 设置为 0，将CURLOPT_SSL_VERIFYPEER设置为 false

$conf[CURLOPT_SSL_VERIFYHOST] = 0;
$conf[CURLOPT_SSL_VERIFYPEER] = false;

来自 GuzzleHttp 文档

验证
描述请求的 SSL 证书验证行为。
设置为 true 以启用 SSL 证书验证并使用操作系统提供的默认 CA 捆绑>。
设置为 false 以禁用证书验证（这是不安全的！
设置为字符串以提供 CA 捆绑包的路径，以启用使用自定义证书的验证。

我遇到了同样的问题。就我而言，我使用的是digitalocean和nginx。
我首先在数字海洋中设置了一个域 example.app 和一个子域 dev.exemple.app。其次，我从 godaddy 那里购买了两个 SSL 证书。最后，我在nginx中配置了两个域，以将这两个SSL证书与以下狙击一起使用

我的 example.app 域配置

    server {
    listen 7000 default_server;
    listen [::]:7000 default_server;
     listen 443 ssl default_server;
     listen [::]:443 ssl default_server;
    root /srv/nodejs/echantillonnage1;
    # Add index.php to the list if you are using PHP
    index index.html index.htm index.nginx-debian.html;
    server_name echantillonnage.app;
    ssl_certificate /srv/nodejs/certificatSsl/widcardcertificate/echantillonnage.app.chained.crt;
    ssl_certificate_key /srv/nodejs/certificatSsl/widcardcertificate/echantillonnage.app.key;
    location / {
            # First attempt to serve request as file, then
            # as directory, then fall back to displaying a 404.
            proxy_pass http://127.0.0.1:8090;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';
            proxy_set_header Host $host;
            proxy_cache_bypass $http_upgrade;
    #try_files $uri $uri/ =404;
    }
 }

我的 dev.example.app

   server {
    listen 7000 default_server;
    listen [::]:7000 default_server;
     listen 444 ssl default_server;
     listen [::]:444 ssl default_server;
    root /srv/nodejs/echantillonnage1;
    # Add index.php to the list if you are using PHP
    index index.html index.htm index.nginx-debian.html;
    server_name dev.echantillonnage.app;
    ssl_certificate /srv/nodejs/certificatSsl/dev/dev.echantillonnage.app.chained.crt;
    ssl_certificate_key /srv/nodejs/certificatSsl/dev/dev.echantillonnage.app.key;
    location / {
            # First attempt to serve request as file, then
            # as directory, then fall back to displaying a 404.
            proxy_pass http://127.0.0.1:8091;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';
            proxy_set_header Host $host;
            proxy_cache_bypass $http_upgrade;
    #try_files $uri $uri/ =404;
    }
 }

当我启动 https://dev.echantillonnage.app 时，我得到了

    Fix CURL (51) SSL error: no alternative certificate subject name matches

我的错误是下面的两行

    listen 444 ssl default_server;
     listen [::]:444 ssl default_server;

我不得不将其更改为：

     listen 443 ssl;
     listen [::]:443 ssl;

正如错误代码所说，"没有备用证书使用者名称与目标主机名匹配" - 因此 SSL 证书存在问题。

证书应包括 SAN，并且仅使用 SAN。某些浏览器会忽略已弃用的公用名。

RFC 2818 明确指出 "如果存在 dNSName 类型的 subjectAltName 扩展，则必须用作标识。否则，（最具体的）公用名必须使用证书的"主题"字段中的字段。虽然使用公用名是现有做法，已弃用，并且鼓励证书颁发机构改用dNSName。

我做了类似的事情，但为了测试，我将主域名添加到我的/etc/hosts文件中，并一直在努力。因此，请确保也检查一次该文件。

相关内容

最新更新

热门标签：