Curl：CURL（51）SSLエラーを修正：代替の証明書サブジェクト名が一致しません

私はCURLの世界に不慣れで、Windows + .NETドメインから来ています。

http://www.evercam.io/docs/api/v1/authenticationで基本認証のためにRestAPIにアクセスしようとしています。

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エラーを修正するにはどうすればよいですか？

これは通常、証明書がホスト名と一致しない場合に発生します。

解決策は、ホストに連絡して、証明書を修正するように依頼することです。
それ以外の場合は、cURLによる証明書の検証をオフにすることができます。-k（または--insecure）オプションを使用してください。
オプションが言ったように、それは安全ではないことに注意してください。このオプションはman-in-the-middle攻撃を許可し、HTTPSの目的を無効にするため、使用しないでください。

詳細については、http：//curl.haxx.se/docs/sslcerts.htmlをご覧ください。

編集者注：これは、使用するのに十分古いバージョンのPHPを使用している場合、非常に危険なアプローチです。コードをman-in-the-middle攻撃にさらし、暗号化された接続の主な目的の1つを削除します。これを行う機能は、非常に危険であるため、最新バージョンのPHPから削除されました。これが70回賛成された唯一の理由は、人々が怠惰だからです。こんなことしないで。

これは（非常に）古い質問であり、コマンドラインに関するものですが、Googleで「SSL：ターゲットホスト名と一致する代替証明書のサブジェクト名がありません」を検索したところ、これが最初のヒットでした。

答えを見つけるのにかなり時間がかかりましたので、これが誰かの時間を大幅に節約することを願っています！PHPでは、これをcUrlsetoptsに追加します。

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

ps：これは一時的な解決策になるはずです。これは証明書エラーなので、もちろん証明書を修正するのが最善です。

の証明書の一般名api.evercam.ioはfor*.herokuapp.comであり、証明書に代替のサブジェクト名はありません。これは、の証明書api.evercam.ioがホスト名と一致しないため、証明書の検証が失敗することを意味します。の場合と同じですwww.evercam.io。たとえば、https：//www.evercam.ioを試してください。、ブラウザでを、証明書の名前がホスト名と一致しないというエラーメッセージが表示されます。

したがって、これはevercam.ioで修正する必要がある問題です。セキュリティやman-in-the-middle攻撃などを気にしない場合は、証明書の検証を無効にする可能性があります（curl --insecure）が、httpではなくhttpsを使用する理由を自問する必要があります。

誰かの時間を節約できるかもしれません。

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_VERIFYHOST0とCURLOPT_SSL_VERIFYPEERfalseに設定されますCurlFactory::applyHandlerOptions()

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

GuzzleHttpのドキュメントから

確認

リクエストのSSL証明書検証動作について説明します。

• trueに設定すると、SSL証明書の検証が有効になり、オペレーティングシステムによって提供されるデフォルトのCAバンドルが使用されます。
• falseに設定すると、証明書の検証が無効になります（これは安全ではありません！）。
• 文字列に設定して、カスタム証明書を使用した検証を有効にするCAバンドルへのパスを提供します。

エラーコードにあるように、「代替の証明書サブジェクト名はターゲットホスト名と一致しません」-したがって、SSL証明書に問題があります。

証明書にはSANが含まれている必要があり、SANのみが使用されます。一部のブラウザは、非推奨の共通名を無視します。

RFC 2818は、「タイプdNSNameのsubjectAltName拡張子が存在する場合は、それをIDとして使用する必要があります。それ以外の場合は、証明書のサブジェクトフィールドの（最も具体的な）共通名フィールドを使用する必要があります。ただし、共通の使用は名前は既存の慣行であり、非推奨であり、認証局は代わりにdNSNameを使用することをお勧めします。」

私も同じ問題を抱えていました。私の場合、digitaloceanとnginxを使用していました。
最初に、digitaloceanにドメインexample.appとサブドメインdev.exemple.appを設定しました。次に、godaddyから2つのSSL証明書を購入しました。そして最後に、次のスニペットでこれら2つのSSL証明書を使用するようにnginxで2つのドメインを構成しました

私の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

私の間違いは以下の2行でした

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

これを次のように変更する必要がありました。

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