Im Homelab läuft vieles monatelang still vor sich hin, bis ein Zertifikat, ein API-Token oder eine Evaluationslizenz mitten im Betrieb abläuft. Statt Erinnerungen über Kalender, Skripte und Notizen zu verteilen, pflege ich alle Fristen an einer einzigen Stelle: einer YAML-Datei im Dokumentations-Repository, aus der einmal täglich eine Übersichtsseite berechnet wird. TLS-Zertifikate und das Passwortalter des zentralen Windows-Dienstkontos schreibe ich dort nicht von Hand ab, sondern lasse sie beim Lauf live von den Systemen abfragen.
Was im Homelab alles ein Ablaufdatum hat
Wer nur an TLS-Zertifikate denkt, übersieht die Hälfte. Als ich meine Liste zum ersten Mal zusammengetragen habe, kamen schnell fast zwanzig Posten aus ganz unterschiedlichen Ecken zusammen:
- Webzertifikate der drei Proxmox-Knoten, des Proxmox Backup Servers, der GitLab-Instanz und der OPNsense-Firewall
- die jährliche Sperrliste (CRL) der eigenen Root-CA
- API- und Projekttokens in GitLab (etwa für die Drift-Prüfung in Checkmk, für das Meldeformular im Intranet)
- ein interner Meldetoken, mit dem der Windows-Dateiserver seine Freigaben ans Intranet meldet (hat keinen technischen Ablauf, soll aber jährlich rotieren)
- das Active-Directory-Dienstkonto für die automatische Windows-Abfrage über WinRM
- Windows-Server-Evaluationszeiträume auf neu aufgesetzten VMs (Sub-CA und Medienserver), bevor die endgültige Lizenz per
DISMeingespielt wird - Domain-Verlängerungen beim Registrar und das Prepaid-Guthaben auf dem Konto davor
- wiederkehrende Handgriffe wie der Ausdruck der Notfallseiten auf Papier, die Kontrolle des gedruckten Notfallblatts für den Kennwort-Tresor und die monatliche Wiederaufbau-Übung
Manche dieser Termine sind hart: Läuft das Zertifikat auf dem Backup-Server ab, verweigern die Proxmox-Knoten die nächtliche Sicherung, weil sie seit dem Umbau auf die eigene Zertifizierungsstelle nicht mehr gegen einen festen Fingerabdruck, sondern gegen die CA-Kette prüfen. Läuft der Evaluationszeitraum einer Windows-VM ab, fährt sie irgendwann stündlich herunter. Andere Termine sind organisatorisch, haben aber handfeste Folgen: Auf dem Prepaid-Konto beim Domain-Registrar lagen im Oktober noch 47,96 Euro, die nächste Verlängerung zweier Domains im Februar kostet zusammen 48,20 Euro. Wegen 24 Cent Differenz würden die Domains nicht verlängert und die E-Mail-Zustellung fiele aus. Deshalb steht die Guthabenprüfung als eigene Frist knapp drei Wochen vor dem Verlängerungstermin in der Liste.
Aufbau der zentralen Datei
Die Quelle für alle festen und wiederkehrenden Termine ist eine einfache Textdatei (inventory/fristen.yaml). Dort stehen ausschließlich Namen, Daten, Intervalle und Speicherorte, niemals Kennwörter, Tokens oder Schlüssel. Ein Eintrag hat entweder ein festes Ablaufdatum oder ein Intervall mit dem Datum der letzten Durchführung.
# Fester Termin (Beispiel: GitLab-Token für Checkmk)
- was: "API-Token für den Monitoring-Check"
ablauf: 2027-10-01
wirkung: "Checkmk-Service meldet UNKNOWN; Rollout läuft weiter"
erneuern: "Neues Token mit Leserechten anlegen, in die Zugangsdatei des Checks schreiben, altes widerrufen"
ort: "Monitoring-Server, Zugangsdatei des Checks"
# Wiederkehrender Termin (alle 3 Monate ab letzter Durchführung)
- was: "Notfallseiten neu ausdrucken"
alle_monate: 3
letzte: 2026-07-15
wirkung: "Bei Komplettausfall fehlt die aktuelle Anleitung auf Papier"
erneuern: "Druckfassung auf A4 drucken, alten Ausdruck ersetzen, Datum 'letzte' nachziehen"
ort: "Doku-Server und Kopie auf Knoten 2"Bei wiederkehrenden Aufgaben wie der monatlichen Runbook-Übung muss ich das Datum nicht einmal selbst anfassen: Sobald ich einen Übungslauf mit seinem Ergebnis in der Dokumentations-Datenbank vermerke, rückt das Startdatum und damit die nächste Frist um einen Monat weiter. Beim Ausdruck der Notfallseiten oder des Notfallblatts für den Kennwort-Tresor (jeweils alle drei Monate) wird letzte nach dem Blick aufs Papier aktualisiert.
Drei Quellen statt Handarbeit: Datei, Intervall und Live-Abfrage
Abgeschriebene Zertifikatslaufzeiten stimmen spätestens nach der ersten außerplanmäßigen Erneuerung nicht mehr. Als ich im Oktober die Webzertifikate der drei Proxmox-Knoten, des Backup-Servers und der GitLab-VM auf meine interne Issuing CA umgestellt habe, bekamen alle fünf Dienste neue Zertifikate mit Laufzeit bis Oktober 2028. Hätte ich diese Daten von Hand in der YAML-Datei gepflegt, wäre bestimmt eines vergessen worden.
Das tägliche Skript kombiniert deshalb drei Wege, um auf die fertige Tabelle zu kommen:
Verträge, Domain-Laufzeiten, Windows-Evaluationszeiträume und API-Tokens, die sich nicht ohne Weiteres von außen abfragen lassen, kommen als festes Datum aus der YAML-Datei. Wiederkehrende Kontrollen stehen ebenfalls in der YAML-Datei, berechnen ihr nächstes Fälligkeitsdatum aber aus dem letzten Stichtag und dem hinterlegten Monatsintervall. TLS-Zertifikate der Webdienste und das Ablaufdatum des Active-Directory-Dienstkontos für die Windows-Fernwartung liest der Generator dagegen bei jedem Lauf direkt von den Zielsystemen aus.
Gerade die Live-Abfrage der Zertifikate hat sofort einen echten Fund geliefert: Während die Proxmox-Knoten, der Backup-Server und GitLab mit ihren neuen CA-Zertifikaten noch 718 Tage Restlaufzeit zeigten, stand die Weboberfläche der OPNsense-Firewall mit ihrem alten, selbstsignierten Zertifikat rot in der Liste – abgelaufen seit dem 11. Februar 2026. Die Firewall-Funktion selbst leidet darunter nicht, aber Browser warnen und API-Aufrufe mit strenger Zertifikatsprüfung brechen ab. In einer handgepflegten Liste hätte ich Stein und Bein geschworen, dass dort alles aktuell ist.
Sechs Spalten, damit im Ernstfall niemand suchen muss
Eine reine Datumsliste hilft wenig, wenn man zehn Tage vor Ablauf vor dem Eintrag „API-Token des Meldeformulars“ sitzt und nicht mehr weiß, auf welchem Server die Datei liegt, welche Dateirechte sie braucht und welche Rolle das Token in GitLab haben muss. Deshalb hat jede Zeile in der erzeugten Tabelle genau sechs Spalten:
| Spalte | Inhalt | Beispiel aus meiner Liste |
|---|---|---|
| Ablauf | Berechnetes oder gelesenes Datum (JJJJ-MM-TT), aufsteigend sortiert | 2027-10-08 |
| Noch | Resttage mit Ampel: grün (> 30 Tage), orange (≤ 30 Tage), rot (abgelaufen) | 🟢 353 Tage |
| Was | Genaue Bezeichnung des Zertifikats, Tokens oder Vorgangs | API-Token des Meldeformulars |
| Quelle | Woher das Datum stammt: Datei, alle N Monate, zuletzt … oder live gelesen | Datei |
| Wirkung | Was konkret kaputtgeht, wenn man nichts tut | Meldeformular im Intranet liefert Fehler 502; Rest läuft weiter |
| Erneuern | Befehl oder Klickweg, wer zuständig ist und wo die Datei liegt | Neuen Projekttoken (Reporter, Scope api) in der Zugangsdatei des Intranets ablegen, alten widerrufen |
Die Spalte „Wirkung“ zwingt beim Eintragen dazu, kurz nachzudenken: Fällt bei Ablauf das halbe Netz aus oder erscheint nur ein gelbes Dreieck im Monitoring? Wenn das Webzertifikat der OPNsense abläuft, arbeitet das Routing weiter. Läuft dagegen das WinRM-Dienstkonto ab, kann der Admin-Container keine Windows-Systeme mehr abfragen und die automatische Dokumentation steht still. Und die Spalte „Erneuern“ spart das Zusammensuchen aus alten Notizen: Beim Proxmox-Webzertifikat steht dort direkt das Rollout-Skript der internen CA samt dem Rückfallbefehl pvecm updatecerts --force und dem Pfad /etc/pve/nodes/<Knoten>/pve-ssl.pem.
Warnung 30 Tage vorher
Eine Übersichtsseite in der Dokumentation nützt nur, wenn man nicht jeden Morgen daran denken muss, sie aufzurufen. Das Skript läuft einmal täglich automatisch durch und berechnet für jeden Eintrag die verbleibenden Tage. Alles, was in 30 Tagen oder weniger abläuft – oder bereits überfällig ist –, wird nicht nur in der Fristentabelle orange bzw. rot markiert, sondern automatisch auch auf die zentrale Seite mit den offenen Abweichungen übernommen.
Dreißig Tage Vorlauf haben sich als guter Schnitt erwiesen: Bei einer Windows-Evaluationslizenz oder einem API-Token reicht ein freier Abend am Wochenende, um den Schlüssel einzuspielen oder das Token zu tauschen. Bei einer Banküberweisung auf das Prepaid-Konto des Domain-Registrars oder einer anstehenden Runbook-Übung sind vier Wochen ebenfalls bequem, ohne dass die Warnung so früh kommt, dass man sie doch wieder wegdrückt.
Was noch offen ist
Vollständig ist die automatische Abfrage noch nicht. Die Webzertifikate der Linux-Dienste lese ich bereits live aus, aber die Überwachung der Windows-Serverzertifikate aus dem Autoenrollment der eigenen Sub-CA und die Ablaufprüfung der Sperrlisten in Checkmk sind noch in Arbeit. Auch das jährliche Prüfdatum der Root-Sperrliste (aktuell gültig bis zum 8. Oktober 2027) und das Backup-Token des Proxmox Backup Servers (bisher ohne festes Ablaufdatum) stehen noch auf der Liste der Kandidaten, die in den automatischen Lauf umziehen sollen. Als Nächstes steht außerdem die automatische Passwortrotation für diejenigen Dienstkonten an, die im Kontenverzeichnis bereits mit rotation: automatisch markiert sind – zuerst als Pilot mit einem einzelnen unkritischen Konto für den ISO-Abruf auf den Proxmox-Knoten, bevor der monatliche Lauf alle Dienstkonten übernimmt.
Schreibe einen Kommentar