Das Symptom
Die Seite läuft. Zwei Wochen später meldet ein einzelnes Gerät, ein Skript oder ein alter Kartenleser, das Zertifikat gehöre zu einem anderen Namen – und zwar zu einem, den man noch nie gesehen hat. Oft ist es der Name des Hosters, manchmal der einer völlig fremden Kundendomain auf demselben Server. Alle anderen Geräte im Haus zeigen dieselbe Seite anstandslos an.
Der Reflex ist, das Zertifikat neu auszustellen. Danach ist der Fehler unverändert, nur das Ausstellungsdatum ist neuer.
Die „Layer 8“-Wahrheit
Das Zertifikat ist nicht falsch. Es ist nur nicht das, das gemeint war. TLS hat eine Reihenfolgen-Eigenart, die man einmal verstanden haben muss: Der Server schickt sein Zertifikat, bevor der Client ihm mitgeteilt hat, mit welchem Namen er ihn eigentlich meint. Der HTTP-Host-Header, der genau diese Information trüge, kommt erst in der verschlüsselten Anfrage – also zu spät. RFC 6066 Abschnitt 3 beginnt deshalb mit der ehrlichsten Feststellung des ganzen Dokuments: TLS bietet keinen Mechanismus, mit dem ein Client dem Server den Namen des Servers mitteilen kann, den er kontaktiert. Server Name Indication ist die nachgereichte Antwort darauf, und ihr erklärter Zweck ist genau der Massenbetrieb: sichere Verbindungen zu Servern, die mehrere virtuelle Server unter einer einzigen Netzwerkadresse beherbergen.
Fehlt die Erweiterung, muss der Server raten, und er rät nach Konfiguration: Standard-Host, erster virtueller Host, irgendetwas. RFC 6066 Abschnitt 3 räumt ihm für den Fall eines unbekannten Namens ausdrücklich zwei Wege ein – Abbruch mit einem unrecognized_name(112) auf Fatal-Ebene oder Fortsetzen des Handshakes; ein Alert auf Warning-Ebene ist NOT RECOMMENDED, weil das Clientverhalten darauf unvorhersehbar ist. In der Praxis setzen die meisten Server fort. Deshalb scheitert die Verbindung nicht dort, wo die Ursache liegt, sondern erst eine Stufe später. Derselbe Abschnitt beschreibt das präzise: Weicht der von der Anwendung verwendete Servername vom Namen der gewählten Anmeldeinformation ab, wird das erst bei der Endpunkt-Identifizierung durch die Client-Anwendung sichtbar. Der Handshake war sauber. Der Name war es nicht.
Zwei Fallen bleiben. Die erste heißt IP-Adresse: RFC 6066 Abschnitt 3 verbietet literale IPv4- und IPv6-Adressen im Feld HostName. Wer zum Testen per IP verbindet, sendet also standardkonform überhaupt keinen Namen und provoziert genau den Fehler, den er untersuchen will – ein Diagnoseartefakt, das für einen echten Serverfehler gehalten wird. Die zweite heißt OpenSSL: Seit Version 1.1.1 füllt s_client die SNI von sich aus mit dem an -connect übergebenen Namen, sofern dieser wie ein DNS-Name aussieht, und ohne -connect mit „localhost“. Wer den SNI-losen Fall nachstellen will, muss das mit -noservername ausdrücklich erzwingen. Und wenn eine Sitzung, die eben noch lief, beim Wiederaufnehmen plötzlich einen vollständigen Handshake macht: Ein Server, der die Erweiterung implementiert, darf eine Sitzung nicht wiederaufnehmen, wenn die server_name-Erweiterung einen anderen Namen enthält. Auch das ist kein Defekt, sondern der Standard bei der Arbeit.