Abgelaufenes SSL-Zertifikat: was Ihre Besucher sehen

Ein abgelaufenes Zertifikat erzeugt keine dezente Warnung. Es erzeugt eine ganze Seite, meist rot, die erklärt, die Verbindung sei nicht privat und Angreifer versuchten womöglich, Ihre Daten zu stehlen. Die meisten Besucher gehen nicht hindurch. Viele schließen daraus, die Website sei gehackt worden.

Währenddessen geht es Ihrem Server bestens. Er liefert die Seiten genau wie gestern, er antwortet in wenigen Millisekunden, und keines Ihrer Protokolle meldet irgendetwas.

Die genaue Meldung sagt Ihnen, welches der vier Probleme Sie haben

Bevor Sie irgendetwas anfassen, lesen Sie den Fehlercode unter der Meldung. Die Browser verstecken ihn hinter einem Link „Erweitert“, und er enthält die gesamte Information.

Die ersten beiden Zeilen behebt man mit einem Befehl. Die dritte ist die heimtückischste und verdient einen eigenen Abschnitt. Die vierte ist überhaupt kein Zertifikatsproblem.

Warum das Websites trifft, die funktionieren

Die Erinnerung ging an eine Adresse, die niemand liest. Die Zertifizierungsstellen warnen per E-Mail, an die bei der Ausstellung angegebene Adresse: oft ein Sammelpostfach, manchmal ein Entwickler, der vor zwei Jahren gegangen ist.

Die automatische Erneuerung ist stillschweigend fehlgeschlagen. Die Aufgabe ist eingeplant und endet mit einem Fehler. Nichts fällt geräuschvoll um: Das Zertifikat wird schlicht nicht mehr ersetzt. Das ist die häufigste Ursache auf modernen Servern, und sie hat drei klassische Spielarten.

Das Zertifikat wurde erneuert, aber nicht ausgeliefert. Eine neue Datei liegt auf der Platte, von heute datiert, einwandfrei gültig. Der Webserver behält die alte im Speicher, weil niemand ihn neu geladen hat. Wirklich zermürbend, und sehr verbreitet.

Eine Subdomain wurde vergessen. Das Zertifikat deckt beispiel.de und www ab, aber nicht das shop., das Sie im März hinzugefügt haben. Die Hauptwebsite läuft gut, und ein Teil des Verkehrs läuft gegen eine Wand.

Was ein Besucher vor dieser Seite tut

Er liest den Fehlercode nicht. Er sieht ein durchgestrichenes Schloss, einen roten Hintergrund und einen Satz, der von Datendiebstahl spricht. Drei Reaktionen teilen sich das Wesentliche: den Tab schließen, zu den Suchergebnissen zurückkehren und auf das nächste klicken, oder jemandem schreiben, dass Ihre Website gehackt wurde.

Keine dieser drei Reaktionen lässt sich nachträglich reparieren. Das unterscheidet diese Störung von einem gewöhnlichen Serverfehler: Eine Seite, die einen Code 500 oder 503 zurückgibt, beunruhigt einen Besucher; eine Seite, die einen Diebstahlversuch ankündigt, vertreibt ihn und hinterlässt eine Erinnerung.

Misstrauen Sie den kursierenden Zahlen über den Anteil der Leute, die trotzdem weiterklicken: Sie stammen aus alten Stichproben und aus Zusammenhängen, die nicht die Ihren sind. Sicher ist, dass die Schaltfläche zum Fortfahren absichtlich hinter zwei Klicks versteckt ist und dass diese Seite genau darauf hin gestaltet wurde, dass niemand sie durchschreitet.

Der halbe Tag, der am meisten kostet

Die Sperre erscheint im exakten Augenblick des Ablaufs, oft nachts, oft am Wochenende, weil die neunzig Tage genau dann zu Ende gehen. Bis es am Montagmorgen jemand bemerkt, zeigt die Website seit sechsunddreißig Stunden jedem Besucher eine Sicherheitswarnung.

Niemand wird Sie in dieser Zeit anrufen: Ihre internen Werkzeuge sehen nichts, und Ihr Hoster auch nicht, denn aus seiner Sicht antwortet die Maschine tadellos. Das ist die Störung, die einer Störung am ähnlichsten sieht, ohne eine zu sein, und deshalb gilt für sie derselbe Reflex wie für die ersten fünfzehn Minuten eines Vorfalls: von außen schauen, bevor man in den Code schaut.

In dreißig Sekunden prüfen

Ein einziger Befehl liefert das Ablaufdatum des Zertifikats, das dem Publikum tatsächlich vorgelegt wird, und das ist nicht immer das, was auf Ihrer Platte herumliegt:

echo | openssl s_client -servername beispiel.de -connect beispiel.de:443 2>/dev/null \
  | openssl x509 -noout -dates -subject

notAfter gibt die Frist an, subject und die alternativen Namen sagen, welche Hosts abgedeckt sind. Wiederholen Sie den Befehl für jede Subdomain, die Sie ausliefern: Jede ist eine eigene Frage. Führen Sie ihn außerdem von einer Maschine aus, die nicht Ihre eigene ist, etwa von einem beliebigen Server: Ein lokaler Zwischenspeicher oder ein Eintrag in Ihrer Hosts-Datei kann Ihnen ein Ergebnis zeigen, das kein Besucher jemals bekommt, und das ist genau die Art von Detail, die eine Prüfung wertlos macht, ohne dass man es merkt.

Wenn Sie kein Terminal zur Hand haben oder einfach nur die Zahl wollen: unser Zertifikatsleser tut dasselbe im Browser und liefert das Datum, die abgedeckten Hosts und den Zustand der Kette.

Der Fall der unvollständigen Kette

Das ist die Falle, die am meisten Zeit kostet, weil sie auf dem Rechner dessen, der prüft, nicht sichtbar ist.

Ein Zertifikat steht nicht allein: Es ist von einem Zwischenzertifikat signiert, das selbst von einer Wurzel signiert ist. Ihr Server muss das Zertifikat und das Zwischenzertifikat ausliefern. Vergisst er das zweite, kommen Desktopbrowser oft dennoch zurecht, weil sie das Zwischenzertifikat bei einem früheren Besuch auf einer anderen Website zwischengespeichert haben. Mobilgeräte hingegen verweigern.

Ergebnis: Die Website läuft auf Ihrem Arbeitsplatz einwandfrei und zeigt einem Teil Ihrer Besucher eine Warnung. Der Test erfolgt von einem Telefon über Mobilfunk, oder mit dem obigen Befehl von einem Rechner, der die Website nie besucht hat.

Was die kurze Lebensdauer verändert hat

Vor zehn Jahren hielt ein Zertifikat ein Jahr oder länger, und eine Erinnerung im gemeinsamen Kalender erledigte die Sache. Die kostenlosen Zertifikate von heute halten neunzig Tage, und der allgemeine Trend geht zu noch kürzeren Laufzeiten, aus guten Sicherheitsgründen.

Das verschiebt das Problem vollständig. Eine jährliche Erneuerung ist ein Ereignis, an das sich jemand erinnert; eine vierteljährliche ist eine automatische Routine, die niemand ansieht. Die Frage lautet also nicht mehr „wer denkt ans Erneuern“, sondern „wer prüft, ob die Automatik noch läuft“.

Diese Umkehrung verdient es, ausgesprochen zu werden, denn sie macht zwei alte Reflexe nutzlos. Das Ablaufdatum im Kalender zu notieren bringt nichts mehr: Es ändert sich viermal im Jahr. Dem Erneuerungsprotokoll zu vertrauen ebenso wenig: Die drei klassischen Pannen hinterlassen dort eine Spur, die niemand öffnet, und die dritte hinterlässt nicht einmal einen Fehler.

Es bleibt eine einzige Prüfung, die noch Sinn ergibt, und es ist die, die von außen schaut, so wie es ein Besucher tun würde, ohne Zugang zu Ihrem Server und ohne Wissen über Ihre Aufgabenplanung.

Was es wirklich verhindert

Das Ablaufdatum überwachen, nicht die Erneuerungsaufgabe. Eine Prüfung, die das von Ihrem Server vorgelegte Zertifikat liest und die verbleibenden Tage zählt, sagt die Wahrheit: Sie sieht das Zertifikat, das ein Besucher erhielte, nicht das, was auf der Platte liegt. Die drei obigen Ursachen enden alle an derselben Stelle, und diese Messung fängt alle drei ab.

Mit echtem Vorlauf warnen. Dreißig Tage, dann sieben, dann einer. Dreißig Tage genügen, um eine kaputte Erneuerung in Ruhe zu reparieren; ein Tag genügt, um eine Auslieferung nachzuholen, die nicht neu geladen hat.

Jeden Hostnamen prüfen, den Sie ausliefern. Jede Subdomain ist eine eigene Zertifikatsfrage, und die vergessene ist immer die, die später hinzugefügt wurde.

Eine menschliche Adresse ins Zertifikat schreiben. Das kostet nichts und ist die letzte Verteidigungslinie, wenn alles andere vergessen wurde. Ein Verteilerpostfach, das zwei Personen erreicht, ist besser als eine persönliche Adresse, denn Personen wechseln den Arbeitgeber, Verteiler seltener.

Was es nicht ist

Es ist kein Hackerangriff, und das dem, der es Ihnen meldet, klar zu sagen, erspart eine Stunde unnötiger Panik. Es ist keine Serverstörung: nichts neu zu starten, nichts wiederherzustellen. Und es ist nicht in erster Linie ein Suchmaschinenproblem.

Was HTTPS für Suchmaschinen wirklich ändert, ist bescheidener, als die Dringlichkeit dieser Seite glauben macht. Der Grund, ein Zertifikat zu reparieren, ist der Besucher, der Rot sieht, nicht der Algorithmus.