Monatliche Zertifikatserneuerung

Ende 2024 überraschte Apple alle mit der Ankündigung, die maximale Zertifikatslaufzeit auf nur 45 Tage zu verkürzen. Nach einigen Monaten und kleineren Revisionen wurde die Maßnahme im April 2025 als CA/Browser Forum-Beschluss SC-081v3 endgültig beschlossen. Falls Ihnen dies noch nicht bekannt ist: Die Änderungen sind ziemlich gravierend und reduzieren die bisher maximal erlaubte Zertifikatslaufzeit von derzeit 398 Tagen auf lediglich 47 Tage im März 2029. Zeit zum Zögern bleibt auch nicht, denn es gibt zwei Zwischenstufen: Die erste Verkürzung erfolgt auf 200 Tage im März 2026 (schon bald!), die zweite auf 100 Tage im März 2027.

In der Praxis wechseln wir damit von jährlichen Erneuerungen heute zu halbjährlichen Erneuerungen 2026, zu vierteljährlichen 2027 und schließlich zu monatlichen Erneuerungen 2029. 

Deshalb sind jetzt alle damit beschäftigt, herauszufinden, wo sie überall öffentliche Zertifikate nutzen, und daraufhin Automatisierung einzuführen. Langfristig werden diese Änderungen die Situation verbessern, aber die kurzfristig zusätzlich anfallende Arbeit stellt für viele eine erhebliche Belastung dar.

Let's Encrypt, die kostenlose CA, von der ein Großteil der Welt seine Zertifikate bezieht und die als Vorreiter der 90-Tage-Zertifikate gilt, verfolgt einen noch ehrgeizigeren Zeitplan: Dort werden die Zertifikate ab Februar 2028 auf 45 Tage gekürzt. Vermutlich ist das für Sie weniger relevant. Die Ausstellung dieser Zertifikate geschieht immer automatisch – das bedeutet, Sie müssen nichts weiter tun, als die Änderung zu beobachten.

Für kürzere Zertifikatslaufzeiten sprechen viele gute Argumente. Betrachten Sie Folgendes:

• Manuelle Erneuerung ist ineffizient. Unzählige Arbeitsstunden werden auf die Planung, Koordination und Durchführung dieser banalen Aufgabe verwendet. Zudem besteht bei jeder manuellen Änderung die Gefahr, dass etwas kaputt geht – und deren Behebung erfordert erneut Ressourcen. Kurze Laufzeiten machen manuelle Erneuerungen unpraktikabel, was wiederum dazu führt, dass Automatisierung für alle unabdingbar wird. Langfristig profitieren davon alle Beteiligten.
• Automatisierte Erneuerung ist flexibel. In öffentlichen PKIs liegt ein starker Fokus auf der Korrektheit der Zertifikate. Strenge Regeln verhindern lange Diskussionen darüber, ob ein bestimmter Fehler so gewichtig ist, dass er als Fehlzertifizierung gilt. Die Branche hat sich auf diese pedantische Herangehensweise geeinigt, um besagte Diskussionen zu vermeiden. Daher müssen Fehler korregiert werden – auch wenn sie praktisch keine Auswirkungen haben. Durch Fehler der CAs erzwungene Zertifikatserneuerungen kommen bei Kunden nie gut an, doch Automatisierung ist eine Lösung dafür. In RFC 9773 wurde ACME um die Möglichkeit erweitert, dass CAs die automatische Erneuerung fehlerhafter Zertifikate auslösen können.
• Kürzere Laufzeiten gewährleisten kryptografische Agilität. Früher setzte man für Zertifikats-Signaturen auf die Hashfunktion SHA1, bis sich eines Tages herausstellte, dass sie kompromittiert ist. Der Umstieg auf SHA2 dauerte lange – unter anderem, weil viele langlaufende Zertifikate noch auf SHA1 basierten. Browser konnten diese nicht einfach blockieren, da es sonst sofort zu massenhaften Problemen gekommen wäre. Mit kürzeren Laufzeiten lassen sich solche Umstellungen künftig wesentlich leichter bewältigen.
• Sperrprüfungen werden kaum durchgeführt. Vor einigen Jahren haben große Browser beschlossen, auf Sperrprüfungen zu verzichten – aus Gründen der Performance, Verfügbarkeit und des Datenschutzes. (Firefox bildet die einzige Ausnahme; hier wurde stattdessen das CRLite-Verfahren eingeführt, das mittlerweile auf den Desktop-Plattformen im Einsatz ist.) Das schafft eine problematische Situation: Wird ein Zertifikat kompromittiert, besteht ein Zeitfenster von bis zu 398 Tagen, in dem es missbraucht werden kann. Die einzige verlässliche Lösung ist daher, die Zertifikatslaufzeit zu verkürzen.
• Verwaiste Zertifikate finden sich überall. Heutzutage holen sich die wenigsten noch selbst Zertifikate. Stattdessen melden wir uns bei Plattformen an, die dann in unserem Namen Zertifikate holen. Das ist die graue Zone von öffentlichen PKIs – diese Zertifikate tragen unsere Domainnamen, stehen aber unter der Kontrolle Dritter. Wem gehören sie also? Beim Wechsel von einer Plattform zur anderen bleiben die älteren Zertifikate oft ... irgendwo aktiv. Das gilt auch beim Domaininhaberwechsel: Der Vorbesitzer behält noch eine Zeit lang Kontrolle. Mehr dazu finden Sie in dieser Forschungsarbeit. Auch in diesem Punkt mindert eine kurze Zertifikatslaufzeit die Risiken.

Es ist offensichtlich, dass diese Entwicklung grundsätzlich positiv ist. Weniger klar ist, warum es ausgerechnet 47 Tage sein müssen – 90 Tage würden vermutlich einen ähnlichen Effekt erzielen und die Erneuerungs- und Überwachungssysteme weniger belasten. Andererseits könnte in Zukunft auch eine weitere Verkürzung erfolgen ... aber das wäre schwer zu begründen, wenn man alle einbeziehen will.

In ihrem Jahresbericht 2024 trieb die Internet Security Research Group (ISRG, die Organisation hinter Let's Encrypt) die Reduzierung der Zertifikatslaufzeiten auf die Spitze und kündigte für 2025 Zertifikate mit einer Laufzeit von sechs Tagen an. Für die meisten Unternehmen ergibt das wenig Sinn, aber für Organisationen, die das Risiko kompromittierter Zertifikate minimal halten wollen, sind sie ideal. Im schlimmsten Fall bleibt das Zertifikat nur sechs Tage lang angreifbar. Das ist tatsächlich besser als die Garantien, die herkömmliche Online-Sperrprüfungen praktisch geboten haben – dort betrug der Zeitraum sieben Tage.

Ich mag ein wenig PKI-Archäologie und habe deshalb die Geschichte der maximalen Zertifikatslaufzeiten recherchiert. Die Veränderungen im Laufe der Zeit spiegeln durchaus die Entwicklung der öffentlichen PKIs wider – vom "Wilden Westen" bis zum heutigen, streng regulierten und überwachten Markt. Es erinnert manchmal fast an eine Seifenoper.

Die ersten Einschränkungen wurden mit der ersten Version der "Baseline Requirements" (BR) des CA/Browser Forums eingeführt, welche festlegen, wie Zertifikate ausgestellt werden sollen. Vor BR gab es keine Begrenzung – wer wollte konnte problemlos ein 10-Jahres-Zertifikat erhalten. Die erste BR-Version setzte 2012 das Limit zunächst auf 60 Monate, die weitere Reduktion auf 39 Monate wurde auf 2015 verschoben.

Zwei Jahre später, 2017, scheiterte zunächst ein Ballot 185, der Zertifikate auf 398 Tage begrenzen sollte. Fast alle CAs stimmten mit "Nein". Interessanterweise lehnten zwei Browserhersteller ebenfalls ab, einer enthielt sich. Nur einen Monat später setzte sich Ballot 193 jedoch durch und reduzierte die Laufzeit auf 825 Tage.

Nochmals zwei Jahre später, im Oktober 2019, scheiterte der zweite Versuch, die Laufzeit auf 398 Tage zu begrenzen (Ballot SC-022v2), erneut. Die CAs waren weiterhin dagegen. Die Hauptbegründung: mehr Aufwand für die Kunden. Doppelte Erneuerung heißt doppelter Aufwand. Für Browser spielt das keine Rolle, für CAs schon – die Interessenlage war verschieden. Bei diesem Ballot wurde der tiefe Graben zwischen Browsern und CAs besonders deutlich.

Am Ende traf Apple – obwohl Google Initiator von SC022 war – eine einseitige Entscheidung und verkündete beim CA/Browser Forum Meeting im Februar 2020, dass ab September 2020 keine neuen Zertifikate mehr akzeptiert werden, die länger als 398 Tage gültig sind. Formal wurde dies durch Ballot SC-031, treffend "Browser Alignment" genannt, in die BR übernommen.

Wie Sie bereits wissen, stand Apple auch hinter dem jüngsten Vorstoß zu 47 Tagen. Dieses Mal stimmten die meisten CAs für den Vorschlag – ob aus Überzeugung oder weil sie keine andere Wahl sahen, sei dahingestellt.

Immerhin, 2025 sieht die Situation bezogen auf Automatisierung viel besser aus als nach 10 Jahren automatisierter Ausstellung über Automatic Certificate Management Environment (ACME). Vielleicht steht flächendeckende Automatisierung wirklich kurz bevor. Außerdem war im aktuellen Ballot klar vorgegeben, schrittweise vorzugehen, sodass wir, falls es gravierende Probleme gibt, jederzeit zurückrudern können.

Wenn man Ballot SC-081v3 (die Einführung der final verkürzten Zertifikatslaufzeiten) genauer liest, erkennt man, dass auch die Wiederverwendungsfristen bei Validierungen entsprechend verkürzt werden. Wer sich mit PKI nicht näher befasst hat, weiß vielleicht gar nicht, dass Validierungen wiederverwendet werden können – aber das können sie.

Früher, als die Validierung meist manuell erfolgte, war die Möglichkeit der Wiederverwendung ein großer Vorteil – sowohl für CAs als auch für die Kunden. CAs mussten ihre Kunden und deren Domains nur periodisch prüfen und konnten anschließend beinahe sofort Zertifikate für deren Domains ausstellen. Wer den manuellen Validierungsprozess kennt, weiß, dass dieser durchaus Tage dauern kann. Diese Vorgehensweise war sinnvoll und hat allen Beteiligten viel Aufwand erspart.

Für die Subject-Validierung (z. B. zur Organisationserkennung) liegt das aktuelle Limit bei 825 Tagen, ab März 2026 wird dieses auf 398 Tage reduziert und bleibt dann konstant. Da die subject-Validierung manuell erfolgen muss und sehr aufwändig ist, macht eine längere Wiederverwendungsfrist hier Sinn.

Hingegen wird die Wiederverwendung der Validierungsergebnisse von Domainnamen und IP-Adressen, die vollautomatisiert werden können, im gleichen Rhythmus wie die der Zertifikatslaufzeiten reduziert – die letzte Stufe liegt dann jedoch bei nur noch 10 Tagen.

Auch diese Anpassungen sind ein weiterer Schritt hin zur Automatisierung aller automatisierbaren Prozesse. Das gehört zu einem umfassenden Modernisierungsprozess, der auch die Abschaffung älterer Validierungsmethoden wie WHOIS, E-Mail und Telefonkommunikation umfasst (beispielsweise SC-090, SC-091 und SC-080v3). Dadurch können Domaininhaber besser steuern, wer für ihre Domains Zertifikate ausstellen darf. Mehr Aufwand bedeutet das aber nicht zwangsläufig, denn neue Funktionen wie dauerhafte DNS-Einträge zur Domainvalidierung werden eingeführt (ebenfalls Teil von SC-091).