SSL-Zertifikat Laufzeit 2026–2029: von 398 auf 47 Tage

Kurz gesagt: Seit dem 15. März 2026 darf ein öffentlich vertrauenswürdiges TLS-Zertifikat höchstens 200 Tage gültig sein. Am 15. März 2027 sinkt die Grenze auf 100 Tage, am 15. März 2029 auf 47 Tage. Der Zeitplan für die SSL-Zertifikat-Laufzeit stammt aus dem Ballot SC-081v3 des CA/Browser Forum, verabschiedet am 11. April 2025, und gilt für jede öffentliche Zertifizierungsstelle – kostenpflichtig oder kostenlos, DV, OV oder EV. Hängt irgendein Schritt Ihrer Verlängerung an einer Person, einer Kalendererinnerung oder einer E-Mail Ihrer CA, wird er auf diesem Weg irgendwann scheitern.

Fakten geprüft am 14. Oktober 2026 anhand des Ballots des CA/Browser Forum, der Zusammenfassung von DigiCert und der Ankündigungen von Let's Encrypt. Die Quellen stehen am Ende des Artikels.

SSL-Zertifikat-Laufzeit: der Zeitplan im Überblick

Die letzte Spalte ist das theoretische Minimum – Verlängerung am letzten Tag. So arbeitet in der Praxis niemand. Mit einer üblichen Sicherheitsreserve heißt die 47-Tage-Stufe, dass Sie etwa jeden Monat verlängern: rund 12 Verlängerungen pro Zertifikat und Jahr.

Eine weitere Änderung gilt seit dem 15. März 2026: Die Organisationsangaben hinter OV- und EV-Zertifikaten (die „Subject Identity Information“) dürfen jetzt 398 statt 825 Tage wiederverwendet werden.

Zwei Zahlen haben sich geändert – die zweite ist wichtiger

Die maximale Gültigkeit bestimmt, wie oft Sie ein neues Zertifikat installieren. Die Wiederverwendung der Domain-Validierung bestimmt, wie oft die CA erneut prüfen muss, dass Sie die Domain kontrollieren – per DNS-Eintrag, HTTP-Challenge-Datei oder E-Mail.

Heute lässt sich eine erfolgreiche Validierung monatelang wiederverwenden, eine wacklige Validierung bleibt also lange unbemerkt. Ab 2029 beträgt dieses Fenster 10 Tage, praktisch jede Verlängerung löst damit eine neue Validierung aus. Ein Schritt, der bisher einmal im Jahr lief, während jemand danebensaß, läuft künftig jeden Monat unbeaufsichtigt. Ist das API-Token Ihres DNS-Anbieters abgelaufen oder blockiert eine Firewall-Regel die Challenge, merken Sie es erst, wenn das Zertifikat abläuft.

Und Let's Encrypt? Auch dort geht es auf 45 Tage

Let's-Encrypt-Zertifikate laufen schon heute 90 Tage, also deutlich innerhalb der neuen Grenzen. Trotzdem verkürzt auch Let's Encrypt die Laufzeit:

• 13. Mai 2026 – das optionale Profil tlsserver stellt seitdem Zertifikate mit 45 Tagen Laufzeit aus.
• 10. Februar 2027 – das Standardprofil classic wechselt auf 64-Tage-Zertifikate und eine Wiederverwendungsfrist für Autorisierungen von 10 Tagen.
• 16. Februar 2028 – das Profil classic wechselt auf 45-Tage-Zertifikate mit einer Wiederverwendungsfrist für Autorisierungen von 7 Stunden.

Let's Encrypt empfiehlt, den Client per ACME Renewal Information (ARI) entscheiden zu lassen oder bei etwa zwei Dritteln der Laufzeit zu verlängern. Dort heißt es auch unmissverständlich, dass ein fest eingestelltes Intervall von 60 Tagen nicht mehr ausreichen wird. Verlängert Ihr Setup nach festem Kalender statt nach der verbleibenden Laufzeit, hat es selbst ein Ablaufdatum.

Dazu kommt eine zweite, leisere Änderung. Am 4. Juni 2025 hat Let's Encrypt den Versand von Ablauf-Warnmails eingestellt. Das Sicherheitsnetz, auf das sich viele Teams verlassen haben – „wenn die Verlängerung scheitert, schickt mir Let's Encrypt eine Mail“ –, gibt es nicht mehr.

Wo Verlängerungen tatsächlich scheitern

Abgelaufene Zertifikate entstehen selten, weil niemand verlängern wollte. Sie entstehen durch Verlängerungen, die nur halb funktioniert haben:

1. Verlängert, aber nie ausgerollt. Das neue Zertifikat liegt auf der Platte, der Webserver wurde aber nie neu geladen und liefert weiter das alte aus, bis es abläuft.
2. Kopien an anderer Stelle. Das Zertifikat wurde auf dem Origin-Server verlängert, während CDN, Load Balancer, Mailserver oder API-Gateway noch eine hochgeladene Kopie vorhalten.
3. Validierung, die nur einmal funktioniert hat. Das API-Token beim DNS-Anbieter ist abgelaufen, DNS ist zu einem anderen Anbieter umgezogen, ein CAA-Eintrag sperrt die CA oder eine Firewall blockiert die HTTP-Challenge.
4. Manuelle Zertifikate. Ein gekauftes OV- oder EV-Zertifikat, von Hand auf einer Appliance oder in einem Hosting-Panel eingespielt – etwa in Plesk, cPanel oder der Verwaltungsoberfläche Ihres Hosters. Bei 47 Tagen sind das bis zu einem Dutzend manuelle Vorgänge pro Zertifikat und Jahr.
5. Der verschwundene Verlängerungsjob. Ein Cron-Eintrag oder systemd-Timer, der bei einem Serverumzug verloren ging, oder ein Container, der ohne ihn neu gebaut wurde.

Das gemeinsame Muster: Das Verlängerungstool meldet Erfolg oder gar nichts, und niemand prüft, was bei den Besuchern tatsächlich ankommt.

SSL-Zertifikat-Ablauf überwachen: prüfen, was das Internet sieht

Eine externe Zertifikatsprüfung verbindet sich wie ein Browser mit Ihrem Host und liest das Zertifikat, das tatsächlich ausgeliefert wird. Warum etwas schiefgegangen ist, spielt für sie keine Rolle – deshalb erkennt sie alle fünf Fehler oben. Eine sinnvolle Prüfung achtet auf:

• wie viele Tage das ausgelieferte Zertifikat noch gültig ist;
• ob es den geprüften Hostnamen abdeckt;
• ob die Zertifikatskette zu einem vertrauenswürdigen Root führt;
• ob es selbstsigniert, noch nicht gültig oder mit einem schwachen Hash signiert ist;
• wann ein neues Zertifikat auftaucht – die Bestätigung, dass eine Verlängerung in Produktion angekommen ist.

Alarmschwellen müssen sich nach der Laufzeit des Zertifikats richten. Eine Warnung „noch 30 Tage“ ist bei einem Jahreszertifikat nützlich, bei einem 47-Tage-Zertifikat würde sie aber etwa zwei Wochen nach der Installation auslösen, obwohl Ihre Automatisierung einwandfrei arbeitet. Feste Schwellen gewöhnen Menschen daran, Alarme zu ignorieren – und ein ignorierter Alarm ist schlimmer als gar keiner.

Wie AlertSleep mit kürzeren Zertifikaten umgeht

In AlertSleep ist die Zertifikatsüberwachung Teil jedes HTTPS-Monitors und kein separates Produkt. Für jeden Monitor gilt:

• das Zertifikat wird alle 6 Stunden geprüft;
• Warnungen gehen 30, 14, 7, 3 und 1 Tag vor Ablauf raus – eine Schwelle entfällt aber, wenn sie ein Drittel der Zertifikatslaufzeit oder mehr ausmacht, sodass ein frisch verlängertes kurzes Zertifikat nie einen Alarm auslöst;
• Sie werden alarmiert, wenn das Zertifikat abgelaufen oder noch nicht gültig ist, die Domain nicht abdeckt, selbstsigniert ist, einen schwachen Signatur-Hash verwendet, eine defekte Kette hat oder ganz fehlt;
• Sie erfahren, wenn ein neues Zertifikat ausgeliefert wird, und sehen so, dass die Verlängerung in Produktion angekommen ist, statt es nur anzunehmen.

In der Praxis ergeben sich daraus diese Schwellen:

Alarme kommen per E-Mail und im Dashboard an, außerdem über Slack, Telegram, Microsoft Teams und die anderen Integrationen, für die Sie Zertifikatsbenachrichtigungen aktivieren.

Eine Domain sofort prüfen: Geben Sie sie in den kostenlosen SSL-Checker ein. Hinterlassen Sie neben dem Ergebnis Ihre E-Mail-Adresse, dann behalten wir dieses Zertifikat für Sie im Blick und warnen Sie vor dem Ablauf. Alles Weitere steht auf der Seite SSL-Monitoring.

Checkliste bis zum 15. März 2027

1. Erfassen Sie jeden öffentlichen Hostnamen mit Zertifikat – Websites, APIs, Mailserver, CDN-Endpunkte, Statusseiten. Certificate-Transparency-Logs (zum Beispiel crt.sh) zeigen jedes Zertifikat, das je für Ihre Domain ausgestellt wurde, auch die vergessenen.
2. Notieren Sie für jeden Hostnamen, was das Zertifikat verlängert, und ob der Ablauf durchgehend automatisiert ist – einschließlich Reload oder Upload ins CDN.
3. Ersetzen Sie Verlängerungen im festen Intervall durch eine Verlängerung nach verbleibender Laufzeit oder durch ARI, wo Ihr ACME-Client das unterstützt.
4. Testen Sie den Validierungsweg: Zugangsdaten für die DNS-API und deren Ablaufdatum, CAA-Einträge und Firewall-Regeln für HTTP-Challenges.
5. Spüren Sie die manuellen Zertifikate auf – auf Appliances, in Hosting-Panels wie Plesk oder cPanel und in hochgeladenen CDN-Konfigurationen – und planen Sie, sie zu automatisieren oder auf verwaltete Zertifikate umzustellen.
6. Richten Sie für jeden Hostnamen aus Schritt 1 eine externe Prüfung ein, damit sich der nächste Fehler als Alarm meldet und nicht als Browserwarnung.

Hintergründe zur Ablaufüberwachung selbst – warum Zertifikate ablaufen und was ein abgelaufenes Zertifikat mit einer Website anrichtet – finden Sie im Artikel SSL-Zertifikat überwachen — Ablauf erkennen und Ausfälle verhindern (2026).

Häufige Fragen

Hören vorhandene Zertifikate am 15. März 2027 auf zu funktionieren?

Nein. Die Grenzen gelten für Zertifikate, die ab dem jeweiligen Stichtag ausgestellt werden. Ein SSL-Zertifikat mit 200 Tagen Laufzeit, ausgestellt am 1. März 2027, bleibt bis zu seinem eigenen Ablaufdatum gültig.

Gilt das auch für interne oder private Zertifikate?

Nein. Die Regeln betreffen öffentlich vertrauenswürdige TLS-Zertifikate, die nach den Baseline Requirements des CA/Browser Forum ausgestellt werden. Eine private CA im eigenen Unternehmen folgt Ihren eigenen Richtlinien.

Lässt sich die Grenze mit einem OV- oder EV-Zertifikat umgehen?

Nein. Die maximale Gültigkeit ist für DV-, OV- und EV-Zertifikate gleich. Gekaufte Zertifikate werden eher von Hand verlängert und machen deshalb meist als Erste Ärger.

Warum wird die SSL-Zertifikat-Laufzeit immer kürzer?

Eine kürzere Laufzeit begrenzt, wie lange ein kompromittiertes oder fälschlich ausgestelltes Zertifikat missbraucht werden kann, und verringert die Abhängigkeit von Sperrprüfungen, die Browser nur unzuverlässig durchführen. Außerdem erzwingt sie Automatisierung und beseitigt damit den manuellen Schritt, an dem die meisten Verlängerungen scheitern.

Wie oft muss ich ein SSL-Zertifikat mit 47 Tagen Laufzeit pro Jahr verlängern?

Mindestens achtmal pro Zertifikat, mit einer vernünftigen Sicherheitsreserve etwa zwölfmal. Voll automatisiert ist das nicht mehr Aufwand als eine einzige Verlängerung – ohne Automatisierung ist es eine monatliche Pflichtaufgabe pro Hostname.

Quellen

• CA/Browser Forum – Ballot SC-081v3: Zeitplan für kürzere Gültigkeits- und Wiederverwendungsfristen
• DigiCert – TLS-Zertifikatslaufzeiten werden offiziell auf 47 Tage verkürzt
• Let's Encrypt – Verkürzung der Zertifikatslaufzeit auf 45 Tage
• Let's Encrypt – Ende der Benachrichtigungsmails zum Zertifikatsablauf