6-Tage-Zertifikate 2026: SSL-Monitoring neu justieren

Was 6-Tage-Zertifikate sind - und warum sie kommen

Ein 6-Tage-Zertifikat ist ein regulär vertrauenswürdiges TLS-Zertifikat, dessen Gültigkeit auf 160 Stunden begrenzt ist - gut sechs Tage (Let's Encrypt). Abgerufen wird es über das shortlived-Profil in einem ACME-fähigen Client wie Certbot oder acme.sh, der Rest läuft wie bei einem gewöhnlichen Zertifikat. Parallel hat Let's Encrypt Zertifikate für IP-Adressen eingeführt: Diese sind verpflichtend kurzlebig und ebenfalls nur 160 Stunden gültig, weil der Besitz einer IP schneller wechseln kann als der einer Domain (Let's Encrypt). Beide Varianten decken IPv4 und IPv6 ab (Let's Encrypt).

Der Sinn hinter der kurzen Laufzeit ist Sicherheit: Je kürzer ein Zertifikat gültig ist, desto kleiner das Zeitfenster, in dem ein kompromittierter Schlüssel missbraucht werden kann - und desto weniger hängt die Sicherheit an trägen Sperrmechanismen wie CRL oder OCSP (Let's Encrypt). Das erste Sechs-Tage-Zertifikat stellte Let's Encrypt bereits im Februar 2025 aus, die allgemeine Verfügbarkeit folgte knapp ein Jahr später (Help Net Security). Die Richtung ist eindeutig: Ende 2025 kündigte Let's Encrypt an, auch die Standard-Laufzeit von 90 auf 45 Tage zu senken (Let's Encrypt). Kurzlebige Zertifikate sind damit kein Nischenexperiment mehr, sondern der neue Normalfall, auf den sich der Betrieb einstellen sollte.

Der Branchentrend: von 398 auf 47 Tage

Kurzlebige Zertifikate von Let's Encrypt sind nur die Speerspitze einer Bewegung, die die gesamte Branche erfasst. Das CA/Browser Forum - das Gremium aus Zertifizierungsstellen und Browser-Herstellern - hat im April 2025 den Beschluss SC-081v3 mit 29 zu 0 Stimmen angenommen (CA/Browser Forum). Er senkt die maximal zulässige Laufzeit öffentlich vertrauenswürdiger TLS-Zertifikate in drei Stufen: von 398 Tagen auf 200 Tage ab dem 15. März 2026, auf 100 Tage ab dem 15. März 2027 und schließlich auf 47 Tage ab dem 15. März 2029 (CA/Browser Forum). Parallel schrumpft die Wiederverwendbarkeit der Domain-Validierung (DCV) bis 2029 auf zehn Tage (CA/Browser Forum).

Der praktische Effekt: Manuelle Zertifikatserneuerung wird zum Auslaufmodell. Wer alle 47 Tage - oder gar alle zwei Tage - von Hand ein Zertifikat tauscht, verliert diesen Wettlauf. Automatisierung per ACME ist die einzige tragfähige Antwort, und mit der Automatisierung verlagert sich das Betriebsrisiko vom Menschen auf die Maschine. Genau deshalb muss auch das Monitoring mitwandern: weg vom Kalendereintrag, hin zur laufenden Kontrolle der Erneuerungskette.

Für kleine und mittlere Betriebe heißt das nicht, selbst zur Zertifizierungsstelle zu werden. Die meisten Hoster und Reverse-Proxys erneuern Zertifikate bereits automatisch per ACME. Entscheidend ist, dass jemand den Überblick behält, ob diese Automatik auch wirklich greift - gerade dann, wenn sie in fremder Hand liegt und man selbst keinen direkten Blick auf den Erneuerungs-Job hat. Ein externes Monitoring übernimmt genau diese Aufsicht, ohne dass Sie Zugriff auf den Server oder den ACME-Client brauchen.

Warum klassische Ablauf-Alarme bei Kurzläufern versagen

Über Jahre war die SSL-Überwachung simpel: Man hinterlegte eine Warnung 30 oder 14 Tage vor Ablauf, und ein Mensch tauschte das Zertifikat rechtzeitig aus. Dieses Modell setzt Monate an Vorlauf voraus. Bei einem Zertifikat mit 160 Stunden Laufzeit ist eine 14-Tage-Schwelle unbrauchbar - das Zertifikat existiert nicht einmal so lange. Eine solche Regel würde permanent Alarm schlagen und landet in der Praxis dort, wo überreizte Alarme oft landen: stummgeschaltet.

Bei Kurzläufern verschiebt sich zudem der Fehlermodus. Früher lautete die typische Ursache eines Ausfalls: Jemand hat vergessen, das Zertifikat zu erneuern. Heute lautet sie: Die Automatik hat still ihren Dienst eingestellt. Ein gestoppter Cron-Job, ein abgelaufener API-Zugang oder eine fehlgeschlagene Challenge fällt niemandem sofort auf, weil kein Mensch mehr aktiv im Prozess steht. Das überwachte Signal muss deshalb der Erneuerungsvorgang sein, nicht mehr allein das Ablaufdatum. Das gilt genauso für Domains - wie der Beitrag zum Domain-Ablauf verhindern zeigt, sind es oft die stillen Automatismen, die reißen.

Was bei Kurzläufern wirklich überwacht werden muss

Wer kurzlebige Zertifikate betreibt, überwacht nicht ein Datum, sondern einen Rhythmus. Vier Signale zusammen ergeben ein belastbares Bild vom Zustand der Erneuerungskette.

Keines dieser vier Signale reicht allein. Ein aktuelles notBefore-Datum sagt wenig, wenn der Erneuerungs-Job nur diesmal zufällig lief; ein grünes Lebenszeichen nützt nichts, wenn der Job zwar startet, die Ausstellung aber abgelehnt wird. Erst das Zusammenspiel aus Rhythmus, Job-Kontrolle, Rest-Anteil und Endpunkt-Inventar macht sichtbar, ob die gesamte Kette gesund ist. Wichtig ist dabei, jeden ausgelieferten Hostnamen und jedes Zertifikat einzeln zu betrachten - ein Wildcard-Zertifikat und ein separater API-Endpunkt können sich völlig unterschiedlich verhalten, obwohl sie zur selben Domain gehören.

Warnschwellen an die Laufzeit koppeln

Die tragfähigste Regel lautet: Schwellen relativ zur Laufzeit setzen, nicht absolut. Let's Encrypt empfiehlt, ein kurzlebiges Zertifikat etwa bei halber Laufzeit zu erneuern und den ACME-Client mindestens einmal täglich laufen zu lassen (Let's Encrypt). Grundlage dafür ist die ACME Renewal Information (ARI): Die Zertifizierungsstelle teilt dem Client mit, wann er erneuern soll, und ARI-gestützte Erneuerungen sind bei Let's Encrypt von den Rate-Limits ausgenommen (Let's Encrypt). Seit September 2025 ist ARI als RFC 9773 standardisiert (IETF).

Für das Monitoring lässt sich dieselbe Logik als kleine Richtlinie fassen: pro Laufzeitklasse eine Warn- und eine Kritisch-Schwelle plus eine Regel, die eine überfällige Erneuerung erkennt. Das folgende Beispiel ist als Richtwert gedacht und sollte an die eigene Umgebung angepasst werden:

{
  "ssl_thresholds": [
    {
      "cert_lifetime_days": 90,
      "warn_days": 30,
      "critical_days": 7
    },
    {
      "cert_lifetime_days": 6,
      "warn_hours": 48,
      "critical_hours": 24
    }
  ],
  "renewal_watch": {
    "expected_renewal_every_hours": 60,
    "alert_if_cert_age_exceeds_hours": 84
  }
}

Die letzte Regel ist der Kern: Übersteigt das Alter des ausgelieferten Zertifikats 84 Stunden, obwohl die Automatik alle rund 60 Stunden erneuern sollte, ist etwas gerissen - und zwar mit genug Puffer, um vor dem Ablauf nach 160 Stunden einzugreifen. Bei XICTRAQ sind die Warnschwellen frei konfigurierbar (standardmäßig 14 Tage vor Ablauf, kritisch ab drei Tagen), sodass Sie sie für Kurzläufer auf Stunden herunterziehen können, statt mit einer für Langläufer gedachten Voreinstellung zu arbeiten.

Auch das Prüfintervall gehört zur Schwelle. Ein Zertifikat mit 160 Stunden Laufzeit nur einmal am Tag zu prüfen, lässt im schlimmsten Fall fast einen ganzen Tag verstreichen, bevor ein Bruch auffällt - bei einem Puffer von wenigen Tagen ist das viel. Als Faustregel sollte das Prüfintervall deutlich kürzer sein als der verbleibende Reaktionsspielraum. Für Kurzläufer bedeutet das mehrere Prüfungen pro Tag statt eines einzelnen nächtlichen Laufs, damit zwischen Bruch und Alarm nicht mehr Zeit vergeht als nötig.

Wenn die ACME-Automatik bricht: die Stunden-Falle

Weil zwischen letzter gültiger Erneuerung und Ausfall nur Stunden liegen, ist die stille Störung der Automatik das zentrale Risiko. Die häufigsten Ursachen für eine gestoppte Erneuerung:

• Der geplante Job wurde deaktiviert, verschoben oder nach einem Server-Umzug nicht wieder eingerichtet - der klassische stille Ausfall.
• Rate-Limits greifen, etwa wenn RSA- und ECDSA-Zertifikate parallel bezogen werden und sich die Anfragen verdoppeln; ARI-fähige Clients sind hiervon ausgenommen (Let's Encrypt).
• Die Domain-Validierung schlägt fehl, weil ein DNS-Eintrag geändert wurde, eine Firewall die HTTP-01-Challenge blockt oder ein Reverse-Proxy den Validierungspfad umleitet.
• Der ACME-Account ist abgelaufen oder die External Account Binding (EAB) wurde ungültig - der Client meldet sich, aber die Ausstellung wird abgelehnt.
• Betriebliche Randfälle wie eine volle Festplatte, eine verstellte Systemuhr oder ein abgelaufenes Client-Token verhindern das Schreiben oder Anfordern des neuen Zertifikats.

Der gemeinsame Nenner: Der Server selbst läuft weiter, nur die Erneuerung nicht. Ein rein lokaler Check auf demselben System kann denselben blinden Fleck haben. Deshalb gehört die Kontrolle nach außen - kombiniert mit klassischem Uptime-Monitoring, damit ein doch eingetretener Ausfall sofort auffällt. Dass fremde Abhängigkeiten dabei zur unterschätzten Fehlerquelle werden, zeigt der Beitrag zu Cloud-Ausfällen und Drittanbieter-Abhängigkeiten.

Wie teuer der blinde Fleck ist, belegen die Zahlen: Laut dem PKI- und Digital-Trust-Report 2024 verzeichneten 88 Prozent der Unternehmen ungeplante Ausfälle durch abgelaufene Zertifikate (Keyfactor), im Schnitt mehr als drei zertifikatsbedingte Ausfälle innerhalb von zwei Jahren (Keyfactor). Eine separate Erhebung sieht 40 Prozent der Unternehmen durch ablaufende SSL-Zertifikate ausfallgefährdet (CSC). Mit kürzeren Laufzeiten wächst die Zahl der Erneuerungen - und damit die Zahl der Gelegenheiten, an denen etwas schiefgehen kann.

Kurzläufer extern überwachen mit XICTRAQ

XICTRAQ prüft das tatsächlich ausgelieferte Zertifikat regelmäßig aus externer Sicht: Ablaufdatum, Zertifikatskette und Konfiguration, dazu die Erkennung schwacher Cipher Suites und Fehlkonfigurationen. Die Warnschwellen sind frei einstellbar und lassen sich so an die Laufzeit koppeln - für Langläufer in Tagen, für Kurzläufer in Stunden. Bei Let's-Encrypt-Zertifikaten erkennt das SSL-Zertifikat-Monitoring zusätzlich fehlgeschlagene Erneuerungen, also genau den stillen Automatik-Bruch, der bei Kurzläufern binnen Stunden zum Ausfall führt.

Weil ein einzelner Server mehrere Zertifikate ausliefern kann - für die Hauptdomain, für Subdomains, für IP-gebundene Dienste -, behandelt XICTRAQ jedes davon als eigenes Prüfobjekt mit eigener Historie. So fällt auch der Fall auf, in dem sich das Hauptzertifikat brav erneuert, ein Nebendienst mit eigener Automatik aber seit Tagen auf demselben alten Zertifikat sitzt und unbemerkt auf den Ablauf zuläuft.

Damit aus einer Messung ein Frühwarnsystem wird, kombiniert XICTRAQ die Zertifikatsprüfung mit Alerting über mehrere Kanäle, mit Domain- und DNS-Monitoring und mit Reports und Statusseiten, die den Erneuerungs-Verlauf über Wochen belegen. Wer parallel den Domain-Ablauf im Blick behält, sollte dabei die WHOIS-Ablösung berücksichtigen - der Beitrag zu RDAP statt WHOIS erklärt, warum. So sehen Sie nicht nur, dass ein Zertifikat noch gültig ist, sondern auch, ob es sich im erwarteten Takt erneuert.

Starten Sie mit dem kostenlosen Test und prüfen Sie, wie Ihre Zertifikate heute erneuert werden. Oder vereinbaren Sie eine persönliche Demo, um laufzeitgekoppelte Schwellen und die Erkennung fehlgeschlagener Erneuerungen in Aktion zu sehen.