Исправить ошибку SSL CURL (51): альтернативное имя субъекта сертификата не соответствует

Я новичок в мире CURL, пришедший из домена Windows + .NET.

Попытка получить доступ к Rest API для базовой аутентификации по адресу http://www.evercam.io/docs/api/v1/authentication .

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

Не знаю, как использовать эту команду в командной строке Windows после успешной настройки CURL. Тестировал 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).
Обратите внимание, что, как сказано в варианте, это небезопасно . Вы не должны использовать эту опцию, потому что она допускает атаки типа «злоумышленник посередине» и сводит на нет цель HTTPS.

Больше можно найти здесь: http://curl.haxx.se/docs/sslcerts.html

Примечание редактора: это очень опасный подход, если вы используете достаточно старую версию PHP для его использования. Он открывает ваш код для атак типа «злоумышленник в середине» и устраняет одну из основных целей зашифрованного соединения. Возможность делать это удалена из современных версий PHP, потому что это очень опасно. Единственная причина, по которой за него проголосовали 70 раз, заключается в том, что люди ленивы. НЕ ДЕЛАЙТЕ ЭТОГО.

Я знаю, что это (очень) старый вопрос, и он касается командной строки, но когда я поискал в Google по запросу «SSL: ни одно альтернативное имя субъекта сертификата не соответствует имени целевого хоста», это был первый ответ.

Мне потребовалось немало времени, чтобы найти ответ, так что надеюсь, что это сэкономит кому-то много времени! В PHP добавьте это в свои настройки cUrl:

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 error 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_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 четко заявляет: «Если присутствует расширение subjectAltName типа dNSName, оно ДОЛЖНО использоваться в качестве идентификатора. В противном случае ДОЛЖНО использоваться (наиболее конкретное) поле Common Name в поле Subject сертификата. Хотя использование Common Имя - это существующая практика, она устарела, и сертификационным центрам рекомендуется использовать вместо этого dNSName ".

Я была такая же проблема. В моем случае я использовал digitalocean и nginx.
Сначала я установил домен example.app и поддомен dev.exemple.app в digitalocean. Во-вторых, я купил два сертификата ssl от godaddy. И, наконец, я настроил два домена в 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;