TLS-Fehler "no alternative certificate subject name" beheben

Bei TLS-Fehlern rund um Hostnamen liegt das Problem meist nicht bei der Verschlüsselung selbst, sondern bei der Identität des Servers. Die Meldung no alternative certificate subject name matches target host name bedeutet in der Praxis: Der aufgerufene Name passt nicht zu den Namen im Zertifikat. Ich zeige hier, wie du den Fehler sauber einordnest, mit welchen Prüfungen du die Ursache findest und wie du ihn dauerhaft beseitigst.

Was die Meldung technisch wirklich sagt

Ich lese diesen Fehler immer als Identitätsproblem, nicht als allgemeines SSL-Problem. Der TLS-Client vergleicht den Namen, den du aufrufst, mit den Identifikatoren im Zertifikat. Fehlt dort der passende DNS-Name oder die passende IP-Adresse, bricht die Prüfung ab, auch wenn das Zertifikat sonst gültig, signiert und nicht abgelaufen ist.

In modernen TLS-Setups ist die subjectAltName-Extension maßgeblich. Dort stehen die erlaubten Namen als dNSName oder iPAddress. Der Common Name im Subject ist historisch wichtig gewesen, ist heute aber keine verlässliche Basis mehr. Einige Bibliotheken akzeptieren ihn noch als Fallback, darauf sollte man sich in produktiven Umgebungen nicht verlassen.

Das erklärt auch, warum derselbe Server in einem Fall funktioniert und im nächsten scheitert: Nicht die Verschlüsselung wechselt, sondern der angefragte Hostname. Wer `example.de` aufruft, braucht ein Zertifikat für genau diesen Namen oder einen explizit abgedeckten Alias, etwa `www.example.de`. Wer direkt per IP geht, braucht dagegen eine Zertifikatsidentität für diese IP oder muss wieder über den DNS-Namen arbeiten.

Aus meiner Sicht ist das die wichtigste Denkregel bei diesem Fehler: Der Client prüft nicht nur, ob ein Zertifikat existiert, sondern ob es für genau diesen Zielnamen gedacht ist. Das führt direkt zur Frage, warum Server in der Praxis trotzdem oft das falsche Zertifikat ausliefern.

Warum derselbe Server plötzlich das falsche Zertifikat liefert

Sehr oft ist der Server technisch erreichbar, aber der falsche virtuelle Host antwortet auf die TLS-Anfrage. Das passiert besonders bei Shared Hosting, Reverse Proxies, Load Balancern und CDNs. Wenn dort SNI nicht korrekt übergeben wird oder das Default-Zertifikat greift, landet der Client bei einem Zertifikat, das zu einem anderen Namen gehört.

Ein weiterer Klassiker sind Namenskonflikte zwischen internen und externen Hosts. Intern heißt der Dienst vielleicht `app.local`, extern aber `app.firma.de`. Wenn das Zertifikat nur einen dieser Namen enthält, scheitert die Prüfung auf der jeweils anderen Seite. Dasselbe gilt für Umgebungen, in denen ein Shortname wie `mail01` verwendet wird, der im Zertifikat nie vorgesehen war.

Genau an dieser Stelle trennt sich saubere Infrastruktur von improvisierter Konfiguration. Ein Zertifikat kann korrekt sein und trotzdem am falschen Ort ausgeliefert werden. Deshalb lohnt sich der Blick auf die nächste Ebene: die Diagnose.

So finde ich die Abweichung in der Praxis

Wenn ich einen Namensfehler untersuche, gehe ich immer in derselben Reihenfolge vor: erst den aufgerufenen Namen bestätigen, dann das tatsächlich gelieferte Zertifikat ansehen, danach die SANs prüfen. Diese Reihenfolge spart Zeit, weil sie DNS-, Proxy- und Zertifikatsfehler sauber voneinander trennt.

1. Prüfe die exakte Ziel-URL, inklusive Subdomain, Port und möglicher Weiterleitungen.
2. Rufe den Dienst mit ausführlicher Ausgabe auf, zum Beispiel mit `curl -v https://beispiel.de/`.
3. Schau dir an, welches Zertifikat der Server wirklich sendet, etwa mit `openssl s_client -connect beispiel.de:443 -servername beispiel.de -showcerts`.
4. Inspektiere anschließend das Zertifikat selbst und suche nach `subjectAltName`.
5. Vergleiche den Namen aus der URL mit allen SAN-Einträgen und prüfe, ob ein Alias oder eine IP im Spiel ist.

curl -v https://beispiel.de/
openssl s_client -connect beispiel.de:443 -servername beispiel.de -showcerts
openssl x509 -noout -text -in cert.pem

Der zweite Befehl ist besonders wichtig, weil er SNI explizit setzt. Ohne SNI kann auf Mehrmandanten-Servern das falsche Zertifikat zurückkommen, obwohl der Zielhost eigentlich korrekt ist. Für Tests ist auch `curl --resolve www.example.de:443:192.0.2.10 https://www.example.de/` hilfreich, weil der Hostname in der URL gleich bleibt, aber die Verbindung auf eine andere IP zeigt.

Wenn der Fehler nur bei `curl` auftaucht, im Browser aber nicht, ist das ebenfalls ein Hinweis. Dann lohnt sich ein Blick darauf, ob Browser und Client denselben Hostnamen benutzen, ob eine Weiterleitung auf eine andere Domain passiert oder ob der Server im Hintergrund ein anderes Zertifikat ausliefert.

So behebe ich den Fehler dauerhaft

Die verlässlichste Lösung ist fast immer: Zertifikat neu ausstellen, damit alle tatsächlich genutzten Namen im SAN stehen. Das betrifft nicht nur den offensichtlichen Hauptnamen, sondern auch die Namen, über die der Dienst real erreichbar ist. Bei Webanwendungen sind das oft `example.de`, `www.example.de`, ein API-Host und gegebenenfalls ein Verwaltungsname.

Ich würde die Behebung immer in dieser Reihenfolge angehen:

• Den kanonischen Hostnamen festlegen, den Benutzer und Systeme künftig verwenden sollen.
• Alle produktiven Alias-Namen sammeln, die in SAN aufgenommen werden müssen.
• Das Zertifikat mit diesen Namen neu ausstellen oder neu beantragen.
• Webserver, Proxy oder Load Balancer so konfigurieren, dass genau dieses Zertifikat für genau diesen Host ausgeliefert wird.
• Nach dem Rollout erneut mit `curl` und `openssl s_client` testen.

Bei Wildcard-Zertifikaten ist die Grenze klar: `*.example.de` deckt nur eine Ebene ab, also etwa `shop.example.de`, nicht aber `a.b.example.de` und auch nicht die Apex-Domain `example.de`. Das ist kein Fehler des Zertifikats, sondern eine Eigenschaft der Namensregel. Wer diese Grenze kennt, vermeidet viele unnötige Supportschleifen.

Für interne Systeme gilt derselbe Grundsatz. Wenn ein Dienst nur per internem DNS-Namen erreichbar ist, muss genau dieser Name im Zertifikat stehen oder durch die interne PKI abgedeckt werden. Ein öffentliches Zertifikat für einen privaten Shortname ist meist keine gute Idee, weil externe Clients den Namen ohnehin nicht auflösen oder nicht als vertrauenswürdig behandeln können.

Welche Abkürzungen ich nur zum Testen akzeptiere

Es gibt ein paar schnelle Wege, die den Fehler kurzfristig verschwinden lassen. Ich setze sie nur in Laboren, bei einmaligen Migrationsschritten oder für die Fehlersuche ein. Dauerhaft sind sie zu teuer, weil sie die eigentliche Ursache verdecken.

Wenn ein Team diese Abkürzungen zu lange mitträgt, entsteht fast immer technischer Schuldenstand: Die Umgebung wirkt stabil, bis ein neues Tool, eine andere Bibliothek oder ein strengerer Client die alte Unsicherheit sichtbar macht. Ich halte es deshalb für besser, die Ursache zügig zu beheben, statt den Fehler zu verstecken.

Was ich für neue TLS-Setups von Anfang an einplane

Bei neuen Umgebungen plane ich TLS nicht erst am Ende ein, sondern parallel zur Namensstrategie. Das spart später die meisten Konflikte. Die Frage ist nicht nur, welches Zertifikat bestellt wird, sondern auch, welche Namen langfristig stabil bleiben sollen.

Mein pragmatischer Standard sieht so aus: ein kanonischer Name pro Dienst, alle produktiven Alias-Namen im SAN, klare Trennung zwischen intern und extern, und ein Testlauf vor dem Go-live. Dazu kommt eine einfache Regel für Betrieb und Automatisierung: Wenn ein neuer Hostname eingeführt wird, wird er gleichzeitig in DNS, Reverse Proxy und Zertifikatsprozess eingetragen.

So bleibt der Fehler gar nicht erst stehen. Und genau das ist die bessere Antwort auf einen Namenskonflikt im TLS-Handshake: nicht nur das Zertifikat wechseln, sondern die gesamte Namenskette von URL über Proxy bis zur Auslieferung konsistent machen. Dann verschwindet der Fehler nicht nur auf dem Papier, sondern auch im Betrieb.