No subject alternative DNS name matching api.example.com found.

Der Host ist der aus deiner URL. JDK 21 und 25 stellen den TLS-Alert voran: „(certificate_unknown) No subject alternative DNS name matching … found.“. Zertifikate ganz ohne SAN-Erweiterung ergeben stattdessen „No subject alternative names present“, URLs mit IP-Adresse „No subject alternative names matching IP address … found“.

Java (JSSE HostnameChecker) — java.security.cert.CertificateException inside SSLHandshakeException

Was der Fehler bedeutet

Die Zertifikatskette ist vertrauenswürdig, aber die Hostnamenprüfung von Java (Identifikation des HTTPS-Endpunkts) hat in der Erweiterung Subject Alternative Name des Zertifikats keinen DNS-Eintrag gefunden, der zum Host in der URL passt. Java nennt in der Meldung den Host, den es erreichen sollte. Da das Zertifikat eine SAN-Erweiterung hat, wird sein Common Name nicht berücksichtigt.

Warum der Fehler auftritt

• Das Zertifikat deckt diesen Hostnamen nicht ab

  häufig

  Das Zertifikat wurde für andere Namen ausgestellt (www., die Apex-Domain, ein alter Dienstname); ein Wildcard-Eintrag deckt nur ein einziges Label ab.

• Der Client verwendet einen internen Alias oder Dienstnamen

  häufig

  Kubernetes-Service-Namen, Aliase aus docker-compose und Hostnamen von Load Balancern erreichen den richtigen Server, stehen aber nicht in einem Zertifikat, das für den öffentlichen Namen ausgestellt wurde.

• Der Server hat das Zertifikat einer anderen Website geliefert

  gelegentlich

  Auf gemeinsam genutzten Endpunkten hängt das Zertifikat von SNI ab; ein nicht konfigurierter Name bekommt das Standardzertifikat.

So behebst du den Fehler

1. 1.

   Namen des Zertifikats auflisten

   openssl oder keytool -printcert -sslserver zeigt die Einträge von SubjectAlternativeName, die du mit der URL vergleichen kannst.

   echo | openssl s_client -connect api.example.com:443 -servername api.example.com 2>/dev/null \
     | openssl x509 -noout -ext subjectAltName
   # or with Java's own tool
   keytool -printcert -sslserver api.example.com:443 | grep -A3 SubjectAlternativeName

2. 2.

   Zertifikat mit den fehlenden Namen neu ausstellen

   Beantrage jeden DNS-Namen, den Clients verwenden; die Option -ext SAN=dns:…,dns:… von keytool fügt sie dem CSR hinzu.

   # Java keystores: request a certificate with every name in the SAN extension
   keytool -certreq -alias server -keystore server.p12 -ext "SAN=dns:api.example.com,dns:www.example.com" -file server.csr

3. 3.

   Mit einem Namen verbinden, den das Zertifikat enthält

   Lass die Hostnamenprüfung eingeschaltet und ändere stattdessen die URL (und die Namensauflösung); ein HostnameVerifier, der alles akzeptiert, hebt genau den Schutz auf, für den es TLS gibt.

   // Use the name in the certificate in the URL; resolve it to the address you need
   // (DNS, /etc/hosts or a custom resolver), instead of connecting by IP or alias.
   HttpRequest req = HttpRequest.newBuilder(URI.create("https://www.example.com/health")).build();

← Gesamte Signaturfehler-Datenbank durchsuchen