How to fix the server certificate does not include an id which matches the server name error

Der Fehler how to fix the server certificate does not include an id which matches the server name error ist fast immer ein Name-Mismatch zwischen der Domain, die du aufrufst, und dem Zertifikat, das der Server ausliefert. Das ist kein exotisches Problem. Das ist ein Standard-SSL-Problem, das ich in Minuten statt Stunden lösen will.

Wenn du das Problem einmal sauber verstehst, ist die Lösung meistens simpel: Hostname prüfen, Zertifikat prüfen, Konfiguration korrigieren, Zertifikat neu ausstellen. Ich gehe das Schritt für Schritt durch.

Was der Fehler eigentlich bedeutet

Ein TLS-Zertifikat ist nur gültig für bestimmte Namen. Das können die Common Name-Angabe oder, besser, die Subject Alternative Names sein. Wenn dein Browser oder Client z. B. api.example.com erwartet, das Zertifikat aber nur für example.com oder www.example.com ausgestellt wurde, kommt genau dieser Fehler.

Das heißt in klar: Der Server spricht mit dem falschen Namen. Oder das Zertifikat wurde für den falschen Namen erstellt. Oder beides.

Die häufigsten Ursachen

• Falscher Hostname im Request: Du rufst eine Subdomain auf, die nicht im Zertifikat steckt.
• Wildcard-Zertifikat falsch verstanden: *.example.com deckt nicht alles ab, was viele denken.
• Server block liefert das falsche Zertifikat: Besonders bei Nginx, Apache, Load Balancern oder Reverse Proxies.
• SAN fehlt: Das Zertifikat enthält die Domain nicht in den Subject Alternative Names.
• DNS zeigt auf den falschen Server: Du landest bei einem anderen System mit einem anderen Zertifikat.
• Interne Systeme mit selbstsignierten Zertifikaten: Häufig in Dev, Staging oder internen APIs.

So prüfe ich den Fehler schnell

Ich gehe immer in dieser Reihenfolge vor:

1. Hostname prüfen: Welchen Namen nutzt der Client wirklich?
2. Zertifikat ansehen: Für welche Namen ist es ausgestellt?
3. Server-Konfiguration prüfen: Welches Zertifikat wird ausgeliefert?
4. DNS prüfen: Zeigt die Domain auf die richtige IP?

1. Den aufgerufenen Hostname prüfen

Ich prüfe zuerst, ob der Client wirklich den Namen nutzt, den ich erwarte. Manchmal ist der Fehler banal: falsche Subdomain, Tippfehler, alter Eintrag in einer Config-Datei oder ein harter Code-String in der App.

Wenn du mit einer API arbeitest, check den Base URL in der Anwendung. Wenn du im Browser testest, check die Adresszeile. Wenn du über ein Skript oder ein Tool gehst, prüf die Ziel-URL exakt.

2. Das Zertifikat direkt anschauen

Ich will wissen, welche Namen im Zertifikat wirklich drinstehen. Dafür nutze ich je nach System z. B. OpenSSL. Ein typischer Check ist:

openssl s_client -connect example.com:443 -servername example.com

Danach schaue ich mir den Zertifikatsinhalt an und prüfe CN und SAN. Der wichtige Punkt ist fast immer der SAN-Bereich.

3. DNS prüfen

Wenn DNS auf die falsche Maschine zeigt, bringt das richtige Zertifikat auf dem richtigen Server nichts. Ich prüfe also, ob die Domain auf die erwartete IP zeigt. Das ist besonders wichtig, wenn du kürzlich umgezogen bist oder mehrere Umgebungen hast.

Wie ich den Fehler behebe

Die Lösung hängt von der Ursache ab. Aber in der Praxis sind das die effektivsten Schritte.

Wenn der Hostname falsch ist

Dann ändere ich die URL in der Anwendung, in der Konfiguration oder im Client. Das ist der schnellste Fix. Danach teste ich erneut.

Wenn das Zertifikat den Namen nicht enthält

Dann muss das Zertifikat neu ausgestellt werden. Ein nachträgliches "Reparieren" des bestehenden Zertifikats gibt es nicht. Das Zertifikat muss den richtigen Namen im SAN-Feld haben.

Wenn du Let’s Encrypt nutzt, kannst du dir die offiziellen Infos hier anschauen: Let’s Encrypt Docs.

Wenn der Server das falsche Zertifikat liefert

Das passiert oft bei mehreren Domains auf einem Server. Dann prüfe ich die Virtual Hosts, Server Blocks oder Listener-Regeln. Das Ziel ist einfach: Die richtige Domain muss das richtige Zertifikat bekommen.

• Bei Nginx: Server-Block, server_name, ssl_certificate, ssl_certificate_key prüfen.
• Bei Apache: VirtualHost, ServerName, Zertifikatpfade prüfen.
• Bei Load Balancern: TLS-Terminierung und Zertifikatszuordnung prüfen.
• Bei Kubernetes Ingress: Secret, Host-Regel und TLS-Setup prüfen.

Wenn du ein Wildcard-Zertifikat nutzt

Ein Wildcard-Zertifikat für *.example.com deckt in der Regel api.example.com oder shop.example.com ab. Es deckt aber nicht automatisch jede mögliche Kombination ab. Ich prüfe deshalb immer genau, ob die aufgerufene Subdomain wirklich enthalten ist.

Mehr zum Thema Zertifikate und TLS findest du bei Mozilla: Mozilla Server Side TLS.

Typische Spezialfälle

Ein paar Situationen sehe ich immer wieder:

Interne APIs und Staging-Umgebungen

Hier wird oft schnell ein Zertifikat gebaut, aber der eigentliche Hostname später geändert. Dann passt das Zertifikat nicht mehr. Mein Fix: Umgebung und Zertifikat immer zusammen denken.

Lokale Entwicklung

Wenn du lokal testest, brauchst du entweder ein lokales Dev-Zertifikat oder du akzeptierst bewusst ein Test-Setup. Für echte Security-Tests nutze ich saubere Zertifikate statt Workarounds.

Reverse Proxy hinter dem eigentlichen Webserver

Oft liefert nicht der Backend-Server das Zertifikat aus, sondern der Proxy. Dann suche ich die Konfiguration an der falschen Stelle. Der TLS-Endpunkt ist entscheidend, nicht nur der App-Server dahinter.

Was ich nicht empfehlen würde

• Zertifikatsprüfung global deaktivieren: Das ist kein Fix, das ist ein Risiko.
• Blind neue Zertifikate ausstellen: Erst prüfen, dann erneuern.
• Hostname-Fehler ignorieren: Der Fehler kommt nicht ohne Grund.

Wenn du Security ernst nimmst, behebst du die Ursache. Nicht die Meldung.

Meine schnelle Checkliste

• Nutze ich den richtigen Hostnamen?
• Steht die Domain im SAN des Zertifikats?
• Gibt der Server das richtige Zertifikat aus?
• Zeigt DNS auf die richtige IP?
• Ist der Load Balancer oder Proxy korrekt konfiguriert?
• Muss das Zertifikat neu ausgestellt werden?

Fazit

Der Fehler how to fix the server certificate does not include an id which matches the server name error ist meistens ein ganz normales Zuordnungsproblem: falscher Name, falsches Zertifikat oder falsche Serverkonfiguration. Ich löse ihn, indem ich zuerst den Hostnamen prüfe, dann das Zertifikat, dann den Server und zuletzt DNS. Das spart Zeit und verhindert unnötige Änderungen.

Wenn du sauber arbeitest, ist die Lösung klar: richtiger Name, richtiges Zertifikat, richtige Auslieferung. Genau so behebe ich den Fehler how to fix the server certificate does not include an id which matches the server name error.