200-Tage-Zertifikate: Ab Oktober läuft die erste Erneuerungswelle – und sie kommt jedes halbe Jahr wieder
Seit dem 15. März 2026 dürfen öffentlich vertrauenswürdige TLS-Zertifikate maximal 200 Tage laufen. Die ersten Zertifikate unter der neuen Regel wurden im März ausgestellt – und laufen damit ab Anfang Oktober aus. Wer bisher einmal im Jahr eine Kalendererinnerung hatte, bekommt jetzt zwei. Ab März 2027 werden es vier, ab 2029 acht. Das ist der Punkt, an dem manuelles Zertifikatsmanagement endet.
Der Stufenplan
Das CA/Browser Forum – der Zusammenschluss aus Zertifizierungsstellen und Browserherstellern, unter anderem Apple, Google, Microsoft und Mozilla – hat mit Ballot SC-081 einen verbindlichen Fahrplan beschlossen. Keine Empfehlung, keine Absichtserklärung: Zertifizierungsstellen dürfen ab den jeweiligen Stichtagen keine längeren Laufzeiten mehr ausstellen.
| bis 14.03.2026 | maximal 398 Tage – die seit September 2020 gültige Obergrenze |
| seit 15.03.2026 | maximal 200 Tage – knapp die Hälfte, Erneuerung etwa alle 6,5 Monate |
| ab 15.03.2027 | maximal 100 Tage – quartalsweise Erneuerung für das gesamte Portfolio |
| ab 15.03.2029 | maximal 47 Tage – faktisch monatlich |
Parallel dazu werden die Zeiträume verkürzt, in denen eine Zertifizierungsstelle bereits erhobene Validierungsdaten wiederverwenden darf. Ab 2029 sind DCV-Token nur noch zehn Tage gültig. Beides zusammen bedeutet: Auch die Domänenvalidierung muss automatisiert laufen, nicht nur die Ausstellung.
Was jetzt im Oktober passiert
Bestehende Zertifikate behalten ihre ursprüngliche Laufzeit – wer im Februar 2026 noch ein 398-Tage-Zertifikat bekommen hat, kann es bis Anfang 2027 nutzen. Die erste Welle betrifft also die Zertifikate, die direkt nach dem 15. März neu ausgestellt oder erneuert wurden. 200 Tage später landet man bei Anfang bis Mitte Oktober 2026.
Praktisch heißt das: In den kommenden Wochen laufen bei vielen Unternehmen zum ersten Mal Zertifikate ab, mit denen sie im Frühjahr noch nicht gerechnet hatten – weil im Kopf immer noch „das läuft ein Jahr“ steht. Und der Ausfall eines Zertifikats ist selten leise. Er trifft die Webseite, das RD-Gateway, den Exchange-Server, das VPN oder die Schnittstelle, über die der Warenwirtschaftsabgleich läuft.
Was betroffen ist – und was nicht
| Öffentliche TLS-Serverzertifikate | Betroffen – von DigiCert über Sectigo bis Let’s Encrypt, ohne Ausnahme. Wildcards und SAN-Zertifikate ebenso. |
| Interne Zertifikate aus der eigenen ADCS | Formal nicht betroffen – die Vorgabe gilt nur für öffentlich vertrauenswürdige Zertifikate. |
| Code-Signing, S/MIME, Client-Zertifikate | Andere Regelwerke, eigene Fristen – nicht mit den TLS-Serverzertifikaten in einen Topf werfen. |
Dass die eigene Unternehmens-CA formal außen vor bleibt, ist übrigens kein Grund zur Entspannung, sondern eine Gelegenheit. Ein kompromittiertes internes Zertifikat mit zwei Jahren Restlaufzeit ist genauso lange ein Problem wie ein öffentliches. Wer ohnehin gerade sein Zertifikatsmanagement anfasst, sollte bei der Gelegenheit die Laufzeiten der eigenen Vorlagen prüfen – Webserver-, RDP- und Domänencontroller-Zertifikate mit fünf Jahren Gültigkeit sind in vielen gewachsenen PKIs noch Normalität.
Die Rechnung, die viele unterschätzen
Ein Unternehmen mit 500 Zertifikaten hatte bisher rund 500 Erneuerungen pro Jahr – knapp zwei pro Arbeitstag, gut verteilt, meist noch händisch machbar. Bei 200 Tagen sind es fast 900. Ab 2027 rund 1.800. Ab 2029 etwa 3.900, also rund 15 pro Arbeitstag. Bei 50 Zertifikaten klingt das harmlos, bei 500 ist es eine Stelle.
Und es geht nicht nur ums Ausstellen. Jede Erneuerung bedeutet: Zertifikat abholen, auf dem Zielsystem installieren, Dienst neu starten oder Bindung aktualisieren, Kette prüfen, alte Zertifikate entfernen. Genau dieser Teil ist bei Exchange, RD-Gateways, Firewalls, Loadbalancern und Druckern nicht per Knopfdruck erledigt.
Vier Schritte, mit denen Sie durchkommen
- Inventar erstellen – vollständig, nicht nur die Webseite. Die gefährlichen Zertifikate sind die, an die niemand denkt: das Managementinterface der USV, die Schnittstelle beim Steuerberater, das alte Testsystem mit Produktivdaten. Zu jedem Zertifikat gehören drei Angaben: wo es installiert ist, wer dafür zuständig ist, wann es abläuft.
- Ablaufüberwachung einrichten. Nicht „ich bekomme eine E-Mail von der CA“, sondern eine aktive Prüfung des tatsächlich ausgelieferten Zertifikats am Endpunkt. Die CA weiß nicht, ob Sie das neue Zertifikat auch installiert haben.
- Automatisieren, wo es geht. ACME nach RFC 8555 ist der Standard dafür; Certbot, acme.sh, Caddy, Traefik oder cert-manager decken die typischen Fälle ab. Windows-Umgebungen kommen mit win-acme für IIS und einer sauberen Skriptanbindung für Exchange und RDS erstaunlich weit.
- Für den Rest Prozesse statt Heldentum. Wo Automatisierung nicht geht, braucht es einen dokumentierten, wiederholbaren Ablauf mit festem Termin und Vertretungsregelung. Ein halbjährlicher Vorgang, den nur ein Kollege beherrscht, ist ein Ausfall mit Ankündigung.
Für die Bestandsaufnahme reicht zum Einstieg ein kurzes Skript, das die tatsächlich ausgelieferten Zertifikate an Ihren Endpunkten abfragt – also den Zustand prüft, nicht die Erwartung:
‘www.ihre-domain.de:443’
‘mail.ihre-domain.de:443’
‘rdgw.ihre-domain.de:443’
‘vpn.ihre-domain.de:443’
)foreach ($e in $Endpunkte) {
$Host_, $Port = $e -split ‘:’
try {
$Tcp = [System.Net.Sockets.TcpClient]::new($Host_, [int]$Port)
$Ssl = [System.Net.Security.SslStream]::new($Tcp.GetStream(), $false,
{ param($s,$c,$ch,$er) $true })
$Ssl.AuthenticateAsClient($Host_)
$Zert = [System.Security.Cryptography.X509Certificates.X509Certificate2]$Ssl.RemoteCertificate [pscustomobject]@{
Endpunkt = $e
Aussteller = ($Zert.Issuer -split ‘,’)[0] GueltigBis = $Zert.NotAfter
RestTage = [int]($Zert.NotAfter – (Get-Date)).TotalDays
Laufzeit = [int]($Zert.NotAfter – $Zert.NotBefore).TotalDays
}
}
catch { Write-Warning “$e nicht erreichbar: $($_.Exception.Message)” }
finally { if ($Ssl) { $Ssl.Dispose() }; if ($Tcp) { $Tcp.Dispose() } }
}
Die Spalte Laufzeit ist dabei der interessante Teil: Alles, was dort noch 398 steht, stammt aus der Zeit vor März und wird bei der nächsten Erneuerung auf 200 fallen. Das ist Ihr Vorlauf, um den Prozess umzustellen.
- ISW Certificate Inventory Manager – Bestandsaufnahme über die gesamte Umgebung, inklusive SAN- und Wildcard-Analyse und Ablaufüberwachung mit SMTP-Alarmierung. Genau das Inventar, das Schritt 1 verlangt.
- ISW CA Operations Manager Pro – bringt Ordnung in die eigene Zertifizierungsstelle: Vorlagen, Laufzeiten, ausgestellte Zertifikate und deren Verwendung auf einen Blick.
- ISW CA Revocation Manager Pro – wenn die Laufzeiten kürzer werden, wird die Sperrliste wichtiger, nicht unwichtiger. Sperren, CRL-Veröffentlichung und OCSP im Griff behalten.
- ISW Registrierungsagent Center – für Umgebungen, in denen Zertifikatanforderungen gegengezeichnet und kontrolliert eingereicht werden müssen, statt dass jeder selbst beantragt.
Fazit
Die Verkürzung ist keine Schikane der Browserhersteller. Sie ist die Antwort auf ein reales Problem: Ein kompromittiertes oder falsch ausgestelltes Zertifikat muss schnell aus dem Verkehr gezogen werden können, und Sperrlisten funktionieren in der Praxis schlechter als kurze Laufzeiten. Nebenbei schafft der Wechsel die Grundlage dafür, künftig zügiger auf neue Verfahren umzustellen – Stichwort Post-Quanten-Kryptografie.
Für Administratoren bleibt trotzdem eine unbequeme Wahrheit: Manuelles Zertifikatsmanagement war schon bei 398 Tagen riskant. Bei 200 Tagen ist es mühsam. Bei 100 Tagen ist es ein Vollzeitjob. Wer jetzt sein Inventar aufbaut und Schritt für Schritt automatisiert, hat bis 2029 einen geordneten Weg. Wer wartet, sammelt Ausfallrisiko an – und zwar in Halbjahresschritten.
Quellen: CA/Browser Forum, Ballot SC-081v3; Herstellerinformationen von DigiCert, Sectigo und SSL.com; Fachbeiträge der PSW Group und von cloudmagazin. Alle ISW-Tools: isw-adtools.de