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

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.

• Virtuelles Hosting: Mehrere Domains teilen sich eine IP und denselben Listener (z. B. TCP/443).
• Zertifikatsauswahl: Der TLS-Terminator wählt per SNI das korrekte Zertifikat (SAN/Wildcard/EV/OV etc.).
• Routing im Edge: Reverse Proxies und Ingress Controller nutzen SNI/Host-Header für Backend-Zuordnung.

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.

• Domain A: SNI stimmt → richtiges Zertifikat → richtiger vHost → Anwendung antwortet.
• Domain B: SNI fehlt/falsch → Default-Zertifikat → falscher vHost/Backend → TLS-Fehler oder falsche Website.

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.

• Browser-Fehler: Zertifikatswarnungen („Common Name/SAN passt nicht“), „SSL_ERROR_BAD_CERT_DOMAIN“, „NET::ERR_CERT_COMMON_NAME_INVALID“.
• Handshake-Abbruch: „Handshake failure“, „unrecognized_name“, „alert“ im TLS-Log; im Packet Capture ggf. TLS-Alert und anschließend FIN/RST.
• Falsche Website: Domain B liefert Content von Domain A (oder eine Default-Seite des Proxies).
• Nur bestimmte Clients betroffen: Alte Clients ohne SNI-Unterstützung oder spezielle TLS-Stacks scheitern, moderne Browser funktionieren.
• Monitoring-Verwirrung: IP-basierte Checks sind grün, domainbasierte Checks rot – oder umgekehrt, abhängig von Check-Implementierung.

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.

• Domainbasierter TLS-Check: Prüfen Sie Zertifikatkette und Host-Match (SAN/CN) für Domain A und Domain B getrennt.
• Vergleich der präsentierten Zertifikate: Wenn Domain B das Zertifikat von Domain A zeigt (oder ein Default-Zertifikat), ist das ein starkes Indiz.
• Packet Capture am Client oder am Edge: Suchen Sie im ClientHello nach dem SNI-Feld und vergleichen Sie mit der erwarteten Domain.
• Edge-Logs: Load Balancer/WAF/CDN protokollieren häufig SNI, ausgewähltes Zertifikat und vHost/Backend.
• DNS-Validierung: A/AAAA/CNAME prüfen, insbesondere ob Domain B wirklich auf die intendierte VIP/Edge zeigt.

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.

• TCP OK: SYN/SYN-ACK/ACK vorhanden, keine Drops.
• TLS scheitert früh: Alert, falsches Zertifikat oder Abbruch ohne HTTP.
• HTTP fehlt: In Logs/PCAP sieht man keinen gültigen HTTP-Request für Domain B.

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.

• Impact: Welche Clients/Standorte/Services waren betroffen? Welche Domain(s) genau?
• Symptomnachweis: Welches Zertifikat wurde für Domain B präsentiert? Welche Fehlermeldung trat auf?
• Beobachtungspunkt: Wo wurde gemessen (Client, Edge, LB, CDN)?
• Konfiguration: Welche SNI-/vHost-Regel fehlte oder kollidierte? Welche Default-Regel griff stattdessen?
• Trigger: Change, Zertifikatsrotation, Ingress-Rollout, DNS-Änderung, Proxy-Policy.
• Fix: Welche konkrete Regel/Zertifikat wurde ergänzt oder korrigiert?

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.

• Symptom: Domain B zeigt falschen Content, Zertifikat kann trotzdem „passen“ (weil SAN/Wildcard).
• Hinweis: Backend-Logs zeigen Requests für Host B auf Service A.

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.

• HTTPS-Check mit Hostname: Zertifikatsvalidierung (SAN/CN), SNI korrekt, ggf. HTTP-Status und Response-Time.
• Zertifikatsmonitoring: Ablaufdatum, SAN-Abdeckung, Deploy-Status auf allen Termination-Points.
• Canary-Clients: Tests aus repräsentativen Netzen (mit/ohne Proxy, verschiedene Standorte).
• Fehlerklassifizierung: Handshake-Fehler vs. HTTP-Fehler getrennt zählen, um L4/L6/L7 sauber zu trennen.

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:

$\mathrm{SNI\_Failure\_Rate}=\frac{\mathrm{Handshake\_Failures\_with\_SNI}}{\mathrm{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.

• Edge/LB: SNI-Regel ergänzen: Korrektes Zertifikat und vHost/Backend-Mapping für Domain B hinzufügen.
• Default vHost entschärfen: Default sollte keine „falsche“ Website liefern, sondern klar und sicher failen (z. B. 421/404 oder Wartungsseite), um Fehlrouting zu entlarven.
• DNS sauberziehen: Wenn Domain B auf eine VIP zeigt, die Domain B nicht kennt, DNS korrigieren oder Provisionierung nachziehen.
• Proxy/Inspection prüfen: Temporäre Bypass-Regel für Domain B, wenn die Ursache eindeutig in einer Middlebox liegt (mit klarer Change- und Rückbauplanung).
• Legacy-Clients adressieren: Wenn Clients ohne SNI unterstützt werden müssen, kann ein dedizierter Endpoint (eigene IP/Listener) nötig sein.

Prävention: So vermeiden Sie SNI-Issues langfristig

• Inventory der Termination-Points: Dokumentieren, ob TLS am CDN, WAF, LB oder Ingress endet – und wo SNI gematcht wird.
• Automatisierte Domain-Provisionierung: Domain-Onboarding als Pipeline: DNS, Zertifikat, SNI/vHost-Regel, Backend-Routing, Monitoring.
• Preflight-Checks bei Changes: Vor jedem LB/Ingress-Change hostbasierte Handshake-Checks für alle kritischen Domains.
• Regelprioritäten testen: Wildcards und spezifische Host-Regeln mit Unit-Tests oder Validierungsregeln absichern.
• Zertifikatsabdeckung überwachen: SAN-Liste gegen tatsächliche Domainliste abgleichen, inklusive Subdomains und CNAME-Ketten.

Outbound-Links für vertiefende technische Referenzen

• TLS Extensions (SNI) nach RFC 6066 für die formale Definition von SNI und das Verhalten im Handshake.
• TLS 1.3 Spezifikation (RFC 8446) für Handshake-Abläufe und relevante Parameter bei modernen Clients.
• HTTP Host-Header bei MDN zur Abgrenzung zwischen TLS-SNI und HTTP-Routing.
• Nginx: HTTPS und SNI-Konfiguration als praxisnahes Beispiel für vHost- und Zertifikatszuordnung.
• Apache mod_ssl Dokumentation für SNI- und Zertifikatsauswahl in klassischen Webserver-Setups.

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:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

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.