Napraw błąd SSL CURL (51): żadna alternatywna nazwa podmiotu certyfikatu nie pasuje

Jestem nowy w świecie CURL, pochodzę z domeny Windows + .NET.

Próba uzyskania dostępu do Rest API w celu podstawowego uwierzytelnienia pod adresem http://www.evercam.io/docs/api/v1/authentication .

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

Nie wiem, jak używać tego polecenia w wierszu poleceń systemu Windows po pomyślnym skonfigurowaniu CURL. Testowany CURL w następujący sposób:

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

Teraz na tym kończę

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'

Jak mogę naprawić ten błąd SSL 51?

Zwykle dzieje się tak, gdy certyfikat nie jest zgodny z nazwą hosta.

Rozwiązaniem byłoby skontaktowanie się z hostem i poproszenie go o naprawienie certyfikatu.
W przeciwnym razie możesz wyłączyć weryfikację certyfikatu przez cURL, użyj opcji -k(lub --insecure).
Należy pamiętać, że zgodnie z opcją jest to niebezpieczne . Nie powinieneś używać tej opcji, ponieważ umożliwia ona ataki typu man-in-the-middle i niweczy cel HTTPS.

Więcej można znaleźć tutaj: http://curl.haxx.se/docs/sslcerts.html

Uwaga edytora: jest to bardzo niebezpieczne podejście, jeśli używasz wystarczająco starej wersji PHP, aby z niej korzystać. Otwiera twój kod na ataki man-in-the-middle i usuwa jeden z głównych celów szyfrowanego połączenia. Możliwość robienia tego została usunięta z nowoczesnych wersji PHP, ponieważ jest tak niebezpieczna. Jedynym powodem, dla którego głosowano 70 razy, jest to, że ludzie są leniwi. NIE RÓB TEGO.

Wiem, że to (bardzo) stare pytanie i dotyczy wiersza poleceń, ale kiedy szukałem w Google hasła „SSL: żadna alternatywna nazwa podmiotu certyfikatu nie pasuje do nazwy hosta docelowego”, to był pierwszy trafienie.

Znalezienie odpowiedzi zajęło mi sporo czasu, więc mam nadzieję, że zaoszczędzi to komuś dużo czasu! W PHP dodaj to do swoich ustawień cUrl:

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

ps: powinno to być rozwiązanie tymczasowe. Ponieważ jest to błąd certyfikatu, najlepiej jest oczywiście go naprawić!

Nazwa zwyczajowa w certyfikacie dla api.evercam.iojest przeznaczona dla *.herokuapp.comi nie ma alternatywnych nazw podmiotów w certyfikacie. Oznacza to, że certyfikat dla api.evercam.ionie jest zgodny z nazwą hosta i dlatego weryfikacja certyfikatu kończy się niepowodzeniem. To samo co prawda www.evercam.io, np. Spróbuj https://www.evercam.io z przeglądarką, a otrzymasz komunikat o błędzie, że nazwa w certyfikacie nie jest zgodna z nazwą hosta.

Jest to więc problem, który musi rozwiązać evercam.io. Jeśli nie zależy Ci na bezpieczeństwie, atakach typu man-in-the-middle itp., Możesz wyłączyć weryfikację certyfikatu ( curl --insecure), ale wtedy powinieneś zadać sobie pytanie, dlaczego w ogóle używasz https zamiast http.

może to komuś zaoszczędzić trochę czasu.

Jeśli używasz GuzzleHttp i napotykasz ten komunikat o błędzie Błąd cURL 60: SSL: żadna alternatywna nazwa podmiotu certyfikatu nie pasuje do nazwy hosta docelowego i nie ma problemu z rozwiązaniem `` niezabezpieczonym '' (niezalecane na produkcji), musisz dodać \GuzzleHttp\RequestOptions::VERIFY => falsedo klienta konfiguracja:

$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,
]);

która ustawia wartość CURLOPT_SSL_VERIFYHOST0 i CURLOPT_SSL_VERIFYPEERfałsz w CurlFactory::applyHandlerOptions()metodzie

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

Z dokumentacji GuzzleHttp

zweryfikować

Opisuje zachowanie weryfikacji certyfikatu SSL w żądaniu.

• Ustaw na true, aby włączyć weryfikację certyfikatu SSL i użyć domyślnego pakietu CA> dostarczonego przez system operacyjny.
• Ustaw wartość false, aby wyłączyć weryfikację certyfikatu (to niebezpieczne!).
• Ustaw na ciąg, aby podać ścieżkę do pakietu urzędu certyfikacji, aby umożliwić weryfikację przy użyciu certyfikatu niestandardowego.

Jak mówi kod błędu, „żadna alternatywna nazwa podmiotu certyfikatu nie pasuje do nazwy hosta docelowego” - występuje więc problem z certyfikatem SSL.

Certyfikat powinien zawierać SAN i będzie używana tylko sieć SAN. Niektóre przeglądarki ignorują przestarzałą nazwę zwykłą.

RFC 2818 wyraźnie stwierdza, że ​​„Jeśli istnieje rozszerzenie subjectAltName typu dNSName, MUSI być ono użyte jako tożsamość. W przeciwnym razie MUSI być użyte (najbardziej szczegółowe) pole Common Name w polu Subject certyfikatu. Chociaż użycie Common Nazwa jest istniejącą praktyką, jest przestarzała, a urzędy certyfikacji są zachęcane do używania zamiast tego nazwy dNSName. "

Miałem ten sam problem. W moim przypadku korzystałem z digitalocean i nginx.
Najpierw skonfigurowałem domenę example.app i subdomenę dev.exemple.app w digitalocean. Po drugie, kupiłem dwa certyfikaty SSL od GoDaddy. Na koniec skonfigurowałem dwie domeny w nginx, aby używać tych dwóch certyfikatów ssl z następującym snipetem

Moja konfiguracja domeny 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;
    }
 }

Moja 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;
    }
 }

Kiedy uruchamiałem https://dev.echantillonnage.app , otrzymywałem

    Fix CURL (51) SSL error: no alternative certificate subject name matches

Moim błędem były dwie linie poniżej

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

Musiałem to zmienić na:

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