Site icon bintorosoft.com

SNI-Issue: Warum Domain A geht, Domain B aber nicht – bei derselben IP

Red Snapper

Cloud storage banner background, remixed from public domain by Nasa

Ein SNI-Issue ist eine der häufigsten Ursachen für das irritierende Fehlerbild: „Domain A geht, Domain B aber nicht – bei derselben IP“. Für ein NOC wirkt das zunächst wie ein klassischer Netzwerk-Incident: Die IP ist erreichbar, Ping funktioniert, TCP/443 baut sich auf – und trotzdem liefert nur eine der beiden Domains eine korrekte Website, während die andere mit TLS-Fehlern, Browser-Warnungen, „Connection reset“ oder 4xx/5xx antwortet. Der Schlüssel liegt in der Art, wie moderne HTTPS-Setups mehrere Hostnames auf einer einzigen IP-Adresse betreiben. Seit Jahren ist das Standard, weil IPv4-Adressen knapp sind, CDNs und Load Balancer zentral terminieren und virtuelle Hosts skalieren. Damit der Server aber weiß, welches Zertifikat und welches Backend er verwenden soll, muss der Client den gewünschten Hostnamen früh im TLS-Handshake mitteilen. Genau dafür gibt es SNI (Server Name Indication). Wenn SNI fehlt, falsch ist oder unterwegs verändert wird, kann derselbe Server mit derselben IP für unterschiedliche Domains komplett unterschiedliche Ergebnisse liefern. Dieser Artikel erklärt praxisnah, warum das passiert, welche Symptome typisch sind, wie Sie SNI-Probleme sicher diagnostizieren und wie eine saubere RCA aussieht – ohne Rätselraten und ohne unnötige Eskalationsschleifen zwischen Netzwerk-, Plattform- und App-Teams.

Was ist SNI und warum ist es heute praktisch unverzichtbar?

SNI (Server Name Indication) ist eine TLS-Erweiterung, mit der der Client bereits im ClientHello den gewünschten Hostnamen übermittelt. Der Server (oder ein TLS-terminierendes Gerät wie Load Balancer, WAF oder CDN) kann damit das passende Zertifikat auswählen und den Traffic in den richtigen virtuellen Kontext routen. Ohne SNI wäre für jede HTTPS-Domain mit eigenem Zertifikat häufig eine eigene IP nötig – ein Ansatz, der im Zeitalter großer Plattformen und Shared-Infrastructure kaum praktikabel ist.

Warum Domain A geht, Domain B aber nicht – obwohl die IP identisch ist

Das scheinbare Paradox löst sich auf, wenn man den Ablauf trennt: Die IP-Adresse entscheidet nur, wohin das Paket geht. SNI entscheidet, welcher virtuelle Dienst auf diesem Endpunkt gemeint ist. Wenn Domain A korrekt per SNI signalisiert wird, aber Domain B nicht, oder wenn Domain B auf einen falschen vHost zeigt, entstehen unterschiedliche Ergebnisse bei identischer IP.

Typische Symptome eines SNI-Issues im NOC

SNI-Probleme erzeugen Muster, die häufig als Netzwerkstörung fehlinterpretiert werden. Besonders tückisch: Der TCP-Connect klappt, es gibt also „Connectivity“. Das Scheitern passiert oberhalb von L4, aber noch vor HTTP.

Die häufigsten Root-Cause-Kategorien bei SNI-Problemen

Default-Zertifikat statt Domain-Zertifikat

Wenn der TLS-Terminator kein SNI erhält oder es nicht matcht, liefert er häufig das Default-Zertifikat. Für Domain A kann das korrekt sein, für Domain B aber nicht. Im Browser wirkt das wie „Zertifikat falsch“ – im NOC oft wie „TLS kaputt“.

Falsches SNI-Routing im Load Balancer oder Ingress

In vielen Plattformen gibt es Mapping-Regeln „SNI → Zertifikat/Backend“. Ein Tippfehler, eine fehlende Regel oder eine Prioritätskollision kann dazu führen, dass Domain B am falschen Backend landet. Besonders häufig ist das in Umgebungen mit vielen Wildcards oder überlappenden Host-Regeln.

DNS und SNI passen nicht zusammen

Ein Klassiker: Domain B zeigt per DNS auf dieselbe IP wie Domain A, aber der TLS-Terminator kennt Domain B nicht (kein Zertifikat, kein vHost). DNS löst also „korrekt“, aber der Dienst ist nicht vollständig provisioniert.

Proxy- oder TLS-Inspection verändert den Host-Kontext

In Unternehmensnetzen können Proxy-Ketten oder TLS-Inspection SNI/Handshake-Verhalten beeinflussen. Wenn ein Proxy SNI nicht korrekt weitergibt oder bei bestimmten Domains anders routet, entsteht das Muster „geht intern nicht, extern schon“ oder „geht bei manchen Standorten nicht“.

Client ohne SNI-Unterstützung

Legacy-Clients (ältere Betriebssysteme, Embedded-Devices, alte Java-Versionen) senden möglicherweise kein SNI. Wenn Domain B auf SNI angewiesen ist und Domain A zufällig das Default-Zertifikat nutzt, wirkt es so, als sei nur Domain B „kaputt“.

HTTP/Host-Header vs. SNI: Zwei Namen, zwei Entscheidungen

Wichtig: SNI steuert TLS-Zertifikat und oft das erste Routing. Der HTTP-Host-Header steuert danach das L7-Routing. In Proxy-Setups kann es passieren, dass TLS korrekt ist (SNI passt), aber HTTP auf einen anderen Host zeigt (Host-Header falsch). Das Ergebnis kann „200 OK, aber falscher Content“ sein – und das ist genauso kritisch.

Operative Diagnose: So beweisen Sie ein SNI-Problem in Minuten

Ein zuverlässiger NOC-Workflow sollte SNI explizit prüfen, statt nur „IP erreichbar“ zu testen. Entscheidend ist, dass Sie Domain A und Domain B mit korrekter Host-Angabe testen und das Zertifikat/Backend eindeutig zuordnen.

Wie SNI-Issues „wie Netzwerk“ aussehen: Die Illusion der funktionierenden IP

Viele NOC-Runbooks beginnen bei Erreichbarkeit: Ping, Traceroute, TCP Connect. Das ist sinnvoll, aber bei SNI-Problemen führt es zu einem falschen Sicherheitsgefühl. Der TCP-Handshake kann vollständig erfolgreich sein, weil die IP stimmt und Port 443 offen ist. Trotzdem scheitert der Dienst, weil die virtuelle Zuordnung nicht stimmt.

RCA-Struktur: Was in die Ursachenanalyse gehört

Eine gute RCA zu einem SNI-Issue sollte die Ursache nicht nur benennen, sondern nachvollziehbar belegen. Das reduziert Wiederholungen und macht Prävention möglich.

Häufige Fehlkonfigurationen im Detail

Wildcard-Overlaps und Prioritätsprobleme

Wildcards sind praktisch, aber gefährlich, wenn Regeln überlappen. Wenn „*.example.com“ vor „api.example.com“ matcht und ein anderes Backend/Zertifikat auswählt, kann eine spezifische Domain plötzlich falsch geroutet werden.

Zertifikatsrotation ohne vollständige Provisionierung

Automatisierte Zertifikatsprozesse erneuern Zertifikate zuverlässig – solange alle Domains korrekt im Zertifikats- und Deployment-Workflow enthalten sind. Fehlt Domain B in der SAN-Liste oder in der Deploy-Target-Liste, bleibt der alte Zustand bestehen oder fällt auf Default zurück.

Falsche Listener-Bindings (VIP/Port/Hostname)

Bei mehreren VIPs oder mehreren Listenern kann Domain B versehentlich auf den falschen Listener zeigen (oder umgekehrt). Das wird besonders unübersichtlich, wenn DNS-CNAMEs auf gemeinsame Edge-Hostnames zeigen.

Monitoring richtig aufsetzen: Warum IP-Checks nicht reichen

Wenn Ihre Uptime-Checks nur die IP prüfen, übersehen Sie SNI-Probleme fast zwangsläufig. Besser ist ein Monitoring, das explizit die Domain im TLS-Handshake und im HTTP-Host-Header setzt.

Messbare SNI-Failure-Rate definieren (MathML)

Damit SNI-Issues nicht erst durch Nutzer auffallen, kann eine Kennzahl helfen, die „SNI-abhängige Handshake-Fehler“ sichtbar macht. Eine einfache Rate ist:

SNI_Failure_Rate = Handshake_Failures_with_SNI Handshake_Attempts_with_SNI

Wichtig ist die Segmentierung nach Hostname: Eine Gesamtrate kann „gut“ aussehen, während Domain B eine hohe Failure Rate hat. Für das NOC ist daher eine hostbasierte Auswertung entscheidend.

Mitigation in Produktion: Was schnell hilft und was nachhaltig ist

Wenn Domain B ausfällt, muss die Wiederherstellung zügig erfolgen, ohne neue Risiken zu erzeugen. Die Maßnahmen hängen stark davon ab, wo TLS terminiert.

Prävention: So vermeiden Sie SNI-Issues langfristig

Outbound-Links für vertiefende technische Referenzen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Lieferumfang:

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.

 

Exit mobile version