Виправлено помилку SSL CURL (51): жодна назва теми сертифіката не збігається


86

Я новачок у світі CURL, походячи з домену Windows + .NET.

Спроба отримати доступ до 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?

Відповіді:


112

Зазвичай це відбувається, коли сертифікат не відповідає імені хоста.

Рішенням було б зв’язатися з хостом і попросити його виправити свій сертифікат.
В іншому випадку ви можете вимкнути перевірку сертифіката за допомогою CURL, скориставшись опцією -k(або --insecure).
Зверніть увагу, що, як зазначено в опції, це небезпечно . Ви не повинні використовувати цю опцію, оскільки вона дозволяє атаки "посередині" та перемагає призначення HTTPS.

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


10
Відповіді, що вимагають вимкнути чек, також повинні наголошувати на наслідках. Це небезпечно!
DrP3pp3r

1
Річ, яку я припустив, - це тематична назва на сертифікаті, *.my-domain.comяка не стосується dev.subdomain.my-domain.com. Але чудово працює для dev-subdomain.my-domain.com. Тож, щоб працювати кілька піддоменів, можливо, вам потрібно те, про що йдеться в цій статті - sslshopper.com/…
prayagupd

76

Примітка редактора: це дуже небезпечний підхід, якщо ви використовуєте версію PHP, досить стару для її використання. Він відкриває ваш код для атак "людина посередині" і усуває одну з основних цілей зашифрованого з'єднання. Здатність робити це було вилучено із сучасних версій PHP, оскільки це настільки небезпечно. Єдина причина, за яку це було підписано 70 разів, полягає в тому, що люди ледачі. НЕ РОБИ ЦЬОГО.


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

Мені знадобився гарний час, щоб зрозуміти відповідь, тому сподіваюся, це заощадить комусь багато часу! У PHP додайте це до своїх секторів cUrl:

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

ps: це має бути тимчасовим рішенням. Оскільки це помилка сертифіката, найкраще, щоб сертифікат був виправлений звичайно!


30
Ну, це з’явилось у моєму пошуковому запиті Google щодо проблеми, з якою я стикався в PHP, так що це було мені корисно.
Гуджамін

1
Я здійснив той самий пошук, і я радий вашій відповіді тут. Дякую!
CptMisery

2
CURLOPT_SSL_VERIFYHOSTу моєму випадку було достатньо
1234ру

Подяка, корисна для тестування, якщо у вас ще немає сертифікатів.
Ендрю

20

Загальна назва в сертифікаті для api.evercam.io- це, *.herokuapp.comі в сертифікаті відсутні альтернативні назви предметів. Це означає, що сертифікат для api.evercam.ioне відповідає імені хосту, і тому перевірка сертифіката не вдається. Так само, як і для www.evercam.io, наприклад, спробуйте https://www.evercam.io за допомогою браузера, і ви отримаєте повідомлення про помилку, що ім'я в сертифікаті не відповідає імені хосту.

Отже, це проблема, яку потребує вирішення evercam.io. Якщо ви не дбаєте про безпеку, атаки "людина посередині" тощо, ви можете відключити перевірку сертифіката ( curl --insecure), але тоді вам слід запитати себе, чому ви взагалі використовуєте https замість http.


3

це може заощадити комусь час.

Якщо ви використовуєте 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>, наданий операційною системою.
  • Встановіть значення false, щоб вимкнути перевірку сертифіката (це небезпечно!).
  • Встановіть у рядок, щоб вказати шлях до набору CA, щоб увімкнути перевірку за допомогою спеціального сертифіката.

0

Як зазначається в коді помилки, "жодна назва альтернативного сертифіката не відповідає імені цільового хосту" - отже, проблема з сертифікатом SSL.

Сертифікат повинен містити SAN, і використовуватиметься лише SAN. Деякі браузери ігнорують застаріле загальне ім'я.

RFC 2818 чітко зазначає: "Якщо присутнє розширення subjectAltName типу dNSName, це ПОВИННО використовуватись як ідентичність. В іншому випадку ПОВИННО використовуватись (найбільш конкретне) поле Загальне ім'я в полі Тема сертифіката. Хоча використання загального Ім'я є існуючою практикою, воно застаріло, і Центрам сертифікації рекомендується використовувати замість цього dNSName. "


0

У мене була та сама проблема. У моєму випадку я використовував 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;
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.