Zum Inhalt springen
ecdsa.com
curl (OpenSSL backend)curl

Fehlermeldung

curl: (60) SSL: no alternative certificate subject name matches target hostname 'api.example.com'

Auch ausgegeben als

  • curl: (60) SSL: no alternative certificate subject name matches target host name 'api.example.com'

curl 8.x gibt „target hostname“ aus; curl 7.x schrieb „target host name“. Der Host in Anführungszeichen ist genau das, was in der URL stand. Sehr alte curl-Versionen (vor 7.62.0) verwendeten für diese Prüfung den Exit-Code 51.

curl (OpenSSL backend) — CURLE_PEER_FAILED_VERIFICATION, hostname check in lib/vtls/openssl.c

Was der Fehler bedeutet

Die Zertifikatskette ist vertrauenswürdig, aber keiner der DNS-Namen (und keine der IP-Adressen) in der Erweiterung Subject Alternative Name des Zertifikats passt zum Host in der URL. curl vergleicht den Host der URL nur mit den SAN-Einträgen; der Common Name im Subject wird ignoriert, sobald eine SAN-Erweiterung vorhanden ist. Der Name in Anführungszeichen am Ende ist der Host, den curl erreichen sollte.

Warum der Fehler auftritt

So behebst du den Fehler

  1. 1.

    SAN-Liste mit der URL vergleichen

    Gib die Erweiterung subjectAltName des ausgelieferten Zertifikats aus. Die Lösung ist entweder ein Zertifikat, das den Namen aufführt, oder eine URL, die einen der aufgeführten Namen verwendet.

    bash
    # Names the served certificate actually covers
echo | openssl s_client -connect api.example.com:443 -servername api.example.com 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName
  2. 2.

    Zertifikat mit allen verwendeten Namen neu ausstellen

    Beantrage alle Hostnamen (und IP-Adressen, falls sich Clients per IP verbinden) als SAN-Einträge. Steht der Name nur im Common Name, funktioniert das mit keinem aktuellen Client.

    bash
    # ACME: list every name the certificate must cover
sudo certbot certonly --nginx -d example.com -d www.example.com -d api.example.com

# Private CA: put all names into subjectAltName (CN is ignored for matching)
openssl req -new -key server.key -out server.csr -subj "/CN=api.example.com" \
  -addext "subjectAltName=DNS:api.example.com,DNS:www.example.com,IP:10.0.0.5"
  3. 3.

    Namen beibehalten, nur die Adresse ändern

    Musst du eine bestimmte Adresse erreichen (einen Knoten des Load Balancers, einen Tunnel, eine Staging-IP), behalten --resolve oder --connect-to den Host der URL bei, sodass SNI und die Hostnamenprüfung weiterhin den Namen aus dem Zertifikat verwenden.

    bash
    # Keep the certificate's name in the URL and steer the connection to another address
curl --resolve api.example.com:443:10.0.0.5 https://api.example.com/
curl --connect-to api.example.com:443:lb-internal.example.net:443 https://api.example.com/
  4. 4.

    Eigener Server: SNI-Routing prüfen

    Unterscheidet sich das Zertifikat zwischen Anfragen mit und ohne SNI, lege für den Namen einen Server-Block (oder eine Ingress-Regel) an und stelle sicher, dass Clients für echte Hostnamen nicht das Standardzertifikat erhalten.

    bash
    # Compare what the server returns with and without SNI
openssl s_client -connect 10.0.0.5:443 -servername api.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject
openssl s_client -connect 10.0.0.5:443 -noservername </dev/null 2>/dev/null | openssl x509 -noout -subject

Verwandte Fehler

Gesamte Signaturfehler-Datenbank durchsuchen