Behebung des CURL (51) SSL-Fehlers: Es stimmt kein Name des alternativen Zertifikatssubjekts überein

86

Ich bin neu in der CURL-Welt und komme aus der Windows + .NET-Domäne.

Versuch, auf die Rest-API für die Basisauthentifizierung unter http://www.evercam.io/docs/api/v1/authentication zuzugreifen .

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

Ich weiß nicht, wie ich diesen Befehl an der Windows-Eingabeaufforderung verwenden soll, nachdem CURL erfolgreich eingerichtet wurde. Getestete CURL wie folgt:

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

Jetzt beende ich damit

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'

Wie kann ich diesen SSL-Fehler 51 beheben?

ssl  curl  https 
— theGeekster
quelle

Antworten:

112

Dies geschieht normalerweise, wenn das Zertifikat nicht mit dem Hostnamen übereinstimmt.

Die Lösung wäre, den Host zu kontaktieren und ihn zu bitten, sein Zertifikat zu reparieren.
Andernfalls können Sie die cURL-Überprüfung des Zertifikats deaktivieren und die Option -k(oder --insecure) verwenden.
Bitte beachten Sie, dass es, wie die Option sagte, unsicher ist . Sie sollten diese Option nicht verwenden, da sie Man-in-the-Middle-Angriffe ermöglicht und den Zweck von HTTPS zunichte macht.

Weitere finden Sie hier: http://curl.haxx.se/docs/sslcerts.html

— Sabuj Hassan
quelle
10
Antworten, die sagen, dass der Check deaktiviert werden soll, sollten auch die Konsequenzen hervorheben. Das ist gefährlich!
— DrP3pp3r
1
Ich nahm an, dass der Name des Betreffs auf dem Zertifikat *.my-domain.comnicht zutraf dev.subdomain.my-domain.com. Funktioniert aber gut für dev-subdomain.my-domain.com. Damit mehrere Subdomains
— betagupd
76

Anmerkung des Herausgebers: Dies ist ein sehr gefährlicher Ansatz, wenn Sie eine Version von PHP verwenden, die alt genug ist, um sie zu verwenden. Es öffnet Ihren Code für Man-in-the-Middle-Angriffe und entfernt einen der Hauptzwecke einer verschlüsselten Verbindung. Die Möglichkeit, dies zu tun, wurde aus modernen Versionen von PHP entfernt, weil es so gefährlich ist. Der einzige Grund, warum dies 70 Mal positiv bewertet wurde, ist, dass die Leute faul sind. MACH DAS NICHT.

Ich weiß, dass es sich um eine (sehr) alte Frage handelt und es sich um eine Befehlszeile handelt. Als ich jedoch bei Google nach "SSL: Kein alternativer Name des Zertifikatssubjekts stimmt mit dem Namen des Zielhosts überein" suchte, war dies der erste Treffer.

Ich habe eine Weile gebraucht, um die Antwort herauszufinden. Ich hoffe, das spart jemandem viel Zeit! Fügen Sie dies in PHP zu Ihren cUrl-Setopts hinzu:

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

ps: dies sollte eine vorübergehende lösung sein. Da dies ein Zertifikatfehler ist, ist es am besten, das Zertifikat natürlich reparieren zu lassen!

— JD_N_PHP
quelle
30
Nun, dies tauchte in meiner Google-Suche nach dem Problem auf, das ich in PHP hatte, also war dies hilfreich für mich.
— Gujamin
1
Ich habe die gleiche Suche durchgeführt und bin froh, Ihre Antwort hier zu haben. Vielen Dank!
— CptMisery
2
CURLOPT_SSL_VERIFYHOSTwar genug in meinem Fall
— 1234ru
Vielen Dank für Testzwecke, wenn Sie Ihre Zertifikate noch nicht haben.
— Andrew
20

Der gebräuchliche Name im Zertifikat für api.evercam.ioist für *.herokuapp.comund es gibt keine alternativen Betreffnamen im Zertifikat. Dies bedeutet, dass das Zertifikat für api.evercam.ionicht mit dem Hostnamen übereinstimmt und daher die Zertifikatüberprüfung fehlschlägt. Gleiches gilt für www.evercam.ioz. B. https://www.evercam.io mit einem Browser und Sie erhalten die Fehlermeldung, dass der Name im Zertifikat nicht mit dem Hostnamen übereinstimmt.

Es ist also ein Problem, das von evercam.io behoben werden muss. Wenn Sie sich nicht um Sicherheit, Man-in-the-Middle-Angriffe usw. kümmern, können Sie die Überprüfung des Zertifikats ( curl --insecure) deaktivieren. Dann sollten Sie sich jedoch fragen, warum Sie überhaupt https anstelle von http verwenden.

— Steffen Ullrich
quelle
3

es könnte jemandem etwas Zeit sparen.

Wenn Sie GuzzleHttp verwenden und die Fehlermeldung cURL-Fehler 60 angezeigt wird : SSL: Kein alternativer Name des Zertifikatssubjekts stimmt mit dem Namen des Zielhosts überein, und Sie sind mit der unsicheren Lösung (in der Produktion nicht empfohlen) einverstanden. Dann müssen Sie sie \GuzzleHttp\RequestOptions::VERIFY => falsedem Client hinzufügen Aufbau:

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

Dies setzt in der Methode CURLOPT_SSL_VERIFYHOSTauf 0 und CURLOPT_SSL_VERIFYPEERauf falseCurlFactory::applyHandlerOptions()

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

Aus der GuzzleHttp-Dokumentation

überprüfen

Beschreibt das Verhalten einer Anforderung zur Überprüfung des SSL-Zertifikats.

  • Setzen Sie diesen Wert auf true, um die Überprüfung des SSL-Zertifikats zu aktivieren und das vom Betriebssystem bereitgestellte Standard-CA-Bundle zu verwenden.
  • Auf false setzen, um die Zertifikatsüberprüfung zu deaktivieren (dies ist unsicher!).
  • Legen Sie eine Zeichenfolge fest, um den Pfad zu einem CA-Bundle anzugeben und die Überprüfung mithilfe eines benutzerdefinierten Zertifikats zu ermöglichen.
— Zoltán Süle
quelle
0

Wie im Fehlercode angegeben, stimmt kein Name des alternativen Zertifikatssubjekts mit dem Namen des Zielhosts überein. Daher liegt ein Problem mit dem SSL-Zertifikat vor.

Das Zertifikat sollte SAN enthalten, und es wird nur SAN verwendet. Einige Browser ignorieren den veralteten allgemeinen Namen.

In RFC 2818 heißt es eindeutig: "Wenn eine subjectAltName-Erweiterung vom Typ dNSName vorhanden ist, MUSS diese als Identität verwendet werden. Andernfalls MUSS das (spezifischste) Feld Common Name im Feld Subject des Zertifikats verwendet werden. Obwohl die Verwendung Common verwendet wird Der Name ist eine gängige Praxis, er ist veraltet und Zertifizierungsstellen werden aufgefordert, stattdessen den dNSName zu verwenden. "

— povlhp
quelle
0

Ich hatte das gleiche Problem. In meinem Fall habe ich Digitalocean und Nginx verwendet.
Ich habe zuerst eine Domain example.app und eine Subdomain dev.exemple.app in digitalocean eingerichtet. Zweitens habe ich zwei SSL-Zertifikate von Godaddy gekauft. Und schließlich habe ich zwei Domänen in Nginx so konfiguriert, dass diese beiden SSL-Zertifikate mit dem folgenden Snipet verwendet werden

Meine example.app Domain Konfiguration 

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

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

Als ich https://dev.echantillonnage.app startete , bekam ich

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

Mein Fehler waren die beiden Zeilen unten

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

Ich musste dies ändern in:

     listen 443 ssl;
     listen [::]:443 ssl;
— nur ich
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.