web-dev-qa-db-de.com

Behebung des CURL (51) SSL-Fehlers: Kein alternativer Zertifikatbetreffname stimmt überein

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

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

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

Sie wissen nicht, wie Sie diesen Befehl in der Windows-Eingabeaufforderung verwenden sollen, nachdem das CURL-Setup erfolgreich war. 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 höre ich damit auf

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 Fehler bei SSL-Problem 51 beheben?

50
theGeekster

Dies passiert 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, indem Sie die Option -k (Oder --insecure) Verwenden.
Bitte beachten Sie, dass die angegebene Option unsicher ist . Sie sollten diese Option in der Produktion nicht verwenden, da sie selbstsignierte Zertifikate zulässt.

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

76
Sabuj Hassan

Ich weiß, es ist eine (sehr) alte Frage und es geht um die Befehlszeile, aber als ich bei Google nach "SSL: Kein alternativer Name des Zertifikatsbetreffs stimmt mit dem Namen des Zielhosts überein" suchte, war dies der erste Treffer.

Es hat eine Weile gedauert, bis ich die Antwort gefunden habe. Ich hoffe, das spart jemandem viel Zeit! In PHP füge dies zu deinen cUrl-Einstellungen 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!

61
JD_N_PHP

Der gebräuchliche Name im Zertifikat für api.evercam.io ist für *.herokuapp.com und das Zertifikat enthält keine alternativen Antragstellernamen. Dies bedeutet, dass das Zertifikat für api.evercam.io stimmt nicht mit dem Hostnamen überein und daher schlägt die Zertifikatüberprüfung fehl. Dasselbe wie für www.evercam.io, z.B. Versuchen Sie 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 deaktivieren (curl --insecure), aber dann sollten Sie sich fragen, warum Sie überhaupt https anstelle von http verwenden.

20
Steffen Ullrich

es könnte jemandem etwas Zeit sparen.

Wenn Sie GuzzleHttp verwenden und diese Fehlermeldung angezeigt wird cURL-Fehler 60: SSL: Kein alternativer Zertifikatbetreff stimmt mit dem Hostnamen des Ziels überein und die 'unsichere' Lösung ist in Ordnung (nicht für die Produktion empfohlen), dann müssen Sie der Client-Konfiguration \GuzzleHttp\RequestOptions::VERIFY => false hinzufügen:

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

hierdurch wird CURLOPT_SSL_VERIFYHOST in der CurlFactory::applyHandlerOptions() -Methode auf 0 und CURLOPT_SSL_VERIFYPEER auf false gesetzt

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

Aus der GuzzleHttp-Dokumentation

überprüfe

Beschreibt das SSL-Zertifikat-Überprüfungsverhalten einer Anforderung.

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

Wie der Fehlercode besagt, stimmt kein alternativer Zertifikatbetreffname mit dem Hostnamen des Ziels überein, sodass ein Problem mit dem SSL-Zertifikat vorliegt.

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

RFC 2818 besagt 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 Der Name ist eine gängige Praxis, er ist veraltet, und Zertifizierungsstellen werden aufgefordert, stattdessen den dNS-Namen zu verwenden. "

0
povlhp

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 config

    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 startete https://dev.echantillonnage.app , bekam ich

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

Mein Fehler war die zwei Zeilen unten

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

Ich musste das ändern zu:

     listen 443 ssl;
     listen [::]:443 ssl;
0
onlyme