Die automatische Verlängerung verspricht, dass Sie nicht mehr an Zertifikate denken müssen. Meistens hält sie dieses Versprechen, und deshalb ist der Tag, an dem sie versagt, eine Überraschung. Gestern funktionierte die Website, und heute zeigen Browser eine Warnung über die ganze Seite.
Der Grund ist, dass „automatische Verlängerung“ nicht eine einzelne Sache ist. Bei einem Zertifikat, das über das gängige automatisierte Protokoll (ACME) ausgestellt wird, das Let's Encrypt und andere nutzen, müssen mehrere Schritte jedes Mal funktionieren. Wie Zertifikate allgemein funktionieren und wie Sie ihre Daten lesen, steht unter So verhindern Sie das Ablaufen von SSL-Zertifikaten. Diese Anleitung behandelt den Fall, dass die Automatisierung eingeschaltet war und das Zertifikat trotzdem ablief.
Die Kette der Schritte
- Ein Job startet. Etwas läuft nach Zeitplan: ein Timer, ein Cron-Eintrag oder eine eingebaute Aufgabe Ihres Hostings.
- Der Verlängerungs-Client fordert ein neues Zertifikat an. Er kontaktiert die Zertifizierungsstelle.
- Die Zertifizierungsstelle prüft, ob Sie den Namen kontrollieren. Eine Challenge muss beantwortet werden, über das Web oder im DNS.
- Das neue Zertifikat wird gespeichert, in einer Datei oder einem Speicher.
- Der Server lädt es. Viele Server lesen die Datei nur beim Start oder bei einem Neuladen.
- Besucher erhalten es. Unter jeder Adresse, jedem Port und jeder Ebene, die ein Zertifikat vorlegt.
Läuft Schritt 1 nie, ist alles andere egal. Geschieht Schritt 5 nie, liegt die erneuerte Datei ungenutzt herum. Jeder Fehler sieht von außen gleich aus: ein altes Zertifikat, das abläuft.
Wo die Kette reißt
| Schritt | Was schiefgeht | Ein typisches Anzeichen |
|---|---|---|
| 1 | Der geplante Job wurde entfernt, deaktiviert oder nach einer Servermigration oder einem Upgrade nie übernommen | Wochenlang nichts im Verlängerungslog |
| 2 | Der Client ist zu alt, oder sein Konto oder Zugang ist weg | Fehler im Verlängerungslog zu Konto oder Anfrage |
| 3 | Der Validierungsschritt funktioniert nicht mehr: eine geänderte Firewall, eine Weiterleitung, die den Pfad der Challenge blockiert, ein geänderter DNS-Eintrag oder API-Zugang | Ein Fehler „challenge failed“ oder „unauthorized“ |
| 3 | Zu viele fehlgeschlagene oder wiederholte Anfragen haben die Ratenbegrenzung der Zertifizierungsstelle erreicht | Eine Meldung zur Ratenbegrenzung; Verlängerungen schlagen fehl, bis das Limit vorbei ist |
| 4 | Die Datei konnte nicht geschrieben werden, oder ein Hook, der sie kopiert, ist fehlgeschlagen | Die neue Datei liegt in einem Ordner, in einem anderen nicht |
| 5 | Der Server wurde nie neu geladen, oder er liest eine andere Datei als die, die der Client aktualisiert | Die Datei zeigt ein neues Datum, der Browser ein altes |
| 6 | Das Zertifikat wird von einer anderen Ebene vorgelegt: einem Load Balancer, einem CDN, einem Mailserver, einem anderen Port, einem anderen virtuellen Host | Eine Adresse ist erneuert, eine andere nicht |
Foren und Hosting-Anleitungen beschreiben all das. Am häufigsten sind ein Job, der nach einer Änderung verschwunden ist, und ein Zertifikat, das zwar verlängert wurde, während der Server die alte Kopie weiter auslieferte.
Das defekte Glied finden
Arbeiten Sie vom Ende her, denn das ist es, was Besucher sehen.
Was ausgeliefert wird
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject
Das gibt Start- und Enddatum des Zertifikats aus, das der Server unter dieser Adresse vorlegt. Ist das Enddatum nah oder vorbei, ist das Zertifikat dort, wo es zählt, nicht erneuert. Führen Sie es für jeden Namen und Port aus, den Sie nutzen, nicht nur für den Hauptnamen.
Was auf der Festplatte liegt
Mit Certbot gibt es die Liste der Zertifikate und ihrer Ablaufdaten so:
sudo certbot certificates
Hat die Datei ein neues Datum und der Server zeigt ein altes, liegt das Problem bei Schritt 5 oder 6: Der Server wurde nicht neu geladen oder liest eine andere Datei. Ist die Datei selbst alt, liegt das Problem bei den Schritten 1 bis 4.
Läuft der Job
Auf einem System mit Timern listet systemctl list-timers die geplanten Jobs auf. Suchen Sie den für die Verlängerung und wann er zuletzt lief. Ein einfaches Cron-Setup steht in crontab -l und in den Dateien unter /etc/cron.d/.
Funktioniert die Verlängerung jetzt
sudo certbot renew --dry-run
Ein Testlauf geht die Schritte durch, ohne etwas zu ersetzen. Ein Fehler hier ist derselbe Fehler, der die echte Verlängerung blockiert hat, und er nennt den Schritt.
Note
Diese Befehle setzen Certbot auf einem Linux-Server voraus. Andere Clients und Hosting-Panels haben ihre eigenen Werkzeuge. Die Reihenfolge bleibt dieselbe: was ausgeliefert wird, was gespeichert ist, ob der Job läuft, ob die Verlängerung funktioniert.
Beheben und vorbeugen
- Beheben Sie die Ursache und verlängern Sie dann einmal von Hand, damit Sie nicht auf den nächsten geplanten Lauf warten.
- Laden Sie den Server nach jeder Verlängerung neu. Die meisten Clients können nach einer erfolgreichen Verlängerung einen Befehl ausführen. Ohne ihn kann eine erneuerte Datei ungenutzt liegen bleiben.
- Führen Sie jeden Ort auf, an dem ein Zertifikat liegt. Die Website, den Mailserver, den API-Host, den Staging-Host, den Load Balancer. Jeder braucht seine eigene Verlängerung und seine eigene Prüfung.
- Vertrauen Sie nicht auf das Schweigen des Jobs. Ein Job, der still scheitert, sieht aus wie ein Job, der funktioniert. Der einzige Beweis, dass die Verlängerung geklappt hat, ist das neue Datum auf dem Zertifikat, das tatsächlich ausgeliefert wird.
- Behalten Sie eine unabhängige Warnung. Eine Warnung von außen, vor dem Enddatum, hängt von keinem Schritt der Kette ab.
Was ein Monitor ergänzt
Ein Monitor, der sich von außen mit Ihrer Adresse verbindet, liest das Zertifikat, das Besucher erhalten würden. Das ist Schritt 6, der einzige Schritt, den Sie vom Inneren des Servers aus nicht vortäuschen können, und er fängt jeden der obigen Fehler auf, gleich welcher Schritt ihn verursacht hat.
UptimeWire prüft das Zertifikat jeder https-Adresse etwa alle sechs Stunden und warnt Sie per E-Mail und Telegram innerhalb des Zeitraums, den Sie für diese Website gewählt haben, von 1 bis 60 Tagen vor dem Ablauf. Die Warnung wird einmal gesendet. Sie ist eine Erinnerung, zu handeln: UptimeWire verlängert, installiert oder repariert keine Zertifikate und findet nicht heraus, warum eine Verlängerung fehlgeschlagen ist. Es prüft das Zertifikat der Adresse, die Sie hinzufügen, andere Namen und Ports brauchen daher eigene Einträge.
Da Zertifikate etwa alle sechs Stunden geprüft werden, trifft eine Warnung einige Stunden nach dem Überschreiten der Schwelle ein, nicht im genauen Moment. Bei einem automatisch verlängerten Zertifikat funktioniert ein Warnzeitraum von 14 oder 30 Tagen als Sicherheitsnetz: Löst er aus, hat die Automatisierung ihre Chance bereits verpasst, und Sie haben noch Zeit, den Fehler zu beheben, bevor Besucher betroffen sind. Den Ablauf nach dem Eintreffen einer Warnung beschreibt Überwachung des Ablaufs von SSL-Zertifikaten.
Checkliste
- Welches Zertifikat liefert jede Adresse und jeder Port aus, und wann endet es?
- Ist der Verlängerungsjob geplant, und wann lief er zuletzt?
- Gelingt ein Testlauf, oder welchen Schritt nennt er?
- Wird der Server nach der Verlängerung neu geladen?
- Wird jeder Name, jede Subdomain und jeder Dienst, der ein Zertifikat vorlegt, verlängert?
- Gibt es eine Warnung von außen, die deutlich vor dem Enddatum eingestellt ist?