Wie Sie sich an kürzere Zertifikatslaufzeiten und PKI-Änderungen anpassen

Management Summary: Browser-Root-Programme verkürzen die Laufzeiten von TLS-Zertifikaten (Transport Layer Security) von derzeit 100 Tagen bis 2029 auf nur noch 47 Tage. Auch das Zeitfenster für Domainvalidierungen, das zur Ausstellung benötigt wird, schrumpft rasant. Kommt Post-Quantum-Kryptografie hinzu, wird Zertifikatsmanagement von einer vierteljährlichen Aufgabe zu einem kontinuierlichen Prozess. Manuelle Erneuerung wird diesen Wandel nicht überstehen. Automatisierte und überwachte Ausstellung dagegen schon.

Wichtige Erkenntnisse:

• TLS-Zertifikatslaufzeiten sinken bis 2027 auf 64 Tage und bis Februar 2028 auf 45 Tage. Das bedeutet für die meisten Unternehmen einen Sprung von vier auf rund 12 oder 13 Erneuerungen pro Zertifikat und Jahr.
• Das Wiederverwendungsfenster für Domain Control Authorizations verkürzt sich von aktuell 30 Tagen auf bis zu nur 7 Stunden. Ausstellungs-Workflows dürfen sich also nicht mehr auf alte Validierungen verlassen.
• Post-Quantum-Kryptografie (PQC): Die Umstellungsziele liegen je nach Anbieter zwischen 2029 (Google) und 2033 (US-amerikanische Systeme für nationale Sicherheit) und betreffen nicht nur den Schlüsselaustausch, sondern auch das Zertifikatsformat.
• Lücken im Zertifikatsinventar – vor allem bei privaten, internen und Drittanbieter-Zertifikaten – werden mit kürzeren Laufzeiten gefährlicher, da unbekannte Zertifikate schneller ausfallen.

Zertifikatslaufzeiten für TLS-Zertifikate, die Ihre Websites, APIs, internen Dienste und Integrationen mit Drittanbietern absichern, werden in Kürze deutlich kürzer werden – und mit ihnen steigt die Frequenz zur Erneuerung erheblich an.

Browser-Root-Programme kürzen die Zeit, in der ein Zertifikat nach der Ausstellung als vertrauenswürdig gilt. Matthew McPherrin, technischer Leiter des SRE-Teams von Let's Encrypt, erläuterte diese Entwicklung in einem kürzlich von Billy McDiarmid, VP of Customer Engineering bei Red Sift, moderierten Webinar. Seine Einschätzung ist eindeutig: Die Branche bewegt sich auf Zertifikate zu, deren Laufzeiten in Wochen, nicht mehr in Monaten gemessen werden.

Die veröffentlichte Zeitachse sieht so aus:

• Februar 2027: 64-Tage-Zertifikate
• Februar 2028: 45-Tage-Zertifikate
• März 2029: Branchenweite Obergrenze von 47 Tagen gemäß CA/Browser Forum Ballot SC-081v3

Aktuell nutzen die meisten Unternehmen 90-Tage-Zertifikate und erneuern etwa vier Mal im Jahr. Bei 47 Tagen muss jedes Zertifikat bereits 12 bis 13 Mal jährlich erneuert werden. Doppelt so viele Erneuerungen heißen auch doppelt so viele Chancen, dass eine fehlgeschlagene Erneuerung unbemerkt bleibt – und der Zeitraum zur Fehlerbehebung wird deutlich kürzer.

Kürzere Laufzeiten bedeuten zwar mehr operativen Aufwand, aber die Sicherheitslogik dahinter ist schlüssig.

McPherrin hob zwei konkrete Vorteile hervor: Ein kompromittiertes Zertifikat ist für Angreifer nur so lange nützlich, wie es gültig ist. Eine kürzere Laufzeit verkürzt dieses Zeitfenster, unabhängig davon, wann der Missbrauch entdeckt wird. Auch die Sperrung wird einfacher – Zertifikatswiderrufslisten (CRLs) werden im Ernstfall riesig, und kurzlebige Zertifikate verringern die Abhängigkeit von lange gespeicherten Widerrufsdaten.

Der Widerruf selbst ist im operativen Alltag oft die größte Herausforderung. Er erfordert Koordination zwischen Teams, Benachrichtigung von Kunden sowie manuelle Ersetzungsarbeiten. Kürzere Laufzeiten verkürzen die Zeit, die dieser Prozess in Anspruch nimmt.

Die Domain Control Validation – der Nachweis, dass Sie tatsächlich Inhaber einer Domain sind, bevor die Zertifizierungsstelle (CA) ein Zertifikat ausstellt – hat künftig ebenfalls ein noch kürzeres Verfallsdatum.

Derzeit gestatten die meisten CAs eine Wiederverwendung gültiger Authorizations bis zu 30 Tage lang. Dieses Zeitfenster wird auf 10 Tage und in Zukunft sogar auf nur noch 7 Stunden verkürzt.

Stützt sich Ihr Ausstellungsprozess auf langjährige Annahmen, einen manuellen Freigabeprozess, ein selten geprüftes Passwort oder einen Erneuerungsjob, der nur vierteljährlich läuft, wird es hier zuerst scheitern. Die Automatisierung muss bei Ablauf der Wiederverwendung die Validierung selbst erneut durchführen – und kann nicht warten, bis jemand einen Fehler bemerkt.

Der häufigste Ratschlag in der Branche: Automatisieren Sie Ausstellung und Erneuerung nach Standardprotokollen, damit Zertifikate ersetzt werden können, ohne dass jemand eine Tastatur berührt.

Selbst Automatisierung kann scheitern: Zugangsdaten laufen ab, APIs verhalten sich unerwartet, Pipelines brechen ab. Die Lösung ist nicht, dass jemand einmal pro Quartal eine Tabelle prüft. Es braucht Monitoring, Retry-Logik und Sichtbarkeit über den gesamten Erneuerungsprozess – vom Ausstellen bis zum Reload.

In der Praxis bedeutet das:

• Automatisieren Sie Ausstellung und Erneuerung über ACME (Automated Certificate Management Environment), das Protokoll, das die meisten großen Zertifizierungsstellen unterstützen.
• Überwachen Sie kontinuierlich den Erneuerungserfolg, nicht nur das Zertifikatsablaufdatum.
• Testen Sie die gesamte Kette von der Ausstellung über Erneuerung und Verteilung bis zum Reload des Dienstes.
• Vermeiden Sie Arbeitsabläufe, die sich auf langfristige Authorizations verlassen.
• Probieren Sie Zertifikate mit kürzeren Laufzeiten zuerst im Testsystem, bevor die Fristen in der Produktion relevant werden.

ACME verringert bereits den Vendor-Lock-in, denn die meisten großen CAs unterstützen dasselbe Protokoll – Ihr Tooling muss bei einem Wechsel nicht angepasst werden. Einige neue Erweiterungen sind besonders interessant.

ACME-Profile ermöglichen es Clients, sich schon vor den verpflichtenden Fristen für kürzere Zertifikatslaufzeiten zu entscheiden. So haben große Unternehmen Zeit, den Wechsel auf 45-Tage-Zertifikate vorab zu testen.

Renewal Info soll den CA-seitigen Widerruf weniger hektisch machen. Clients können auf diesem Weg automatisch den richtigen Pfad zur Problembehebung herausfinden, ohne dass Mitarbeiter im Notfall erst nach einer Lösung suchen müssen.

Kurzlebige Zertifikate, darunter eine sechs Tage gültige, per Opt-in wählbare Variante, unterstreichen die Notwendigkeit zur Automatisierung nochmals. McPherrins Warnung dazu ist praxisnah: Das funktioniert nur, wenn Ihr Monitoring perfekt eingestellt ist, da es keinen Spielraum für eine manuelle Nachbesserung mehr gibt.

Neue Validierungsmethoden sind in Entwicklung, um DNS-basierte Domainvalidierung für Organisationen zu erleichtern, deren Infrastruktur nicht zu den aktuell genutzten Challenge-Typen passt.

Automatische Erneuerung bringt wenig, wenn Sie nicht wissen, welche Zertifikate erneuert werden müssen. Die meisten Inventarisierungsprozesse beschränken sich auf die öffentlich sichtbaren Zertifikate, die ein oder zwei Teams aktiv pflegen. Die Wirklichkeit sieht deutlich umfangreicher aus:

• Private und interne Zertifikate
• Zertifikate in Shadow-IT-Umgebungen
• Drittanbieter-Zertifikate, die in SaaS-Tools und Integrationen stecken
• Zertifikate auf abgeschalteten Diensten, die niemand entfernt hat
• Zertifikate, die an CDNs oder externe Plattformen gebunden sind
• Inventardrift nach Fusionen und Übernahmen

Ein Zertifikatsinventar ist die vollständige, aktuelle Liste aller Zertifikate in Ihrer Infrastruktur: Wo sind sie installiert, von welcher CA wurden sie ausgestellt, wann laufen sie ab, und welche Systeme präsentieren oder vertrauen ihnen? Mit kürzeren Laufzeiten versagen unbekannte Zertifikate schneller und der „Blast Radius“ einer versäumten Erneuerung wächst entsprechend.

Kürzere Laufzeiten betreffen den kurzfristigen Betrieb. Post-Quantum-Kryptografie (PQC) stellt eine langfristige Herausforderung dar und betrifft gleichzeitig Browser-Vertrauen, Zertifikatsformate, CA-Signaturalgorithmen und Support-Zeitpläne für Geräte.

Die Migrationsziele variieren je nach Bereich: Google zielt auf 2029, nationale Sicherheitssysteme der USA auf 2030 und 2033. Die entsprechenden Standards werden von NIST und anderen Regierungsstellen vorangetrieben.

PQC ist kein Schalter, den man einfach umlegt. Post-Quanten-Signaturen fallen in der Regel größer aus als herkömmliche – das braucht mehr Bandbreite und verlangsamt den TLS-Handshake im großen Maßstab. Ein diskutierter Lösungsansatz, „Merkle Tree Certificates“, bündelt Validierungsdaten für Signaturen und verteilt sie außerhalb des TLS-Handshakes per Browser. Profitieren kann man davon aber erst, wenn auch Browser und Clients diese Ansätze unterstützen.

PQC-Migration betrifft nicht nur Zertifikate. Der Schlüsselaustausch – also der Teil von TLS, der ein gemeinsames Sitzungs-Geheimnis aushandelt – ist ebenfalls kritisch. Hier spielt das „Harvest now, decrypt later“-Szenario eine Rolle: Ein Angreifer zeichnet den Datenverkehr heute auf, um ihn später mit Quantencomputern zu entschlüsseln.

McPherrins Tipp ist praktisch und leicht umsetzbar: TLS 1.3 einsetzen und wo immer möglich hybriden Post-Quantum-Schlüsselaustausch aktivieren. Das birgt weniger Risiko als eine komplette Umstellung der Zertifikatsstruktur, weil es eher abwärtskompatibel ist und kein geändertes Zertifikatsformat erfordert.

Geräte mit begrenzten Ressourcen lassen sich nicht mit standardmäßigen Web-PKI-Strategien absichern. Akku-Limits, geringe Bandbreite und begrenzte Update-Mechanismen führen dazu, dass IoT-Umgebungen vermutlich mehr Algorithmus-Diversität als Server oder Browser benötigen. Manche Geräte unterstützen Merkle-Tree-Ansätze, andere benötigen alternative Signaturverfahren mit unterschiedlichen Bandbreiten-Komponenten. Was auch immer Sie für Ihre Web-Infrastruktur planen – prüfen Sie vorher ab, ob es auf IoT-Geräte tatsächlich passt.

Wer Zertifikatslaufzeiten, ACME-Automatisierung, Inventarlücken und PQC-Readyheit in einem Quartal angeht, riskiert ungeplante Ausfälle. Zerlegen Sie die Aufgaben in Testbare Einzelschritte:

1. Pilotieren Sie Zertifikate mit kürzeren Laufzeiten zunächst in einer Testumgebung.
2. Stärken Sie das Monitoring der Erneuerung und den Deployment-/Reload-Workflow.
3. Erstellen Sie vollständige Zertifikatsinventare – private und Drittanbieter-Zertifikate zuerst, da diese besonders häufig übersehen werden.
4. Aktivieren Sie TLS 1.3 und hybriden Post-Quantum-Schlüsselaustausch, wo immer möglich.
5. Planen Sie die PQC-Readyheit Ihrer Zertifikate basierend auf realistischen Zeitplänen für Browser- und Gerätesupport, nicht auf frühestmöglichen Stichtagen.

Zertifikatsmanagement wird von einer quartalsweisen Kontrolle zu einem kontinuierlichen Betrieb. McPherrin formulierte es so: Die Web-PKI wird immer weniger Geduld für Unternehmen haben, die dies noch von Hand erledigen.

Wer weiß, welche Zertifikate tatsächlich existieren, ihre Erneuerung automatisiert und den Gesamtprozess lückenlos überwacht, erkennt Fehlkonfigurationen, bevor es zu Ausfällen kommt.

Wenn Sie Zertifikate noch in Excel-Tabellen verwalten, hilft Red Sifts Certificate Essentials – volle Transparenz über alle Zertifikate und Echtzeitüberwachung, sodass nichts durchs Raster fällt. Enthalten: DNS-Inspektion, Überprüfung der TLS-Sicherheitslage und dedizierte PQC-Überwachung – und genug Platz für weitere Veränderungen. Für Unterstützung bei der ACME-Automatisierung empfiehlt sich der Getting Started Guide von Let's Encrypt als Einstieg.

Den vollständigen Q&A-Teil zum Webinar finden Sie hier in der Aufzeichnung – inklusive Informationen zu IoT-Einschränkungen und zur Nutzung von Post-Quantum-Zertifikaten mit ACME.