"Die Verbindung ist nicht sicher" ("Your Connection Is Not Private"): Welche der fünf Ursachen es ist, und wessen Rechner schuld ist

Ein roter Warnbildschirm deckt mindestens fünf voneinander unabhängige Fehlerursachen ab. Genau das macht die Sache bei „Die Verbindung ist nicht sicher” so schwierig: Die Seite, die ein Nutzer sieht, ist identisch, egal ob Ihr Zertifikat letzte Nacht abgelaufen ist, sein Laptop glaubt, es sei 2019, oder sein Arbeitgeber seinen Datenverkehr mitliest.

Der Bildschirm verbirgt genau das eine Detail, das diese Fälle voneinander unterscheidet, und es steckt hinter dem Link Erweitert: ein Code, der mit NET::ERR_CERT_ beginnt. Alles Wichtige steckt in diesem Code, und fast kein Bug-Report enthält ihn.

Was der Browser tatsächlich tut

Bevor überhaupt eine Anfrage hinausgeht, prüft der Browser das Zertifikat, das der Server vorgelegt hat. Drei dieser Prüfungen scheitern häufig genug, um eigene Fehlercodes zu haben, und Chromiums eigene Liste der Netzwerkfehler beschreibt jeden davon in einer Zeile.

ERR_CERT_COMMON_NAME_INVALID bedeutet, in den Worten von Chromium: „Der Server hat mit einem Zertifikat geantwortet, dessen Common Name nicht mit dem Hostnamen übereinstimmte.” Das Zertifikat ist echt und gültig, nur für einen anderen Namen. Jemand hat www.example.com aufgerufen, während das Zertifikat example.com abdeckt, oder eine reine IP-Adresse, oder einen Staging-Host, der nie in die Liste der Namen aufgenommen wurde.

ERR_CERT_DATE_INVALID ist der interessante Fall, und die Formulierung lohnt zweimaliges Lesen: „Der Server hat mit einem Zertifikat geantwortet, das nach unserer Uhr entweder noch nicht gültig zu sein scheint oder bereits abgelaufen ist.”

Nach unserer Uhr. Der Browser vergleicht die Daten des Zertifikats mit der Uhr des Geräts, auf dem er läuft. Ein völlig gültiges Zertifikat scheitert an dieser Prüfung, wenn die Uhr des Geräts falsch geht, und ein Gerät mit falscher Uhr ist keine Seltenheit: ein Laptop, der Monate in einer Schublade lag, ein Smartphone, das seine Zeitsynchronisierung verloren hat, eine virtuelle Maschine, die aus einem Snapshot wiederhergestellt wurde, ein Desktop-Rechner, bei dem jemand das Datum von Hand gesetzt hat. Dieselbe Seite lädt bei Ihnen und wird bei ihnen abgelehnt, und nichts an der Fehlermeldung verrät, wessen Uhr falsch geht.

ERR_CERT_AUTHORITY_INVALID bedeutet „Der Server hat mit einem Zertifikat geantwortet, das von einer Stelle signiert wurde, der wir nicht vertrauen.” Drei sehr unterschiedliche Situationen führen zu diesem Fehler, und es lohnt sich, sie auseinanderzuhalten, was wir im Folgenden tun.

ERR_CERT_REVOKED bedeutet „Der Server hat mit einem Zertifikat geantwortet, das widerrufen wurde” (im englischen Original fehlt dort grammatisch ein Wort, das geht auf Chromiums eigene Kappe). Jemand hat es vor Ablauf zurückgezogen, meist weil ein Schlüssel durchgesickert ist. Das hier ist wirklich Ihr Problem, und es ist wirklich dringend.

Auch die Zahlencodes sind stabil, falls Sie am Ende Logs statt Bildschirme lesen: -200, -201, -202 beziehungsweise -206.

Drei der fünf Ursachen liegen nicht an Ihrem Server

Das ist der Teil, der aus einem Zertifikatsfehler eher ein Bug-Report-Problem als ein Betriebsproblem macht.

Die Uhr. Bereits erklärt. Ihr Zertifikat ist in Ordnung. Das Gerät des Nutzers ist sich nur uneinig darüber, welcher Tag heute ist. Sie können das nicht nachstellen, Sie können es nicht von Ihrer Seite aus beheben, und kein noch so häufiges Neu-Deployment ändert daran etwas.

Das Netzwerk liest den Datenverkehr mit. Ein Firmen-Proxy, manche Antivirenprodukte und die meisten Captive Portals in öffentlichen WLANs funktionieren, indem sie für jede Website ein eigenes Zertifikat vorlegen und es mit einem Root-Zertifikat signieren, das sie auf dem Gerät installieren. Funktioniert das, sieht der Nutzer nichts davon. Ist das Root-Zertifikat nicht installiert, oder handelt es sich nicht um ein Firmengerät, zeigt jede Website in diesem Netzwerk ERR_CERT_AUTHORITY_INVALID. Das Erkennungsmerkmal: Der Fehler folgt dem Netzwerk, nicht der Website. Dieselbe Person ist über mobile Daten problemlos unterwegs.

Das fehlende Zwischenzertifikat. Einem Zertifikat wird über eine Kette vertraut: Ihres wird von einem Zwischenzertifikat signiert, das wiederum von einem Root-Zertifikat signiert ist, dem der Browser bereits vertraut. Ihr Server soll das Zwischenzertifikat zusammen mit dem eigenen Zertifikat mitschicken. Tut er das nicht, sind manche Besucher trotzdem nicht betroffen, weil ihr Browser dieses Zwischenzertifikat bereits von anderswo kennt oder es sich spontan besorgt, während andere Besucher ERR_CERT_AUTHORITY_INVALID erhalten.

Dieser letzte Fall verdient einen eigenen Satz, denn er ist das am häufigsten falsch diagnostizierte Konfigurationsproblem im Web: Eine Kette ohne ihr Zwischenzertifikat funktioniert auf dem Rechner der Person, die sie eingerichtet hat, und schlägt bei einem Teil fremder Besucher fehl. Das ist wirklich der Fehler Ihres Servers, und Ihr eigener Browser ist das denkbar schlechteste Instrument, um ihn zu finden.

Schwach

Ein Kunde sagt, die Website sei unsicher. Hier in Chrome und Safari geprüft, Schloss-Symbol ist in Ordnung. Ihm gesagt, er solle seinen Cache leeren.

Besser

NET::ERR_CERT_AUTHORITY_INVALID, nur im Büro-WLAN, funktioniert über mobile Daten. Dieselbe Seite ist hier in Ordnung. Proxy oder fehlendes Zwischenzertifikat, die Kette von außen geprüft, bevor dem Netzwerk des Kunden die Schuld gegeben wurde.

Sie in einer Minute unterscheiden

Der Code grenzt es auf eine von drei Ursachen ein. Drei Fragen erledigen den Rest.

Welche Uhrzeit zeigt das Gerät an? Fragen Sie nach der Uhrzeit, nicht nach dem Datum. Bei manchen Dingen zählen Minuten, hier ist ein Jahr Abweichung der Normalfall, und das fällt sofort auf, sobald man hinschaut. Ist die Uhr falsch, ist ERR_CERT_DATE_INVALID erklärt, und es muss nichts weiter untersucht werden. Eine Geräteuhr, die still und heimlich um Monate danebenliegt, ist auch der Grund, warum „es ist gegen drei kaputtgegangen” Sie zur falschen Stunde in Ihren Logs schicken kann, es lohnt sich also, das über diesen einen Fehler hinaus im Kopf zu behalten. Der Leitfaden für Bug-Reports nimmt die Umgebung aus genau diesem Grund in die Vorlage auf.

Folgt es dem Netzwerk oder der Website? Eine Frage: Tritt es bei mobilen Daten auf? Ein Zertifikatsproblem, das verschwindet, sobald der Nutzer das WLAN verlässt, bedeutet, dass das Netzwerk ein eigenes Zertifikat vorlegt, und die Lösung liegt bei ihm selbst oder seiner IT-Abteilung.

Tritt es für irgendjemanden außerhalb Ihres Büros auf? Prüfen Sie die Kette von einem Rechner aus, der Ihre Website noch nie besucht hat, genau das ist ein externer SSL-Checker: Er verbindet sich frisch und meldet, was Ihr Server tatsächlich gesendet hat, statt dessen, was Ihr Browser gelernt hat zu ergänzen. Meldet er ein fehlendes Zwischenzertifikat, liegt es an Ihrem Deployment, und es ist wahrscheinlich seit der letzten Zertifikatsverlängerung für einen Teil der Besucher kaputt.

Die Verlängerung, die nur halb funktionierte

Es lohnt sich, dieses Muster zu kennen, weil es die verwirrendste Variante dieses Problems erzeugt.

Zertifikate werden heute automatisch verlängert, und eine Verlängerung, die das neue Zertifikat installiert, aber nicht das neue Zwischenzertifikat, oder die einen Prozess neu lädt und einen anderen nicht, hinterlässt einen Server, der aus manchen Blickwinkeln korrekt ist und aus anderen nicht. Nutzer hinter einem Load Balancer treffen zufällig auf den reparierten Knoten oder den veralteten. Die Hälfte der Berichte sagt, es sei kaputt, die andere Hälfte sagt, es sei in Ordnung, beide Hälften sagen die Wahrheit, und man verbringt eine Stunde damit, ein Muster in den Nutzern zu suchen, obwohl das Muster in den Servern liegt.

Der Ausweg besteht darin, nicht länger von einem Browser aus zu testen, der Ihnen möglicherweise unbemerkt hilft. Testen Sie den Endpunkt, von außen, wiederholt.

Was ein Melder Ihnen tatsächlich schicken kann

Hier ist die ehrliche Grenze, und sie gilt für uns genauso wie für alle anderen. Eine Zertifikatswarnung bedeutet, dass die Seite nie geladen wurde. Es gibt keine Konsole, kein Netzwerkprotokoll und nichts, was ein Capture-Tool aufzeichnen könnte, weil der Browser abgelehnt hat, bevor Ihre Website überhaupt laufen konnte. Worauf Sie sich normalerweise verlassen, um einen Fehler mit den Augen eines anderen zu sehen, steht hier nicht zur Verfügung.

Es läuft also wieder auf Nachfragen hinaus, und zwar nach den richtigen drei Dingen:

• Den Code, versteckt hinter „Erweitert”, vollständig. NET::ERR_CERT_AUTHORITY_INVALID, nicht „eine Sicherheitswarnung”.
• Datum und Uhrzeit auf ihrem Gerät, direkt von der eigenen Uhr abgelesen.
• Das Netzwerk, und ob es bei mobilen Daten anders aussieht.

Drei Antworten, und die Ursache steht meist fest, bevor irgendjemand überhaupt einen Server angeschaut hat. Das ist eine bessere Trefferquote, als die meisten Fehler bieten, und sie ist nur deshalb verfügbar, weil der Browser die Diagnose bereits erledigt und hinter einem Link versteckt hat, auf den niemand klickt.

Eine Sache, die man ihnen nicht raten sollte: die Warnung wegzuklicken. Es ist der Reflex, der Button ist direkt da, und bei einer echten Man-in-the-Middle-Situation übergibt das den Datenverkehr genau an die Stelle, die ihn abfängt. Liegt die Ursache bei der Uhr, dauert deren Korrektur dieselben dreißig Sekunden und lässt die Prüfung für die nächste Website weiter funktionieren.

Was man daraus mitnehmen sollte

Der rote Bildschirm ist eine Kategorie, keine Diagnose. Der Code unter „Erweitert” ist die Diagnose, und er kommt bei jedem Auftreten kostenlos mit.

Drei der Ursachen liegen auf dem Rechner des Nutzers oder in seinem Netzwerk, weshalb sie sich auf Ihrem Rechner grundsätzlich nicht nachstellen lassen, und diejenige, die wirklich Ihre eigene ist, das fehlende Zwischenzertifikat, ist genau die, die Ihr eigener Browser Ihnen am wenigsten wahrscheinlich zeigt. Beide Hälften laufen auf dasselbe hinaus: Fragen Sie bei Zertifikatsfehlern zuerst nach dem Code und testen Sie dann von außen, in dieser Reihenfolge.

Chromiums eigene Liste dieser Fehler, mit der einzeiligen Definition zu jedem, ist net_error_list.h. Sie ist die Quelle, aus der die Fehlerseiten generiert werden, und sie klärt Streitfragen schneller, als es jeder Artikel könnte.