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

Ответ 1

Обычно это происходит, когда сертификат не совпадает с именем хоста.

Решение состоит в том, чтобы связаться с хостом и попросить его исправить свой сертификат.
В противном случае вы можете отключить проверку сертификата cURL, используя -k (или --insecure).
Обратите внимание, что, как сказал вариант, это небезопасно. Вы не должны использовать эту опцию в производстве, так как она позволяет самозаверяющие сертификаты.

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

Ответ 2

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

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

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

p.s: это должно быть временным решением. Поскольку это ошибка сертификата, лучше всего иметь сертификат, установленный для вас!

Ответ 3

Общее имя в сертификате для api.evercam.io для *.herokuapp.com, и в сертификате нет альтернативных имен объектов. Это означает, что сертификат для api.evercam.io не соответствует имени хоста, поэтому проверка сертификата не выполняется. То же, что и для www.evercam.io, например. попробуйте https://www.evercam.io с браузером, и вы получите сообщение об ошибке, что имя в сертификате не совпадает с именем хоста.

Так что это проблема, которая должна быть исправлена ​​с помощью evercam.io. Если вы не заботитесь о безопасности, атаках "человек-в-середине" и т.д., Вы можете отключить проверку сертификата (curl --insecure), но тогда вы должны спросить себя, почему вы используете https вместо http вообще.

Ответ 4

Как говорится в коде ошибки, "альтернативное имя субъекта сертификата не соответствует имени целевого хоста" - поэтому существует проблема с сертификатом SSL.

Сертификат должен включать SAN, и будет использоваться только SAN. Некоторые браузеры игнорируют устаревшее общее имя.

RFC 2818 четко заявляет: "Если присутствует расширение subjectAltName типа dNSName, то оно ДОЛЖНО использоваться в качестве идентификатора. В противном случае ДОЛЖНО использоваться поле (наиболее конкретное) общего имени в поле" Тема "сертификата. Хотя использование общего Имя является существующей практикой, оно устарело, и сертификационным органам рекомендуется вместо этого использовать dNSName. "

Ответ 5

Я была такая же проблема. В моем случае я использовал 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;

Ответ 6

это может сэкономить время кому-то.

Если вы используете GuzzleHttp и сталкиваетесь с этим сообщением об ошибке cURL error 60: SSL: альтернативное имя субъекта сертификата не совпадает с именем целевого хоста, и у вас все в порядке с "небезопасным" решением (не рекомендуется в \GuzzleHttp\RequestOptions::VERIFY => false), то вам необходимо добавить \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 в false в CurlFactory::applyHandlerOptions()

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

Из документации GuzzleHttp

проверить

Описывает поведение запроса подтверждения сертификата SSL.

• Установите значение true, чтобы включить проверку сертификата SSL и использовать пакет CA по умолчанию>, предоставляемый операционной системой.
• Установите в false, чтобы отключить проверку сертификата (это небезопасно!).
• Задайте строку, чтобы указать путь к центру сертификации, чтобы включить проверку с использованием настраиваемого сертификата.