Wieder so ein "extrem wichtiger" Request von mit....
Kurzfassung:
Der Check warnt ab Werk 30 Tage vor Ablauf (warnDays default 30, errorDays default 14). Genau bei 30 Tagen Restlaufzeit erneuern die verbreiteten ACME-Clients ihr Zertifikat. Die Warnung kommt also nicht vor einem Problem, sondern regelmäßig am Tag vor der planmäßigen Erneuerung — bei einem Let's-Encrypt-Zertifikat alle 60 Tage aufs Neue, für jeden Endpunkt.
Warum 30 Tage die falsche Zahl ist
Ein Let's-Encrypt-Zertifikat läuft 90 Tage. Erneuert wird bei etwa einem Drittel Restlaufzeit: certbot ab 30 Tagen Rest, acme.sh nach 60 Tagen Standzeit, Caddy bei einem Drittel der Gesamtlaufzeit, Traefik 30 Tage vor Ablauf, win-acme nach 55 Tagen. Die Voreinstellung des Checks liegt damit auf demselben Tag wie die Erneuerung.
In meiner Instanz überwache ich 69 Endpunkte über 11 Zuweisungen, überwiegend Let's Encrypt (tendenz steigend da ich immer mehr auf api basierte DNS-autorisierte Erneuerungen mit LE Zertifikaten umstelle). Heute standen wieder zwei davon mit 29 Tagen Restlaufzeit in Warnung — beide erneuern sich in den nächsten Tagen von selbst. Das ist kein Einzelfall, sondern der Normalfall, und es ist die Art Meldung, die einen Monitoring-Kanal unbrauchbar macht: Sie ist immer da, sie ist immer unbegründet, und irgendwann sieht man die echte nicht mehr.
Eine Warnung ist erst dann eine Information, wenn die automatische Erneuerung nicht stattgefunden hat. ACME-Clients versuchen es täglich. Bei 21 Tagen Restlaufzeit sind mindestens neun Versuche gescheitert — das ist ein Befund. Bei 30 Tagen ist es der Normalbetrieb.
Die feste Tagesschwelle läuft ohnehin aus
Mit Ballot SC-081v3 sinkt die maximale Laufzeit öffentlicher TLS-Zertifikate schrittweise: 200 Tage seit dem 15.03.2026, 100 Tage ab dem 15.03.2027, 47 Tage ab dem 15.03.2029. Ein 100-Tage-Zertifikat wird bei rund 33 Tagen Rest erneuert — die 30-Tage-Warnung liegt dann dauerhaft im Erneuerungsfenster. Bei 47 Tagen Laufzeit greift sie unmittelbar nach der Ausstellung. Eine absolute Tagesangabe als einzige Stellschraube hat damit ein Ablaufdatum.
Vorschlag:
Default auf 21 Tage senken (
warnDays21,errorDays7). Kleine Änderung, wirkt sofort für alle Neuzuweisungen und trifft die gängigen ACME-Clients nicht mehr.Schwelle je Zuweisung statt je Endpunkt, mit optionaler Abweichung am einzelnen Endpunkt. Heute steht
warnDaysin jedem Endpunkt-Objekt. Bei einer Zuweisung mit 24 Endpunkten heißt eine Korrektur: 24 Einträge aufklappen und einzeln ändern. Über die API war das ein Skript, in der Oberfläche ist es eine halbe Stunde.Alternativ oder ergänzend eine relative Schwelle — Warnung bei X Prozent Restlaufzeit statt bei X Tagen. Das ist die Variante, die die Laufzeitverkürzung ohne weiteres Nachjustieren übersteht: 20 Prozent Rest sind bei 90 Tagen 18 Tage, bei 47 Tagen 9 Tage, jeweils deutlich hinter dem Erneuerungszeitpunkt.
Punkt 1 allein löst das Alltagsproblem. Punkt 3 löst es dauerhaft.