SSL und HTTPSRatgeber
Laufzeit von SSL-Zertifikaten: die Stufen bis 47 Tage
Öffentlich vertrauenswürdige SSL-Zertifikate, die seit dem 15.03.2026 ausgestellt werden, gelten höchstens 200 Tage. Ab dem 15.03.2027 sind es 100 Tage, ab dem 15.03.2029 nur noch 47 Tage. Das hat das CA/Browser Forum 2025 beschlossen, die Erneuerung sollte deshalb automatisch laufen.

Jedes Zertifikat hat ein Ablaufdatum. Bis dahin vertraut ihm der Browser, danach zeigt er eine Warnung, und Besucher kommen nur noch mit Mühe auf die Website. Wie lange ein Zertifikat höchstens gelten darf, bestimmen die Zertifizierungsstellen nicht allein. Die Regeln legt das CA/Browser Forum fest, in dem Zertifizierungsstellen und Browserhersteller zusammenarbeiten. 2025 hat es beschlossen, die Höchstlaufzeit in drei Schritten von 398 auf 47 Tage zu senken [2]. Die erste Stufe gilt seit dem 15.03.2026.
Die Stichtage bis 2029
Maßgeblich ist das Datum, an dem ein Zertifikat ausgestellt wird. Ein Zertifikat, das vor einem Stichtag ausgestellt wurde, behält seine Laufzeit. Die Baseline Requirements des CA/Browser Forum nennen in Abschnitt 6.3.2 diese Grenzen [1]:

| Ausgestellt | Höchstlaufzeit |
|---|---|
| vor dem 15.03.2026 | 398 Tage (empfohlen höchstens 397) |
| ab dem 15.03.2026 | 200 Tage |
| ab dem 15.03.2027 | 100 Tage |
| ab dem 15.03.2029 | 47 Tage |
Ein Zertifikat, das am 01.11.2026 ausgestellt wird, gilt also höchstens bis zum 20.05.2027. Jahreszertifikate, wie sie viele Anbieter früher verkauft haben, gibt es seit März 2026 nicht mehr. Wer bei einem Anbieter ein Paket über mehrere Jahre bezahlt, bekommt in dieser Zeit mehrere Zertifikate nacheinander, weil jedes einzelne die Grenze einhalten muss [1].
Wie es zu den 47 Tagen kam
Die Laufzeiten sind über die Jahre immer kürzer geworden. Den letzten großen Schritt vor 2026 ging Apple allein: Seit dem 01.09.2020 lehnen Apple-Geräte Zertifikate ab, die nach diesem Tag ausgestellt wurden und länger als 398 Tage gelten. Apple empfahl höchstens 397 Tage und schrieb, dass Verbindungen zu Servern mit solchen Zertifikaten scheitern [3]. Die 398 Tage wurden danach zur allgemeinen Grenze in den Baseline Requirements [1]. Chrome hat für dieses Problem eine eigene Fehlermeldung, ERR_CERT_VALIDITY_TOO_LONG [9].
Den Zeitplan bis 2029 hat das CA/Browser Forum mit dem Beschluss SC-081v3 im April 2025 festgelegt. Bei den Zertifizierungsstellen stimmten 25 dafür, keine dagegen, fünf enthielten sich. Alle vier abstimmenden Browserhersteller stimmten zu [2]. Let's Encrypt nennt als Gründe, dass kürzere Laufzeiten den Schaden bei einem gestohlenen Schlüssel begrenzen und den Widerruf von Zertifikaten wirksamer machen [4].
Auch die Domainprüfung gilt kürzer
Bevor eine Zertifizierungsstelle ein Zertifikat ausstellt, prüft sie, ob du die Domain kontrollierst. Das Ergebnis darf sie für eine gewisse Zeit wiederverwenden, sodass bei einer Erneuerung keine neue Prüfung nötig ist. Auch diese Frist schrumpft [1]:
| Ausgestellt | Domainprüfung wiederverwendbar |
|---|---|
| vor dem 15.03.2026 | 398 Tage |
| ab dem 15.03.2026 | 200 Tage |
| ab dem 15.03.2027 | 100 Tage |
| ab dem 15.03.2029 | 10 Tage |
Ab 2029 muss die Zertifizierungsstelle die Kontrolle über die Domain also fast bei jeder Erneuerung neu prüfen. Wer die Bestätigung über einen TXT-Eintrag im DNS führt und diesen Eintrag von Hand setzt, muss das dann bei jedem neuen Zertifikat tun. Ein neues Verfahren soll das erleichtern: Bei der Bestätigung über einen dauerhaften TXT-Eintrag (in den Baseline Requirements als Persistent DCV TXT Record geführt) bleibt der Eintrag stehen und muss bei der Erneuerung nicht geändert werden [1, 4]. Let's Encrypt nennt dieses Verfahren DNS-PERSIST-01 und erwartet es im Jahr 2026 [4].
Let's Encrypt: von 90 auf 45 Tage
Let's Encrypt stellt seine Standardzertifikate seit Jahren mit 90 Tagen Laufzeit aus. Das liegt unter allen Grenzen bis 2027. Trotzdem stellt die Organisation schrittweise auf 45 Tage um und verkürzt zugleich, wie lange eine Domainprüfung wiederverwendet wird [4]:

| Datum | Änderung |
|---|---|
| 13.05.2026 | Profil tlsserver auf Wunsch mit 45 Tagen, zum Testen |
| 10.02.2027 | Standardprofil classic: 64 Tage, Domainprüfung 10 Tage wiederverwendbar |
| 16.02.2028 | Standardprofil classic: 45 Tage, Domainprüfung 7 Stunden wiederverwendbar |
Die Änderungen erscheinen jeweils etwa einen Monat vorher in der Testumgebung und gelten für neue Zertifikate, also ab der nächsten Erneuerung nach dem Stichtag [4]. Daneben gibt es auf Wunsch Zertifikate mit sechs Tagen Laufzeit. Let's Encrypt empfiehlt, 90-Tage-Zertifikate alle 60 Tage und Sechs-Tage-Zertifikate alle drei Tage zu erneuern [5].
Was du jetzt umstellen solltest
Mit 200 Tagen kommt man noch mit zwei Erneuerungen im Jahr aus, mit 47 Tagen sind es acht oder mehr. Von Hand ist das kaum zu schaffen. Let's Encrypt rät ausdrücklich davon ab, Zertifikate manuell zu erneuern [4]. Prüfe deshalb diese Punkte:

- Erneuert dein Hoster oder dein Server das Zertifikat automatisch? Die Plesk-Erweiterung SSL It! erneuert kostenlose Zertifikate von Let's Encrypt zum Beispiel 30 Tage vor Ablauf selbst [8]. Mehr dazu unter Plesk: Domains, Subdomains und Zertifikate verwalten.
- Ist der Zeitpunkt der Erneuerung fest eingestellt? Ein festes Intervall von 60 Tagen reicht für 45-Tage-Zertifikate nicht mehr. Let's Encrypt hält eine Erneuerung nach etwa zwei Dritteln der Laufzeit für angemessen [4].
- Unterstützt dein ACME-Programm ARI? Mit dieser Erweiterung nach RFC 9773 schlägt die Zertifizierungsstelle selbst ein Zeitfenster für die Erneuerung vor, und das Programm wählt einen Zeitpunkt darin [6]. Let's Encrypt empfiehlt, ARI zu nutzen [4].
- Wird der Ablauf überwacht? Let's Encrypt hat zum 04.06.2025 die Erinnerungs-E-Mails vor dem Ablauf eingestellt und verweist auf externe Überwachungsdienste [7]. Die Organisation empfiehlt, Erneuerungen zu überwachen, damit ein Ausfall auffällt [4].
Wie die DNS-Bestätigung bei Wildcard-Zertifikaten funktioniert, steht unter SSL für Subdomains: Wildcard oder einzelne Zertifikate. Die Einrichtung einer automatischen Erneuerung beschreibt Let's Encrypt: kostenlose Zertifikate einrichten.
Kurze Laufzeit statt Widerruf
Ein Zertifikat lässt sich vor seinem Ablauf widerrufen, etwa wenn der private Schlüssel gestohlen wurde. Die Zertifizierungsstelle muss das in solchen Fällen innerhalb von 24 Stunden tun [1]. Ob ein Browser den Widerruf auch mitbekommt, hängt davon ab, wie er Sperrlisten abfragt. Je kürzer ein Zertifikat gilt, desto kürzer ist die Zeit, in der ein gestohlener Schlüssel missbraucht werden kann, auch wenn der Widerruf nicht ankommt. Das meint Let's Encrypt, wenn es von einem begrenzten Schaden spricht [4].
Die Baseline Requirements kennen deshalb auch kurzlebige Zertifikate. Seit dem 15.03.2026 zählt ein Zertifikat als kurzlebig, wenn es höchstens sieben Tage gilt, vorher lag die Grenze bei zehn Tagen [1]. Die Sechs-Tage-Zertifikate von Let's Encrypt liegen darunter [5].
Was ein abgelaufenes Zertifikat auslöst
Läuft ein Zertifikat ab, prüft der Browser das anhand der Uhr des eigenen Geräts. Chrome meldet dann den Fehler ERR_CERT_DATE_INVALID, der laut Beschreibung im Quelltext bedeutet, dass das Zertifikat nach der Uhr des Browsers noch nicht gültig oder schon abgelaufen ist [9]. Besucher sehen eine ganzseitige Warnung. Hat deine Website HSTS aktiviert, dürfen Browser die Warnung nach RFC 6797 nicht übergehen lassen und müssen die Verbindung abbrechen [10]. Die Website ist dann für alle Besucher nicht erreichbar, bis ein neues Zertifikat installiert ist. Was HSTS ist, steht im Glossar unter HSTS.
Gekaufte Zertifikate und Geräte ohne Automatik
Auch gekaufte OV- und EV-Zertifikate fallen unter die Grenzen [1]. Wer sie bisher einmal im Jahr von Hand getauscht hat, muss das ab dem 15.03.2027 etwa viermal im Jahr tun und ab 2029 noch öfter. Schwieriger ist es bei Geräten, die ihr Zertifikat nur über eine Weboberfläche annehmen, etwa ältere Router, Drucker oder NAS-Systeme im Firmennetz. Für Geräte, die nur im eigenen Netz erreichbar sind, kann eine interne Zertifizierungsstelle die Lösung sein, deren Stammzertifikat du auf den eigenen Rechnern hinterlegst. Für öffentlich erreichbare Dienste gibt es diesen Ausweg nicht.
Ablaufdatum prüfen
Das Ablaufdatum steht im Zertifikat im Feld notAfter. Im Browser siehst du es, wenn du auf das Symbol links in der Adresszeile klickst und die Zertifikatsangaben öffnest. Auf einem Rechner mit OpenSSL zeigt der Befehl "openssl s_client -connect beispiel.de:443 -servername beispiel.de | openssl x509 -noout -dates" Beginn und Ende des Zertifikats, das der Server gerade ausliefert. Das ist praktisch nach einer Erneuerung: Steht dort noch das alte Ablaufdatum, liegt das neue Zertifikat oft schon auf dem Server, ist aber noch nicht geladen. Dann hilft ein Neustart oder ein Neuladen der Konfiguration. Mit dem SSL-Check kannst du die zuletzt ausgestellten Zertifikate einer Domain mit Ausstellungs- und Ablaufdatum ansehen. Ist ein Zertifikat abgelaufen, meldet der Browser einen Fehler. Was du dann tun kannst, steht unter Zertifikatsfehler im Browser verstehen und beheben. Grundlagen zum Aufbau eines Zertifikats erklärt SSL-Zertifikat: was es ist und welche Arten es gibt.
- Organisation Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, Version 2.3.1, Abschnitte 1.2.2, 3.2.2.4.22, 4.2.1, 4.9.1.1 und 6.3.2. CA/Browser Forum. Stand 04.10.2026. abgerufen am 29.10.2026
- Organisation Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods. CA/Browser Forum. Stand 11.04.2025. abgerufen am 29.10.2026
- Organisation About upcoming limits on trusted certificates. Apple. Stand 21.08.2023. abgerufen am 29.10.2026
- Organisation Decreasing Certificate Lifetimes to 45 Days. Let's Encrypt. Stand 02.12.2025. abgerufen am 29.10.2026
- Organisation FAQ. Let's Encrypt. Stand 28.04.2025. abgerufen am 29.10.2026
- Gesetz RFC 9773: ACME Renewal Information (ARI) Extension. IETF. Stand Juni 2025. abgerufen am 29.10.2026
- Organisation Ending Support for Expiration Notification Emails. Let's Encrypt. Stand 22.01.2025. abgerufen am 29.10.2026
- Organisation Securing Connections with the SSL It! Extension. Plesk. Stand ohne Datum. abgerufen am 29.10.2026
- Organisation net_error_list.h (Fehlercodes des Chromium-Netzwerkstapels). The Chromium Projects. Stand laufend. abgerufen am 29.10.2026
- Gesetz RFC 6797: HTTP Strict Transport Security (HSTS), Abschnitt 8.4. IETF. Stand November 2012. abgerufen am 29.10.2026
Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.
Weitere Artikel
SSLSSL-ZertifikatWas ein SSL-Zertifikat enthält, wie der Browser es prüft, worin sich DV, OV und EV unterscheiden und welche TLS-Versionen …
SSLLet's EncryptWie Let's Encrypt deine Domain prüft, wie du Zertifikate beim Hoster oder mit Certbot einrichtest und was die kürzeren …
WerkzeugeSSL-CheckDer SSL-Check zeigt die letzten 20 Zertifikate einer Domain aus den Certificate-Transparency-Logs mit Aussteller, Laufzeit …