Kürzere Zertifikatslaufzeiten: warum 47 Tage kommen und Automatisierung zur Pflicht wird

Problem

Wer einen Webserver, eine API (Programmierschnittstelle) oder einen Mailserver mit HTTPS (verschlüsseltes Web-Protokoll) betreibt, braucht ein TLS-Zertifikat (digitaler Ausweis, der die Identität einer Domain bestätigt und die Verschlüsselung absichert). Bisher galt: einmal im Jahr erneuern, oft von Hand, oft per Kalendereintrag. Genau dieses Modell fällt jetzt weg.

Das CA/Browser Forum - das Gremium aus Zertifizierungsstellen (CAs, Certificate Authorities) und Browser-Herstellern, das die Spielregeln für öffentliche Zertifikate festlegt - hat 2025 beschlossen, die maximale Gültigkeitsdauer drastisch zu verkürzen. Am Ende stehen 47 Tage. Wer darauf nicht vorbereitet ist, riskiert regelmäßige Ausfälle durch abgelaufene Zertifikate. Und ein abgelaufenes Zertifikat bedeutet: Der Browser zeigt eine rote Warnseite, Kunden kommen nicht mehr durch, APIs brechen ab.

Für wen ist das? Für alle, die TLS-Zertifikate für Webserver, APIs oder Mailserver betreiben.

Kurze Antwort

Die maximale Laufzeit öffentlich vertrauenswürdiger TLS-Zertifikate sinkt stufenweise, bis manuelle Erneuerung endgültig unpraktikabel wird. Der einzige tragfähige Weg ist Automatisierung.

• ab März 2026: maximal 200 Tage
• ab März 2027: maximal 100 Tage
• ab März 2029: maximal 47 Tage
• die erlaubte Wiederverwendung einer Domain-Prüfung (DCV, Domain Control Validation - der Nachweis, dass Sie die Domain kontrollieren) sinkt bis 2029 auf 10 Tage
• Konsequenz: Automatisierung per ACME (Automated Certificate Management Environment - ein Protokoll, das Ausstellung und Erneuerung ohne Menschen am Steuer erledigt)

Tiefgang

Warum kürzere Laufzeiten sicherer sind

Ein Zertifikat bindet einen öffentlichen Schlüssel an eine Domain. Wird der zugehörige private Schlüssel gestohlen - etwa durch eine Server-Lücke, ein geleaktes Backup oder einen Innentäter - kann ein Angreifer sich als Ihre Domain ausgeben und Datenverkehr entschlüsseln oder manipulieren. Die entscheidende Frage ist: Wie lange bleibt ein gestohlenes Zertifikat brauchbar?

Bei einem Jahr Laufzeit hat ein Angreifer im schlimmsten Fall fast 12 Monate Zeit. Bei 47 Tagen schrumpft dieses Risikofenster auf wenige Wochen. Das Zertifikat läuft von selbst ab, der Schaden begrenzt sich selbst.

Der zweite Grund ist subtiler und betrifft die Sperrung. Theoretisch kann eine CA ein kompromittiertes Zertifikat vorzeitig für ungültig erklären. In der Praxis funktioniert das schlecht. Die klassischen Mechanismen dafür sind CRL (Certificate Revocation List - eine Liste gesperrter Zertifikate) und OCSP (Online Certificate Status Protocol - eine Echtzeit-Abfrage des Sperrstatus). Beide haben sich als unzuverlässig erwiesen: CRLs werden riesig und veraltet, OCSP-Abfragen verraten das Surfverhalten der Nutzer an die CA und werden von Browsern bei Nichterreichbarkeit oft einfach ignoriert (sogenanntes soft-fail). Let's Encrypt hat OCSP daher 2025 abgeschaltet.

Kurze Laufzeiten lösen dieses Dilemma elegant: Wenn ein Zertifikat ohnehin nur 47 Tage lebt, braucht man die wacklige Sperr-Infrastruktur kaum noch. Ablauf ersetzt Sperrung. Das ist robuster, weil Ablauf nicht von einer erreichbaren Online-Komponente abhängt.

Warum manuelle Erneuerung endgültig stirbt

Rechnen Sie nach. Bei 47 Tagen Laufzeit erneuern Sie sinnvollerweise nach etwa zwei Dritteln der Zeit, also alle rund 30 Tage - und das pro Zertifikat. Ein mittelständisches Unternehmen hat schnell Dutzende bis Hunderte Zertifikate: Hauptdomain, Subdomains, interne Dienste, Loadbalancer, Mailserver. Manuell hieße das: jede Woche mehrere Erneuerungen, jede mit Domain-Prüfung, Schlüsselerzeugung, Installation und Neustart des Dienstes. Eine einzige vergessene Erneuerung produziert einen Ausfall.

Kein Team hält das von Hand fehlerfrei durch. Der jährliche Kalendereintrag war schon bei 398 Tagen riskant - bei 47 Tagen ist er chancenlos.

Wie ACME das löst

ACME automatisiert den kompletten Ablauf. Ein Client auf Ihrem Server kommuniziert mit der CA und erledigt vollautomatisch:

1. Domain-Prüfung (DCV): Der Client beweist die Kontrolle über die Domain, etwa indem er eine Datei unter einem bestimmten Pfad ablegt (HTTP-01-Challenge) oder einen DNS-Eintrag setzt (DNS-01-Challenge - nötig für Wildcard-Zertifikate, die mit *.beispiel.de ganze Subdomain-Bäume abdecken).
2. Ausstellung: Die CA stellt das Zertifikat aus.
3. Installation und Erneuerung: Der Client legt die Dateien ab, lädt den Dienst neu und wiederholt das automatisch lange vor Ablauf.

Verbreitete Werkzeuge:

• certbot - der Referenz-Client von der Electronic Frontier Foundation, gut für Apache und nginx.
• acme.sh - ein schlankes Shell-Skript ohne schwere Abhängigkeiten, sehr flexibel bei DNS-Anbietern.
• Caddy - ein Webserver, der ACME eingebaut hat und Zertifikate ohne jede Zusatzkonfiguration besorgt und erneuert.

Meist genügt eine einmalige Einrichtung; danach läuft die Erneuerung still im Hintergrund. Die treibende Kraft hinter kostenlosen, automatisierten Zertifikaten ist Let's Encrypt, das ACME breit etabliert hat. Das Protokoll selbst ist als RFC 8555 offen standardisiert.

Abgelehnte Alternativen und Mythen

"Ich kaufe einfach ein teures Zertifikat mit langer Laufzeit." Das gibt es für öffentlich vertrauenswürdige Zertifikate nicht mehr. Die Obergrenzen gelten für alle öffentlichen CAs, unabhängig vom Preis. Teure Zertifikate laufen genauso schnell ab wie kostenlose.

"EV-Zertifikate (Extended Validation, mit aufwendiger Organisationsprüfung) sind ausgenommen." Nein. Die Laufzeitgrenzen gelten für alle Typen. EV bezieht sich auf die Prüftiefe, nicht auf die Gültigkeitsdauer.

"Kurze Laufzeiten sind unsicher, weil ständig neue Schlüssel im Umlauf sind." Das Gegenteil stimmt. Häufigere Rotation begrenzt den Schaden eines Schlüsseldiebstahls und zwingt zu sauberer Automatisierung. Statische Jahres-Zertifikate sind das größere Risiko.

"Sperrlisten reichen doch, falls etwas passiert." CRL und OCSP haben in der Praxis zu oft versagt - zu langsam, zu löchrig, datenschutzproblematisch. Kurze Laufzeit ist die verlässlichere Schadensbegrenzung.

"ACME ist nur für Webserver." ACME funktioniert für alles, was TLS spricht: Mailserver, APIs, interne Dienste. Für interne PKI (Public Key Infrastructure - die Gesamtheit aus CAs, Schlüsseln und Regeln) können Sie eine eigene ACME-fähige CA betreiben.

Was Sie jetzt tun sollten

• Inventar erstellen: Verschaffen Sie sich einen vollständigen Überblick aller Zertifikate - inklusive der vergessenen auf Testsystemen, Appliances und alten Loadbalancern. Was Sie nicht kennen, erneuern Sie nicht. Ein guter Startpunkt sind die öffentlichen Certificate-Transparency-Logs (öffentliche, manipulationssichere Verzeichnisse aller ausgestellten Zertifikate); dazu mehr in Certificate Transparency als Frühwarnsystem.
• ACME einführen: Stellen Sie Ihre Dienste auf einen ACME-Client (certbot, acme.sh oder Caddy) um, sodass Ausstellung und Erneuerung ohne manuellen Eingriff laufen.
• Kurzlebige Zertifikate jetzt testen: Stellen Sie Ihre Pipeline bereits heute auf 47 Tage oder kürzer ein, statt auf die maximale Laufzeit. So entdecken Sie Erneuerungsprobleme im Alltag und nicht erst 2029.
• Altsysteme ohne ACME identifizieren: Listen Sie Appliances und Software auf, die ACME nicht beherrschen, und planen Sie Übergangslösung oder Austausch, bevor die kurzen Laufzeiten greifen.
• Monitoring auf Ablauf: Verlassen Sie sich nicht blind auf die Automatik. Überwachen Sie aktiv das Ablaufdatum jedes Zertifikats und schlagen Sie Alarm, falls eine Erneuerung ausbleibt - zum Beispiel, wenn ein DNS-Anbieter-Token abgelaufen ist.

Wie Dernium hier hilft

Für Dernium ist das keine kommende Umstellung, sondern gelebte Praxis. Unsere Dienste laufen auf einer Infrastruktur-Baseline mit automatisierten, kurzlebigen Zertifikaten - Erneuerung und Rotation passieren ohne manuelle Eingriffe. Der angekündigte Wechsel auf 47 Tage ändert an unserem Betrieb wenig, weil die Automatisierung ohnehin der Normalfall ist.

Wenn Sie eigene Domains und Zertifikate überwachen wollen, kann Dernium Watch den Ablauf von Zertifikaten im Blick behalten und zusätzlich Certificate-Transparency-Logs mitbeobachten - also melden, wenn für Ihre Domain überraschend ein neues Zertifikat ausgestellt wird oder wenn eine Erneuerung ausbleibt. Das ersetzt nicht Ihre Automatisierung, sondern ist das Sicherheitsnetz darunter. Den Zustand einer einzelnen Domain können Sie sofort selbst prüfen: Unter den kostenlosen Webtools liegen ein Validator für die TLS-Zertifikatskette und eine Cipher-Suite-Analyse, beide ohne Anmeldung.

Die Verkürzung der Laufzeiten ist nur eine von mehreren Entwicklungen, die TLS gerade umbauen. Eine zweite, langfristige Baustelle ist die Umstellung auf quantensichere Verfahren - dazu Post-Quantum-TLS heute.

Offene Punkte

• Die genauen Stichtage und Höchstwerte können sich verschieben; das CA/Browser Forum aktualisiert die Vorgaben fortlaufend. Prüfen Sie vor wichtigen Entscheidungen die Primärquelle.
• Nicht jede Appliance oder Altsoftware unterstützt ACME. Für solche Fälle brauchen Sie Übergangslösungen oder einen Austauschplan, bevor die kurzen Laufzeiten greifen.
• DNS-basierte Domain-Prüfung hängt an API-Zugängen Ihres DNS-Anbieters. Deren Ausfall oder abgelaufene Tokens sind eine eigene Fehlerquelle, die Sie überwachen müssen.

Häufige Fragen

Muss ich jetzt sofort auf 47 Tage umstellen?

Nicht von heute auf morgen, aber Sie sollten nicht warten. Die Höchstlaufzeit sinkt stufenweise: 200 Tage ab März 2026, 100 Tage ab März 2027, 47 Tage ab März 2029. Der entscheidende Schritt ist nicht das Datum, sondern die Automatisierung. Wer heute schon einen ACME-Client einrichtet und testweise kurze Laufzeiten fährt, hat 2029 keinen Stress.

Sind teure oder EV-Zertifikate von den kurzen Laufzeiten ausgenommen?

Nein. Die Obergrenzen gelten für alle öffentlich vertrauenswürdigen Zertifikate, unabhängig von Preis und Typ. EV (Extended Validation) betrifft nur die Tiefe der Identitätsprüfung, nicht die Gültigkeitsdauer. Ein teures EV-Zertifikat läuft genauso schnell ab wie ein kostenloses.

Was passiert, wenn die automatische Erneuerung einmal fehlschlägt?

Dann läuft das Zertifikat ab und der Dienst wird im Browser als unsicher angezeigt - Kunden kommen nicht mehr durch, APIs brechen ab. Genau deshalb sollten Sie sich nicht blind auf die Automatik verlassen, sondern das Ablaufdatum jedes Zertifikats getrennt überwachen. Häufige Ursache ist ein abgelaufenes API-Token beim DNS-Anbieter, das die Domain-Prüfung blockiert.

Funktioniert ACME auch für interne Systeme ohne öffentliche Domain?

Ja. ACME ist nicht auf öffentliche CAs beschränkt. Für interne Dienste können Sie eine eigene ACME-fähige CA als Teil Ihrer internen PKI betreiben. So profitieren auch nicht öffentlich erreichbare Systeme von automatischer Ausstellung und Erneuerung, ohne dass Sie sie von Hand pflegen müssen.

Wie finde ich heraus, welche Zertifikate ich überhaupt habe?

Beginnen Sie mit einem Inventar aller Dienste und ergänzen Sie es mit den öffentlichen Certificate-Transparency-Logs, die jede für Ihre Domains ausgestellte Bescheinigung verzeichnen. So finden Sie auch vergessene Zertifikate auf Testsystemen oder alten Loadbalancern. Was Sie nicht kennen, können Sie nicht automatisiert erneuern - und genau das wird zur Ausfallquelle.

Verifikation

• Ablaufdatum eines Zertifikats prüfen: echo | openssl s_client -connect beispiel.de:443 -servername beispiel.de 2>/dev/null | openssl x509 -noout -dates
• Restlaufzeit und Aussteller anzeigen: openssl x509 -in zertifikat.pem -noout -enddate -issuer
• Beschlüsse und aktuelle Anforderungen: CA/Browser Forum
• ACME-Standard: RFC 8555
• Hintergrund zu kurzlebigen Zertifikaten: Let's Encrypt