Curl: correzione dell'errore SSL CURL (51): nessun nome del soggetto del certificato alternativo corrisponde

88

Sono nuovo nel mondo CURL, vengo dal dominio Windows + .NET.

Tentativo di accedere all'API Rest per l'autenticazione di base su http://www.evercam.io/docs/api/v1/authentication .

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

Non so come utilizzare questo comando sul prompt dei comandi di Windows dopo aver installato correttamente CURL. CURL testato come segue:

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

Ora sto finendo con questo

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'

Come posso correggere questo errore 51 del problema SSL?

ssl  curl  https 
— theGeekster
fonte

Risposte:

113

Di solito accade quando il certificato non corrisponde al nome host.

La soluzione sarebbe contattare l'host e chiedergli di correggere il suo certificato.
Altrimenti puoi disattivare la verifica del certificato da parte di cURL, usa l' opzione -k(o --insecure).
Si prega di notare che come l'opzione ha detto, è insicuro . Non dovresti usare questa opzione perché consente attacchi man-in-the-middle e vanifica lo scopo di HTTPS.

Ulteriori informazioni possono essere trovate qui: http://curl.haxx.se/docs/sslcerts.html

— Sabuj Hassan
fonte
10
Le risposte che dicono di disattivare il controllo dovrebbero anche evidenziare quali sono le conseguenze. Questo è pericoloso!
— DrP3pp3r
1
Quello che immaginavo fosse il nome del soggetto sul certificato era *.my-domain.comche non si applicava a dev.subdomain.my-domain.com. Ma funziona bene per dev-subdomain.my-domain.com. Quindi, per far funzionare più sottodomini, forse hai bisogno di ciò che dice questo articolo - sslshopper.com/…
— prayagupd
77

Nota del redattore: questo è un approccio molto pericoloso, se stai usando una versione di PHP abbastanza vecchia per usarla. Apre il tuo codice ad attacchi man-in-the-middle e rimuove uno degli scopi principali di una connessione crittografata. La possibilità di farlo è stata rimossa dalle versioni moderne di PHP perché è così pericolosa. L'unico motivo per cui questo è stato votato 70 volte è perché le persone sono pigre. NON FARLO.

So che è una domanda (molto) vecchia e riguarda la riga di comando, ma quando ho cercato su Google "SSL: nessun nome del soggetto del certificato alternativo corrisponde al nome host di destinazione", questo è stato il primo risultato.

Mi ci è voluto un bel po 'per capire la risposta, quindi spero che questo faccia risparmiare un sacco di tempo a qualcuno! In PHP aggiungi questo al tuo setopts cUrl:

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

ps: questa dovrebbe essere una soluzione temporanea. Poiché si tratta di un errore del certificato, la cosa migliore è che il certificato venga riparato ovviamente!

— JD_N_PHP
fonte
30
Bene, questo è emerso nella mia ricerca su Google per il problema che stavo avendo in PHP, quindi questo è stato utile per me.
— Gujamin
1
Ho fatto la stessa ricerca e sono felice di avere la tua risposta qui. Grazie!
— CptMisery
2
CURLOPT_SSL_VERIFYHOSTnel mio caso è stato sufficiente
— 1234ru
Grazie utile a scopo di test se non hai ancora i tuoi certificati.
— Andrew
20

Il nome comune nel certificato per api.evercam.ioè per *.herokuapp.come non ci sono nomi di soggetto alternativi nel certificato. Ciò significa che il certificato per api.evercam.ionon corrisponde al nome host e quindi la verifica del certificato non riesce. Come per www.evercam.io, ad esempio, prova https://www.evercam.io con un browser e ricevi il messaggio di errore, che il nome nel certificato non corrisponde al nome host.

Quindi è un problema che deve essere risolto da evercam.io. Se non ti interessa la sicurezza, gli attacchi man-in-the-middle ecc. Potresti disabilitare la verifica del certificato ( curl --insecure), ma dovresti chiederti perché usi https invece di http.

— Steffen Ullrich
fonte
4

potrebbe far risparmiare tempo a qualcuno.

Se usi GuzzleHttp e ti trovi di fronte a questo messaggio di errore cURL error 60: SSL: nessun nome del soggetto del certificato alternativo corrisponde al nome host di destinazione e stai bene con la soluzione 'insicura' (non consigliata in produzione), devi aggiungere \GuzzleHttp\RequestOptions::VERIFY => falseal client configurazione:

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

che viene impostato CURLOPT_SSL_VERIFYHOSTsu 0 e CURLOPT_SSL_VERIFYPEERsu false nel CurlFactory::applyHandlerOptions()metodo

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

Dalla documentazione di GuzzleHttp

verificare

Descrive il comportamento di verifica del certificato SSL di una richiesta.

  • Impostare su true per abilitare la verifica del certificato SSL e utilizzare il bundle CA predefinito> fornito dal sistema operativo.
  • Impostare su false per disabilitare la verifica del certificato (non è sicuro!).
  • Impostare su una stringa per fornire il percorso a un bundle CA per abilitare la verifica utilizzando un certificato personalizzato.
— Zoltán Süle
fonte
0

Come dice il codice di errore, "nessun nome alternativo del soggetto del certificato corrisponde al nome host di destinazione", quindi c'è un problema con il certificato SSL.

Il certificato deve includere SAN e verrà utilizzata solo SAN. Alcuni browser ignorano il nome comune deprecato.

RFC 2818 afferma chiaramente: "Se è presente un'estensione subjectAltName di tipo dNSName, DEVE essere utilizzata come identità. In caso contrario, DEVE essere utilizzato il campo Common Name (più specifico) nel campo Subject del certificato. Sebbene l'uso del Common Il nome è una pratica esistente, è deprecato e le autorità di certificazione sono incoraggiate a utilizzare invece dNSName. "

— povlhp
fonte
0

Ho avuto lo stesso problema. Nel mio caso stavo usando digitalocean e nginx.
Ho prima configurato un dominio example.app e un sottodominio dev.exemple.app in digitalocean. In secondo luogo, ho acquistato due certificati SSL da Godaddy. Infine, ho configurato due domini in nginx per utilizzare quei due certificati ssl con il seguente snipet

La mia configurazione del dominio 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;
    }
 }

Il mio 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;
    }
 }

Quando stavo lanciando https://dev.echantillonnage.app , stavo ottenendo

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

Il mio errore sono state le due righe qui sotto

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

Ho dovuto cambiarlo in:

     listen 443 ssl;
     listen [::]:443 ssl;
— solo io
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.