Let's-Encrypt-Erneuerung: die drei klassischen Pannen

Die automatische Zertifikatserneuerung hat einen ganz eigenen Charakter: Sie läuft monatelang tadellos, hört dann auf und sagt es niemandem. Der Befehl läuft weiterhin pünktlich. Er endet lediglich mit einem Fehler, in einer Protokolldatei, die niemand öffnet. Hier sind die drei Arten, wie sie wirklich bricht, und die einzige Prüfung, die alle drei abfängt.

Die drei Pannen, als Tabelle

Die dritte Zeile kommt am teuersten, gerade weil das Protokoll tadellos aussieht. Eine Überwachung, die das Erneuerungsprotokoll liest, erklärt also, alles sei in Ordnung, während Ihre Besucher einen roten Bildschirm sehen.

1. Die Validierungs-Challenge erreicht Ihren Server nicht mehr

Um zu bestätigen, dass Sie die Domain kontrollieren, fordert die Zertifizierungsstelle eine Datei unter /.well-known/acme-challenge/… auf Ihrer Website an. Ihr Server muss sie ausliefern, über einfaches HTTP, ohne Störung.

Was das Monate nach der Einrichtung kaputt macht:

• Eine globale Weiterleitung auf HTTPS oder auf eine neue Domain, aus besten Gründen hinzugefügt, die auch den Challenge-Pfad einfängt.
• Eine Firewall- oder WAF-Regel, die unbekannte Pfade zu filtern beginnt oder die Adressen sperrt, von denen die Validierung kommt.
• Eine Catch-all-Route des Frameworks, die jede unbekannte URL in eine 404-Seite verwandelt, einschließlich der Challenge-Datei, die nun ein 404 in hübschem Layout zurückgibt.
• Ein Bot-Schutz vor der Website, der jedem Client ohne JavaScript eine Warteseite vorsetzt.

Der Erneuerungsbefehl hat sich nicht geändert. Seine Umgebung schon. Das macht diese Panne schwer zuzuordnen: Niemand hat das Zertifikat angefasst, und trotzdem erneuert es sich nicht mehr.

Der Test besteht aus einer Zeile, von jedem beliebigen Rechner aus:

mkdir -p /var/www/html/.well-known/acme-challenge && echo ok > /var/www/html/.well-known/acme-challenge/test
curl -sI http://beispiel.de/.well-known/acme-challenge/test | head -n 1

Die erwartete Antwort ist 200. Ein 301 auf HTTPS ist in manchen Konfigurationen bereits ein Problem, und ein 403 oder ein 404 ist immer eines.

2. Das DNS hat sich bewegt

Wenn Sie ein Wildcard-Zertifikat erneuern, läuft die Validierung über einen DNS-Eintrag statt über eine Datei. Das setzt ein API-Token bei Ihrem DNS-Anbieter voraus, abgelegt in einer Konfigurationsdatei, das an dem Tag stillschweigend abläuft oder widerrufen wird, an dem jemand die Zugangsdaten rotiert.

Drei Spielarten derselben Geschichte:

• Das Token wurde widerrufen, bei einem Sicherheitsaufräumen, sechs Monate zuvor.
• Die Domain wurde übertragen, zu einem anderen Registrar, und niemand hat daran gedacht, das Skript zu informieren.
• Die Nameserver haben gewechselt, die Zone wird nun anderswo verwaltet, und das Skript schreibt gewissenhaft seinen Eintrag in eine Zone, die niemand mehr abfragt.

In allen drei Fällen steht der Fehler ausdrücklich im Protokoll. Es müsste ihn nur jemand öffnen, und das ist das ganze Problem. Wer ein Wildcard-Zertifikat betreibt, sollte deshalb den Trockenlauf an denselben Tag legen, an dem er ohnehin die Zugangsdaten durchsieht: Beide Aufgaben scheitern aus demselben Grund, und beide zusammen zu erledigen ist die einzige Art, sich daran zu erinnern.

3. Die Erneuerung hat geklappt, die Auslieferung nicht

Das ist die grausame Fassung. Das neue Zertifikat liegt auf der Platte, von heute datiert, einwandfrei gültig. Ihr Webserver zeigt weiterhin das alte, weil er seit seinem Start nicht neu geladen wurde.

Nichts im Erneuerungsprotokoll sieht ungewöhnlich aus. Die Datei ist da. Und Ihre Besucher bekommen trotzdem die bildschirmfüllende Sicherheitswarnung.

Die Ursache ist fast immer ein fehlender oder stiller Reload-Hook:

# Das Neuladen muss Teil der Erneuerung sein, nicht eines manuellen Handgriffs
--deploy-hook "systemctl reload nginx"

Zwei Fallen sind zu kennen. Ein fehlgeschlagener Hook lässt die Erneuerung nicht fehlschlagen: Er hinterlässt eine Meldung im Protokoll und gibt zurück. Und ein Dienst, der einen vollständigen Neustart statt eines Neuladens braucht, übernimmt die neue Datei nicht; das ist häufig bei Konfigurationen, die TLS außerhalb des Webservers beenden, hinter einem Proxy oder einem Lastverteiler, wo das Zertifikat an zwei Stellen ausgerollt werden muss.

Die vierte Panne, seltener und verwirrender

Die drei vorigen stammen aus Ihrer Installation. Diese kommt von anderswo, und sie verwirrt, weil der Befehl korrekt und der Server untadelig ist.

Das Kontingent wurde erreicht. Die Zertifizierungsstellen begrenzen die Zahl der für dieselbe Domain in einem bestimmten Zeitraum ausgestellten Zertifikate. Im Normalbetrieb erreicht man das selten und in einer Debugging-Schleife sehr leicht: zehn Neuausstellungsversuche an einem Nachmittag, und schon sind Sie eine Woche lang mit einem abgelaufenen Zertifikat in der Produktion blockiert. Genau dafür gibt es den Trockenlauf, der nichts verbraucht.

Der Kontoschlüssel ist verschwunden. Eine Neuinstallation des Servers, eine teilweise Wiederherstellung, ein ohne sein Volume neu gebauter Container: Der Client findet das Konto nicht mehr, dem die Zertifikate gehörten, und fängt bei null an, ohne das klar zu sagen.

Die Domain löst nicht mehr auf Sie auf. Ein geänderter Eintrag, eine laufende Migration, eine schlecht beendete Umschaltung. Die Validierung schlägt fehl, weil sie auf einer anderen Maschine landet, was zutreffend ist und mit dem Zertifikat nichts zu tun hat.

In drei Befehlen diagnostizieren

certbot renew --dry-run                 # spielt die ganze Erneuerung durch, ohne Kontingent zu verbrauchen
curl -sI http://beispiel.de/.well-known/acme-challenge/test   # kommt die Challenge durch
echo | openssl s_client -connect beispiel.de:443 2>/dev/null | openssl x509 -noout -dates

Der erste fängt die Pannen 1 und 2 ab. Der dritte fängt Panne 3 ab, und er ist der einzige, der sagt, was das Publikum tatsächlich bekommt.

Und wenn Sie nur wissen wollen, was das Publikum gerade bekommt, ohne ein Terminal zu öffnen, beantwortet die Seite, die ein Zertifikat liest, genau diese Frage mit einer einzigen Adresse.

Was man während der Panne nicht tun sollte

Stellen Sie nicht in Schleife neu aus: So wird aus einem reparierbaren Problem ein Wochenproblem. Schalten Sie HTTPS nicht ab, um „die Website wieder online zu bringen“: Alle Links im Web, die auf Ihre https://-Adressen zeigen, würden brechen, und Browser merken sich diese Vorliebe lange. Und installieren Sie kein selbstsigniertes Zertifikat als Notlösung: Es erzeugt genau dieselbe rote Seite, mit denselben Folgen, plus ein zweites Problem, das man danach wieder abbauen muss.

Die Prüfung, die alle drei abfängt

Jede dieser Pannen ist von innen unsichtbar und von außen offensichtlich. Also schauen Sie von außen: Öffnen Sie eine TLS-Verbindung zu Ihrem eigenen Hostnamen und lesen Sie das Ablaufdatum des tatsächlich ausgelieferten Zertifikats.

Diese eine Messung deckt auf einen Schlag eine fehlgeschlagene Challenge, ein DNS-Problem und ein fehlendes Neuladen ab, weil alle drei an derselben Stelle enden: einem alten Zertifikat, das dem Publikum weiterhin vorgelegt wird. Sie hat zudem den Vorzug, nichts über Ihre Installation vorauszusetzen, was sie auch nach einem Wechsel des Hosters oder des Technikstapels gültig hält.

Warnen Sie bei dreißig Tagen, sieben Tagen und einem Tag. Dreißig lassen Raum, in Ruhe zu debuggen; einer fängt das Neuladen ab, das nie stattgefunden hat. Eine tägliche Prüfung genügt bei Weitem, und das ist ein Fall, in dem eine höhere Frequenz nichts bringt: Ein Ablaufdatum ändert sich nicht von Stunde zu Stunde.

Zwei Gewohnheiten, die sich lohnen

Mit Vorlauf erneuern. Bei sechzig Tagen auf einem Neunzig-Tage-Zertifikat lässt Ihnen ein Fehlschlag einen Monat statt eines Nachmittags. Das ist die Voreinstellung der meisten Clients, und es ist einer der wenigen Vorgabewerte, die man auf keinen Fall anfassen sollte.

Die Erneuerung testen, nicht nur das Zertifikat. Den Trockenlauf gibt es in fast allen Clients. Ihn einmal im Monat zu starten verwandelt eine stille Panne in eine bekannte Panne, Monate bevor sie zählt. Und weil niemand sonst Sie warnen wird, ist er Ihre einzige Vorwarnung.

Wenn es bereits abgelaufen ist

Suchen Sie nicht zuerst die Ursache. Erneuern und neu laden, die Website wieder in Ordnung bringen, und danach ermitteln: Das ist dieselbe Reihenfolge wie bei den ersten fünfzehn Minuten eines Vorfalls, aus demselben Grund, nämlich dass eine gesperrte Website jede Minute etwas kostet, während Sie verstehen.

Nichts davon ändert nebenbei Ihre Sichtbarkeit in Suchmaschinen: HTTPS wiegt für Suchmaschinen viel weniger, als die Panik nahelegt. Es zählt für die Person, die Ihre Website nicht öffnen kann.