NET::ERR_CERT_COMMON_NAME_INVALID

Was dieser Fehler bedeutet und wie du ihn erkennst

• Chrome oder Edge zeigt „Ihre Verbindung ist nicht privat“ zusammen mit NET::ERR_CERT_COMMON_NAME_INVALID an.
• Die Zertifikatsdetails zeigen einen Common Name oder Subject Alternative Name für einen anderen Hostnamen.
• Die Root-Domain funktioniert, aber eine bestimmte Subdomain schlägt fehl.
• Der Fehler beginnt nach dem Hinzufügen einer Subdomain, einer DNS-Änderung, einem Hosting-Umzug oder der Aktivierung eines CDN oder Load Balancers.
• Ein gemeinsam genutzter Server oder ein CDN präsentiert ein Standard-, Platzhalter- oder nicht zugehöriges Zertifikat.
• Einige Nutzer oder Netzwerke sehen den Fehler, andere nicht. Das deutet häufig auf unterschiedliche IPv4-, IPv6-, DNS- oder Edge-Routing-Pfade hin.

Hauptursachen nach Wahrscheinlichkeit

1. Das Zertifikat enthält den angeforderten Hostnamen nicht. Der betroffene Hostname kann in der SAN-Liste des Zertifikats fehlen. Ein Wildcard-Zertifikat kann einige Subdomains abdecken, aber sein Gültigkeitsbereich muss zum angeforderten Namen passen.
2. Der Server liefert sein Standardzertifikat aus. Beim Shared Hosting wurde das Zertifikat möglicherweise nicht der Domain zugewiesen, oder die Auswahl des Zertifikats über SNI und HTTPS-Virtual-Hosts ist falsch konfiguriert.
3. Ein CDN oder Load Balancer verwendet das falsche Edge-Zertifikat. Der Hostname ist möglicherweise nicht auf dem Dienst konfiguriert, oder die Anfrage erreicht einen Standard-Listener oder eine Standard-Edge-Konfiguration.
4. DNS verweist auf den falschen Endpunkt. Ein falscher A-, AAAA- oder CNAME-Eintrag kann die Anfrage an einen Server senden, der ein Zertifikat für eine andere Website präsentiert. Ein falscher AAAA-Eintrag kann IPv6-Nutzer betreffen, auch wenn IPv4 funktioniert.
5. Nach einer Migration oder Domainänderung sind die Dienste nicht mehr synchron. DNS, CDN, Origin-Server und Zertifikat können jeweils für unterschiedliche Hostnamen oder Endpunkte konfiguriert sein.

So behebst du den Fehler

1. Exakten Hostnamen und Zertifikatsabweichung ermitteln

Prüfen Sie den vollständigen Hostnamen in der Adressleiste einschließlich aller Subdomains. Öffnen Sie die Zertifikatsdetails des Browsers und prüfen Sie den Common Name sowie die Subject Alternative Names (SANs). Der angeforderte Hostname muss in der SAN-Liste erscheinen oder einem passenden Wildcard-Muster entsprechen.

Für eine Prüfung über die Kommandozeile setzen Sie die Variable auf den zu testenden Hostnamen:

HOSTNAME='[your hostname]'
openssl s_client -connect "$HOSTNAME:443" -servername "$HOSTNAME" </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Die Option -servername sendet den Hostnamen über SNI. Das ist bei gemeinsam genutzter HTTPS-Infrastruktur wichtig. Führen Sie Diagnosebefehle aus, bevor Sie Konfigurationsänderungen vornehmen.

2. Hostnamen zum Zertifikat hinzufügen

Wenn das Zertifikat die Root-Domain, aber nicht die betroffene Subdomain abdeckt, stellen Sie ein neues Zertifikat aus oder ersetzen Sie das vorhandene durch eines, das den erforderlichen Hostnamen als SAN enthält. Ein Wildcard-Zertifikat kann mehrere Subdomains auf einer Ebene abdecken. Prüfen Sie jedoch die Abdeckung der Root-Domain und etwaiger tieferer Subdomains separat.

Wenn Sie Certbot verwenden, bestätigen Sie zunächst, dass Sie berechtigt sind, ein Zertifikat für die Domain anzufordern und bereitzustellen, dass der Webroot korrekt ist und dass sich die Validierungsmethode für den Server eignet. Nehmen Sie jeden erforderlichen Namen in die Ausstellungsanforderung auf:

DOMAIN='[your bare domain]'
SUBDOMAIN='[your subdomain]'
certbot certonly --webroot -w '[your webroot]' -d "$DOMAIN" -d "$SUBDOMAIN"

Damit wird ein Zertifikat abgerufen, aber nicht automatisch installiert oder aktiviert. Verwenden Sie die für den Server geeignete Ausstellungsmethode und den passenden Webroot. Installieren Sie das Zertifikat anschließend auf dem Endpunkt, der HTTPS beendet, und weisen Sie es dem richtigen Hostnamen zu.

3. Shared Hosting und Origin-Server-Konfiguration prüfen

Bestätigen Sie im Hosting-Control-Panel, dass ein Zertifikat installiert und exakt der betreffenden Domain oder Subdomain zugewiesen ist. Bitten Sie den Anbieter bei einem gemeinsam genutzten Server, die SNI-basierte Zertifikatsauswahl und die HTTPS-Virtual-Host-Konfiguration zu überprüfen.

Laden Sie den Webserver erst neu oder starten Sie ihn erst dann neu, wenn Sie bestätigt haben, dass Zertifikatsdateien, Berechtigungen und Konfiguration korrekt sind. Ein Reload oder Neustart kann den Dienst unterbrechen. Befolgen Sie daher das Änderungsverfahren des Anbieters und holen Sie vor der Anwendung die erforderliche Berechtigung ein.

4. Zertifikatsabdeckung von CDN und Load Balancer prüfen

Prüfen Sie, ob der exakte Hostname auf dem CDN oder Load Balancer konfiguriert und im Edge-Zertifikat enthalten ist. Bestätigen Sie außerdem, dass der Hostname zum vorgesehenen Origin geroutet wird.

Wenn das CDN HTTPS beendet, kann das Origin-Zertifikat allein eine Browserabweichung nicht beheben. Das vom öffentlichen Edge-Endpunkt ausgelieferte Zertifikat muss den Hostnamen abdecken. Wenn das CDN HTTPS durchreicht, prüfen Sie stattdessen das Zertifikat am Origin.

5. DNS für IPv4 und IPv6 überprüfen

Vergleichen Sie die A-, AAAA- und CNAME-Einträge des Hostnamens mit dem vom Hosting- oder CDN-Anbieter angegebenen Endpunkt oder Ziel. Prüfen Sie, ob das betroffene Netzwerk IPv4 oder IPv6 verwendet und ob beide Pfade den vorgesehenen Dienst erreichen.

Korrigieren Sie veraltete oder unbeabsichtigte Einträge erst, nachdem Sie den vorgesehenen Endpunkt und das passende DNS-Änderungsverfahren bestätigt haben. Prüfen Sie das Ergebnis aus dem betroffenen Netzwerk, da zwischengespeicherte DNS-Antworten bis zum Ablauf ihrer TTL bestehen bleiben können.

6. Denselben HTTPS-Hostnamen erneut testen

Testen Sie nach Änderungen an Zertifikatszuweisung, Routing oder DNS die exakt fehlgeschlagene URL. Prüfen Sie das zurückgegebene Zertifikat erneut und bestätigen Sie SAN-Liste, Aussteller und Gültigkeitsdaten. Testen Sie sowohl aus dem betroffenen Netzwerk als auch aus der Hosting-, CDN- oder Serverumgebung, um Unterschiede bei Propagation oder Resolvern von einer aktiven Fehlkonfiguration zu unterscheiden.

Vorbeugung und Überprüfung der Lösung

• Berücksichtigen Sie die Zertifikatsabdeckung immer, wenn Sie eine Subdomain hinzufügen, DNS ändern, das Hosting migrieren oder ein CDN einbinden.
• Verwenden Sie SAN-Abdeckung oder ein passend eingeschränktes Wildcard-Zertifikat erst, nachdem Sie Root-Domain, Subdomains auf einer Ebene und die vom Dienst tatsächlich verwendeten tieferen Namen geprüft haben.
• Halten Sie DNS-Einträge, CDN-Hostnamen, Load-Balancer-Listener, Origin-Virtual-Hosts und Zertifikatszuweisungen aufeinander abgestimmt.
• Testen Sie nach DNS-Änderungen sowohl A- als auch AAAA-Pfade.
• Prüfen Sie das vom öffentlichen Endpunkt ausgelieferte Zertifikat, statt sich nur darauf zu verlassen, dass keine Browserwarnung erscheint.
• Dokumentieren Sie, welcher Dienst HTTPS beendet, damit Zertifikatsänderungen auf der richtigen Ebene vorgenommen werden.
• Sorgen Sie für Erneuerungs- und Bereitstellungsverfahren, die jeden erforderlichen Hostnamen einschließen.

Häufig gestellte Fragen