Hostname/IP does not match certificate's altnames: Host: api.example.com. is not in the cert's altnames: DNS:www.example.com

Der Host und die Liste der altnames hängen vom jeweiligen Fehlerfall ab. Bei IP-Adressen lautet die Meldung „Hostname/IP does not match certificate's altnames: IP: <address> is not in the cert's list: <entries>“. npm zeigt sie als „npm error code ERR_TLS_CERT_ALTNAME_INVALID“.

Node.js tls.checkServerIdentity() — code ERR_TLS_CERT_ALTNAME_INVALID

Was der Fehler bedeutet

Die Zertifikatskette ist vertrauenswürdig, aber tls.checkServerIdentity() hat keinen Subject Alternative Name gefunden, der zu dem Host passt, mit dem sich Node.js verbunden hat. Die Meldung nennt beide Seiten: den Host, den du angefragt hast, und die Namen, die das Zertifikat tatsächlich enthält, sodass die Abweichung sofort zu sehen ist. Der Common Name wird ignoriert, wenn das Zertifikat eine SAN-Erweiterung hat.

Warum der Fehler auftritt

• Das Zertifikat enthält diesen Namen nicht

  häufig

  Ein Zertifikat für www.example.com deckt weder api.example.com noch die Domain selbst ab; Wildcards decken nur ein einzelnes Label ab.

• Verbindung über IP, localhost oder einen Container-Alias

  häufig

  URLs wie https://127.0.0.1:8443 oder https://backend:443 innerhalb von docker-compose fragen nach Namen, die das Zertifikat nicht enthält; IP-Adressen brauchen IP-SAN-Einträge.

• Nur der Host-Header wurde geändert, nicht der TLS-Name

  gelegentlich

  Setzt du headers.host auf den richtigen Namen, verbindest dich aber über die IP, ändert das nichts daran, was Node.js prüft; die Option servername (oder der Host der URL) bestimmt, welcher Name geprüft und als SNI gesendet wird.

• Der Server hat sein Standardzertifikat ausgeliefert

  gelegentlich

  Ein Reverse Proxy ohne Konfiguration für diesen Namen antwortet mit dem Zertifikat einer anderen Website.

So behebst du den Fehler

1. 1.

   Namen des Zertifikats auflisten

   Vergleiche subjectAltName mit dem Host, zu dem du dich verbindest.

   echo | openssl s_client -connect api.example.com:443 -servername api.example.com 2>/dev/null \
     | openssl x509 -noout -ext subjectAltName

2. 2.

   Mit allen verwendeten Namen neu ausstellen

   Nimm alle DNS-Namen auf und, wenn sich Clients über die Adresse verbinden, auch IP-Einträge.

   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.

   servername setzen, wenn du dich über die Adresse verbindest

   Setze servername (und den Host-Header) auf den Namen des Zertifikats und verbinde dich mit der Adresse; die Prüfung verwendet dann den richtigen Namen, statt abgeschaltet zu werden.

   // Connect to an address but verify the certificate's real name (also sent as SNI)
   import https from "node:https";
   
   https.get({ host: "10.0.0.5", port: 443, path: "/", servername: "api.example.com",
               headers: { host: "api.example.com" } }, (res) => res.resume());

4. 4.

   Eng begrenzte Ausnahme mit checkServerIdentity

   Bei einem Legacy-Host, dessen Zertifikat sich noch nicht neu ausstellen lässt, ordne einen bekannten Alias dem Namen des Zertifikats zu und delegiere an tls.checkServerIdentity(). Gib niemals bedingungslos undefined zurück: Damit ist die Namensprüfung komplett abgeschaltet.

   // Narrow exception for a host you cannot reissue: accept one extra name, keep all other checks
   import https from "node:https";
   import tls from "node:tls";
   
   const agent = new https.Agent({
     checkServerIdentity: (host, cert) =>
       tls.checkServerIdentity(host === "legacy-alias.internal" ? "api.example.com" : host, cert),
   });

← Gesamte Signaturfehler-Datenbank durchsuchen