Das Zertifikat ist echt und gültig, wurde aber für andere Namen ausgestellt als den in Ihrer Adressleiste. So entsteht ERR_CERT_COMMON_NAME_INVALID, und so beheben Besucher und Website-Betreiber den Fehler.

ERR_CERT_COMMON_NAME_INVALID: Was der Fehler bedeutet und wie Sie ihn beheben

ERR_CERT_COMMON_NAME_INVALID bedeutet: Die Website hat ein echtes, nicht abgelaufenes Zertifikat vorgezeigt, aber dieses Zertifikat wurde für einen anderen Namen ausgestellt als den in Ihrer Adressleiste. Chrome vergleicht die angeforderte Domain mit den Hostnamen im Feld Subject Alternative Name (SAN) des Zertifikats. Passt keiner davon, blockiert Chrome die Seite mit diesem Fehler. Die Lösung hängt davon ab, wer Sie sind: Als Besucher können Sie die Lage meist in Minuten klären, als Website-Betreiber müssen Sie ein Zertifikat neu ausstellen oder umkonfigurieren. Dieser Leitfaden behandelt beides, mit Daten dazu, wie häufig jede Ursache wirklich ist.

Was der Fehler wirklich bedeutet

Jedes öffentliche HTTPS-Zertifikat enthält eine Liste von Hostnamen, für die es gilt, gespeichert in der SAN-Erweiterung. Historisch akzeptierten Browser auch das Common-Name-Feld (CN) des Zertifikats, daher der Name des Fehlers. Dieser Rückfallmechanismus ist längst Geschichte:

RFC 2818 riet bereits im Jahr 2000 vom CN-Abgleich für HTTPS ab.
Chrome 58 entfernte den CN-Abgleich im April 2017 vollständig und verlangt seitdem SAN-Einträge (Quelle: Chrome for Developers, "Deprecations and Removals in Chrome 58"). Damals stützten sich nur noch rund 0,1 % aller Zertifikatsprüfungen auf den CN-Rückfall (Chromium security-dev, 2017).
RFC 9525 (November 2023), der Nachfolger von RFC 6125, machte es branchenweit verbindlich: Clients dürfen nur die SAN-Erweiterung prüfen und Domainnamen nicht mehr gegen den CN abgleichen.

Trotz seines Namens bedeutet der Fehler also eigentlich "SAN-Mismatch": Nichts in der Namensliste des Zertifikats deckt den angeforderten Host ab.

Der Fehler ist zudem bemerkenswert häufig. In Googles Auswertung von über 300 Millionen echten Chrome-Zertifikatswarnungen (Acer et al., "Where the Wild Warnings Are", ACM CCS 2017) war der Namens-Mismatch die größte serverseitige Einzelursache auf dem Desktop: 11,7 % aller Warnmeldungen unter Windows und 11,6 % auf dem Mac, vor nicht vertrauenswürdigen Zertifizierungsstellen und abgelaufenen Zertifikaten.

Balkendiagramm der serverseitigen Ursachen von Chrome-Zertifikatswarnungen unter Windows: Namens-Mismatch 11,7 Prozent, nicht vertrauenswürdige CA 6,11 Prozent, abgelaufen oder falsches Datum 4,23 Prozent, fehlende Zwischenzertifikate 1,26 Prozent

Serverseitige Ursachen von Chrome-Zertifikatswarnungen als Anteil aller Warnmeldungen unter Windows. Daten: Acer et al., "Where the Wild Warnings Are", ACM CCS 2017.

Die 7 häufigen Ursachen, und wer sie behebt

#	Ursache	Was passiert	Wer behebt es
1	www-Mismatch	Das Zertifikat deckt `www.example.com` ab, aber nicht `example.com`, oder umgekehrt	Betreiber
2	Subdomain außerhalb des Wildcard-Bereichs	`*.example.com` deckt `app.eu.example.com` nicht ab	Betreiber
3	Falsches oder Standard-Zertifikat	Shared Hosting oder ein falsch konfigurierter Server (SNI) antwortet mit dem Zertifikat einer anderen Website	Betreiber
4	Veraltetes DNS oder umgezogene Domain	Die Domain zeigt noch auf einen Server, der sie nicht mehr hostet, also antwortet ein fremdes Zertifikat	Betreiber
5	Nur-CN-Zertifikat	Ein altes oder internes Zertifikat hat den richtigen CN, aber keine SAN-Einträge; Chrome lehnt diese seit Version 58 (April 2017) ab	Betreiber / IT
6	Captive Portal	Hotel- oder Flughafen-WLAN fängt Ihre erste Anfrage ab, um die Anmeldeseite zu zeigen	Besucher
7	HTTPS-Inspektion	Antivirus oder ein Firmen-Proxy signiert den Verkehr mit eigenem Zertifikat neu	Besucher / IT

Innerhalb der Namens-Mismatches stechen Subdomain-Fehler hervor. Im selben Google-Datensatz waren 13,2 % der serverseitigen Namensfehler Anfragen an Subdomains außerhalb des Wildcard-Bereichs, und 3,7 % waren reine www-Mismatches (Acer et al., CCS 2017). Weitere 3,8 % der Namensfehler passten zu bekannten Captive-Portal-Mustern, wurden also vom Netzwerk verursacht, nicht von der Website.

Als Besucher: 5 schnelle Checks

Probieren Sie die andere Form der Adresse. Wenn example.com scheitert, versuchen Sie www.example.com, oder umgekehrt. Funktioniert eine davon, hat die Website einen www-Mismatch, und Sie können das dem Betreiber exakt so melden.
Prüfen Sie, auf wen das Zertifikat ausgestellt ist. Klicken Sie auf das Schloss oder "Nicht sicher", öffnen Sie die Zertifikatsdetails und lesen Sie die SAN-Liste. Ein Zertifikat für die Platzhalter-Domain eines Hosters oder eine völlig fremde Website erklärt die Blockade sofort.
In öffentlichem WLAN: zuerst die Anmeldeseite auslösen. Captive Portals fangen die erste HTTPS-Anfrage ab und antworten mit ihrem eigenen Zertifikat. Öffnen Sie eine reine HTTP-Seite (etwa die Statusseite eines Routers oder neverssl.com), schließen Sie die Portal-Anmeldung ab und versuchen Sie es erneut.
Testen Sie mit deaktivierter HTTPS-Prüfung. Manche Antivirus-Suiten und Firmen-Proxys signieren TLS-Verkehr neu. Deaktivieren Sie das HTTPS-Scanning vorübergehend oder wechseln Sie das Netzwerk; verschwindet der Fehler, ist die Inspektionssoftware die Ursache.
Klicken Sie sich auf wichtigen Seiten nicht durch. Bei Banking, E-Mail oder allem mit Login gilt ein Namens-Mismatch als hartes Stopp-Signal. Die allgemeine Variante dieser Warnung behandeln wir im Leitfaden zum Fehler "Ihre Verbindung ist nicht privat".

Als Betreiber: erst diagnostizieren, dann beheben

Laptop-Bildschirm mit Monitoring-Diagrammen und Website-Statistiken

Lesen Sie zuerst aus, welche Namen Ihr Zertifikat tatsächlich abdeckt. Von jedem Terminal mit installiertem OpenSSL:

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

Führen Sie den Befehl zweimal aus, einmal mit der Apex-Domain und einmal mit www, und vergleichen Sie die SAN-Ausgabe mit jedem Hostnamen, den Ihre Nutzer tatsächlich aufrufen. Beheben Sie dann die gefundene Ursache:

Apex und www gemeinsam abdecken. Stellen Sie ein Zertifikat aus, das beide Namen auflistet. Let's Encrypt erlaubt bis zu 100 Hostnamen pro Zertifikat kostenlos (Let's-Encrypt-Dokumentation zu Limits), und jede kommerzielle CA verkauft Multi-Domain-Zertifikate (SAN).
Wildcard-Reichweite beachten. Ein Wildcard deckt genau eine Ebene ab, gemäß RFC 9525:

Angeforderter Name	Von `*.example.com` abgedeckt?
`app.example.com`	Ja
`example.com`	Nein, die Apex-Domain braucht einen eigenen SAN-Eintrag
`eu.app.example.com`	Nein, Wildcards decken nur eine Ebene ab
`app.example.net`	Nein, andere Domain

SNI und Default-Vhost korrigieren. Hostet Ihr Server mehrere Websites, verknüpfen Sie jeden Hostnamen mit dem eigenen Zertifikat und stellen Sie sicher, dass der Default-Vhost nicht mit dem falschen Zertifikat antwortet, wenn Clients oder Bots SNI weglassen.
Beide Enden des CDN prüfen. Mit CDN oder Reverse Proxy davor muss das Edge-Zertifikat Ihren öffentlichen Hostnamen abdecken und das Origin-Zertifikat den Hostnamen, zu dem das CDN verbindet. Ein Mismatch auf einer der beiden Strecken löst Fehler aus.
Nicht auf Weiterleitungen verlassen. TLS wird ausgehandelt, bevor eine HTTP-Weiterleitung gesendet wird. Auch wenn example.com sofort auf www.example.com weiterleitet, muss das auf example.com ausgelieferte Zertifikat diesen Namen weiterhin abdecken.

Ein Grund mehr zu automatisieren: Mit dem CA/Browser-Forum-Beschluss SC-081v3 (angenommen im April 2025) sank die maximale Laufzeit öffentlicher Zertifikate am 15. März 2026 von 398 auf 200 Tage, fällt im März 2027 auf 100 Tage und erreicht im März 2029 47 Tage. Erneuerungen werden deutlich häufiger, und jede Erneuerung ist eine neue Gelegenheit, bei der eine SAN-Liste still einen Namen verliert. Setzen Sie auf ACME-Automatisierung und überwachen Sie die Abdeckung, statt sich auf das Gedächtnis zu verlassen.

Häufige Fragen

Ist es sicher, auf "Trotzdem fortfahren" zu klicken? Nur wenn Sie sicher wissen, warum der Mismatch besteht, etwa bei Ihrem eigenen Testserver, der per IP-Adresse erreicht wird. Auf Seiten, auf denen Sie Passwörter oder Zahlungsdaten eingeben würden: nicht fortfahren.

Bedeutet der Fehler, dass die Website gehackt wurde? Fast nie. Meist steckt ein Konfigurationsfehler dahinter: eine umbenannte Domain, ein vergessener www-Eintrag oder ein Wildcard, das nicht so weit reicht, wie der Betreiber dachte. Angriffe kommen vor, und genau deshalb weigern sich Browser zu raten.

Warum heißt es "Common Name", wenn Browser das CN-Feld ignorieren? Der Name ist historisch. Browser glichen das CN-Feld ab, bis RFC 2818 (2000) davon abriet und Chrome 58 (April 2017) es entfernte. Heute zählt nur die SAN-Liste, gemäß RFC 9525 (November 2023), aber die Fehlerkennung wurde nie umbenannt.

Brauche ich für jede Subdomain ein eigenes Zertifikat? Nein. Ein Zertifikat kann viele SAN-Einträge auflisten, und ein Wildcard deckt alle direkten Subdomains einer Ebene ab. Zusätzliche Planung brauchen nur tiefere Ebenen wie a.b.example.com, die ein einstufiges Wildcard nicht abdeckt.

Prüfen Sie Ihre Zertifikatsabdeckung in 60 Sekunden

Ein Namens-Mismatch bleibt unsichtbar, bis jemand genau den Hostnamen aufruft, den Sie vergessen haben. Der kostenlose FortifyNet-Scan liest Ihr aktives Zertifikat aus und meldet, welche Namen es abdeckt, zusammen mit TLS-Konfiguration, Security-Headern, DNS, E-Mail-Authentifizierung und Dark-Web-Exposition. Starten Sie den Gratis-Scan für Ihre Domain und prüfen Sie Apex, www und Subdomains in einem Durchgang.