修复CURL（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命令提示符下使用此命令。测试CURL如下：

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错误？

通常在证书与主机名不匹配时发生。

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

在此处可以找到更多信息：http : //curl.haxx.se/docs/sslcerts.html

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

我知道这是一个（非常）古老的问题，它与命令行有关，但是当我在Google上搜索“ 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与主机名不匹配，因此证书验证失败。与true相同www.evercam.io，例如，使用浏览器尝试https://www.evercam.io，您将收到错误消息，证书中的名称与主机名不匹配。

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

可能会节省一些时间。

如果您使用GuzzleHttp并且遇到此错误消息cURL错误60：SSL：没有其他证书主题名称与目标主机名匹配，并且使用“不安全”解决方案（在生产中不建议使用）很好，那么您必须添加 \GuzzleHttp\RequestOptions::VERIFY => false到客户端组态：

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

在方法中设置CURLOPT_SSL_VERIFYHOST为0并设置CURLOPT_SSL_VERIFYPEER为falseCurlFactory::applyHandlerOptions()

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

从GuzzleHttp文档

校验

描述请求的SSL证书验证行为。

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

如错误代码所示，“没有其他证书使用者名称与目标主机名称匹配”-SSL证书存在问题。

该证书应包括SAN，并且将仅使用SAN。某些浏览器会忽略不建议使用的通用名称。

RFC 2818明确指出“如果存在类型为dNSName的subjectAltName扩展名，则必须将其用作标识。否则，必须使用证书的Subject字段中的（最特定的）Common Name字段。尽管使用Common名称是现有的做法，不建议使用，鼓励证书颁发机构改为使用dNSName。”

我遇到过同样的问题。就我而言，我使用的是digitalocean和nginx。
我首先在digitalocean中设置了一个域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;