Certificate Lifecycle Management (CLM): der komplette Leitfaden zum Überleben kurzer Zertifikate
Von CaptainDNS
Veröffentlicht am 9. Juli 2026
- Die Rechnung ändert alles: Ein Bestand von 1000 Zertifikaten, die alle 47 Tage erneuert werden, erzeugt über 7700 Erneuerungen pro Jahr, also das 8- bis 9-Fache des Volumens eines Jahreszyklus
- Das Tooling hinkt hinterher: Laut dem PKI-Bericht von Keyfactor (2024) verfügen nur 32 % der Organisationen über ein Tool zur Verwaltung des Zertifikatslebenszyklus, während 86 % innerhalb eines Jahres einen zertifikatsbedingten Ausfall erlitten haben
- Sechs Phasen, eine Schleife: Bestandsaufnahme, Ausstellung, Bereitstellung, Erneuerung, Widerruf und Überwachung, orchestriert durch ACME (RFC 8555) und ARI (RFC 9773), bilden einen Zero-Touch-Zyklus
- Um zu verstehen, warum die Laufzeit auf 47 Tage sinkt, lesen Sie den vollständigen Zeitplan der Reduzierung SC-081v3; dieser Artikel behandelt das Wie des operativen Überlebens
Am 21. Juli 2024 legte die Bank of England ihr Interbanken-Zahlungssystem CHAPS für 91 Minuten still. Kein Cyberangriff, keine Hardware-Störung. Ein abgelaufenes TLS-Zertifikat auf einer Netzwerkkomponente. Anderthalb Stunden lang blieben Transaktionen im Milliardenwert wegen einer Datei von wenigen Kilobyte, die ihr Verfallsdatum überschritten hatte, in der Warteschleife hängen. Die Lehre ist brutal: In einer modernen Infrastruktur ist ein vergessenes Zertifikat eine tickende Zeitbombe.
Der Vorfall steht keineswegs allein, und der Kontext verschärft ihn. Das CA/Browser Forum hat die Reduzierung der maximalen Laufzeit von TLS-Zertifikaten auf 47 Tage bis März 2029 beschlossen, mit Zwischenstufen 2026 und 2027. Die Debatte ist beendet: Kurze Zertifikate kommen, ob die Betriebsteams es wollen oder nicht. Die eigentliche Frage lautet nicht mehr ob man sich vorbereiten muss, sondern wie man Schritt hält. Ein Zertifikat einmal im Jahr zu erneuern ist eine Kalenderpflicht. Es alle 47 Tage über einen ganzen Bestand hinweg zu erneuern, ist Produktions-Engineering.
Dieser Leitfaden ist das Überlebenshandbuch. Er zerlegt das Leben eines Zertifikats in sechs Phasen, zeigt, wie ACME und seine Erweiterung ARI diesen Zyklus in eine Zero-Touch-Schleife verwandeln, entfaltet einen Aktionsplan und weitet den Blick dann auf Krypto-Agilität und die Migration in die Post-Quanten-Ära. Er richtet sich an Systemadministratoren, Plattform-Ingenieure und CISOs, die eine belastbare Erneuerungskette aufbauen müssen. Das Warum des regulatorischen Zeitplans behandelt der Artikel über die Reduzierung auf 47 Tage im Detail. Hier geht es um die Mechanik.
Prüfen und überwachen Sie den Ablauf Ihrer Zertifikate
Das eigentliche Problem ist nicht mehr die Laufzeit, sondern das Volumen
Die instinktive Reaktion auf 47-Tage-Zertifikate betrifft die Laufzeit: "Mein Zertifikat hält nur noch anderthalb Monate." Falsche Analyse. Ein kurzes Zertifikat ist nicht anfälliger als ein langes; es verschlüsselt exakt auf dieselbe Weise. Das eigentliche Problem ist arithmetisch. Es liegt in der Häufigkeit der Vorgänge: Was klemmt, ist die Vervielfachung der Erneuerungen im Maßstab eines Bestands.
Die arithmetische Explosion des Volumens
Rechnen Sie es an einem mittelgroßen Bestand durch. Mit jährlichen Zertifikaten (398 Tage) bedeuten 1000 Zertifikate rund 1000 Erneuerungen pro Jahr, also weniger als drei pro Tag. Das ist machbar, sogar von Hand, mit einer Tabelle und Disziplin.
Wechseln Sie auf 47 Tage. Jedes Zertifikat muss etwa alle 30 Tage erneuert werden (mit dem Sicherheitspuffer, der in der Zahl 47 steckt), also ungefähr 8-mal pro Jahr. Die 1000 Zertifikate erzeugen dann über 7700 Erneuerungen pro Jahr, das sind mehr als 21 Vorgänge pro Tag, Wochenenden und Feiertage inbegriffen. Der Multiplikator liegt bei 8 bis 9. Kein menschliches Team hält dieses Tempo manuell ohne Fehler durch.
Ein Detail verschärft die Mechanik: Die Wiederverwendung des Domain-Kontrollnachweises (DCV-Wiederverwendung) sinkt in der Endstufe auf 10 Tage, gegenüber 47 Tagen für die Gültigkeit des Zertifikats. Zwei Zähler, zwei Rhythmen. Die 47-Tage-Gültigkeit sagt, wie oft das Zertifikat neu ausgestellt werden muss; das 10-Tage-DCV-Fenster sagt, wie oft Ihre Domain-Kontrolle neu nachgewiesen werden muss. Verwechseln Sie die beiden nicht: Die Gültigkeit beträgt 47 Tage, die Wiederverwendung des Nachweises nur 10. Ergebnis: Jede Erneuerung schleppt eine neue Domain-Validierung hinter sich her, weil der vorherige Nachweis bereits abgelaufen ist. Der Zeitplan dieser Stufen wird im eigenen Leitfaden behandelt; merken Sie sich, dass sich auch die Validierungslast vervielfacht.
Die tatsächlichen Kosten eines Ablaufs
Warum so viel Aufmerksamkeit für eine Datei, die abläuft? Weil ein unentdeckter Ablauf den Dienst unterbricht, und die Unterbrechung teuer ist. Die öffentlichen Vorfälle erinnern oft genug daran.
Der CHAPS-Ausfall der Bank of England vom 21. Juli 2024 (91 Minuten Unterbrechung eines Interbanken-Abwicklungssystems) bleibt das Musterbeispiel für ein abgelaufenes Zertifikat auf einer kritischen Komponente. Dasselbe im Dezember 2025: Die Domain bazel.build, die von Zehntausenden Build-Pipelines weltweit genutzt wird, wurde wegen des Ablaufs ihres Zertifikats unerreichbar und legte Continuous-Integration-Ketten bis hin zu Dritten lahm, die nichts damit zu tun hatten. Und laut dem PKI-Bericht von Keyfactor haben 86 % der Organisationen in den vergangenen zwölf Monaten mindestens einen zertifikatsbedingten Ausfall erlitten. Das ist nicht der Rand der Verteilung. Das ist die Norm.
Die Kosten dieser Ausfälle werden regelmäßig beziffert, doch hüten Sie sich vor Abkürzungen. Man begegnet mehreren Größenordnungen aus unterschiedlichen Methoden, und sie zu einer einzigen Zahl zu verschmelzen wäre unehrlich. Drei getrennte Referenzen kursieren:
- Manche Branchenschätzungen beziffern die Kosten eines schweren zertifikatsbedingten Ausfalls je nach Kritikalität des betroffenen Dienstes auf 500.000 bis 5 Mio. $.
- Der PKI-Bericht von Keyfactor nennt für die befragten Organisationen durchschnittliche Kosten von 2,86 Mio. $ pro zertifikatsbedingtem Ausfall.
- Andere Analysen von Anwendungsausfällen setzen eine Größenordnung von 72.000 $ pro Stunde Unterbrechung für einen produktiven Dienst an.
Diese Zahlen messen nicht dasselbe (Kosten pro Vorfall, angegebene Durchschnittskosten, Stundenkosten) und stammen aus getrennten Quellen. In einem Punkt sind sie sich einig: Ein Ablauf ist nie kostenlos, und der Preis für gutes Tooling ist im Vergleich lächerlich gering.
Warum sind nur 32 % der Organisationen ausgestattet?
Wenn die Sache so klar ist, warum verfügen dann laut Keyfactor nur 32 % der Organisationen über ein Tool zur Verwaltung des Zertifikatslebenszyklus? Drei Gründe kommen zusammen.
Zunächst die Trägheit des Jahresmodells. Solange ein Zertifikat ein Jahr hielt, erzeugten eine Kalendererinnerung und eine Tabelle die Illusion von Kontrolle. Die Automatisierungsschuld blieb unsichtbar, weil sich Versäumnisse selten rächten. Dann die zersplitterte Verantwortung: Zertifikate werden von unterschiedlichen Teams ausgestellt (Netzwerk, Anwendung, Sicherheit, Dienstleister), und niemand führt eine vollständige Bestandsaufnahme. Und schließlich die Unterschätzung. Viele Teams glauben, ihren Bestand zu beherrschen, während sie am Rand ausgestellte Zertifikate übersehen, auf einer Test-Subdomain oder von einem Cloud-Dienst.
Der Wechsel auf 47 Tage löst diese Illusion auf. Was bei einer Erneuerung pro Jahr durchging, wird bei acht unbeherrschbar. Tooling ist kein Komfort mehr. Es ist eine Überlebensbedingung.
Die 6 Phasen des Lebenszyklus
Das Certificate Lifecycle Management (CLM) zerlegt das Leben eines Zertifikats in sechs Phasen, die in einer Schleife laufen. Sie zu kennen bedeutet zu erkennen, wo die Automatisierung eingreifen muss und wo ein Versagen zum Ausfall wird. Diese Phasen sind nicht linear: Sie bilden einen Kreis, denn das Ende eines Zertifikats löst den Beginn des nächsten aus.
Phase 1: Bestandsaufnahme und Erkennung
Man verwaltet nicht, was man nicht sieht. Die erste Phase erstellt die vollständige Liste der in Betrieb befindlichen Zertifikate, und das ist schwerer, als es scheint. Die Hauptbedrohung trägt einen Namen: Schattenzertifikate.
Ein Schattenzertifikat (oder Shadow Certificate) wird außerhalb des offiziellen Prozesses ausgestellt, oft von einem Team, das einen Dienst in der Cloud bereitstellt, von einem Entwickler, der eine Funktion testet, oder von einem Dienstleister, der ein Gerät installiert. Es taucht in keiner zentralen Tabelle auf. Es läuft ohne Vorwarnung ab. Und genau es verursacht die überraschendsten Ausfälle, weil niemand es überwacht hat.
Die Erkennung stützt sich auf mehrere Quellen, von denen keine für sich allein vollständig ist. Die Transparenzprotokolle für Zertifikate (Certificate Transparency) verzeichnen öffentlich jedes Zertifikat, das von einer öffentlichen CA für Ihre Domains ausgestellt wurde: Sie sagen, was ausgestellt wurde, aber nicht, wo es bereitgestellt ist oder ob es noch in Betrieb ist. Der aktive Netzwerkscan Ihrer IP-Adressbereiche und Ports füllt diese Lücke, indem er beobachtet, was tatsächlich über die Verbindung ausgeliefert wird, interne Zertifikate inbegriffen, die in den öffentlichen Protokollen fehlen. Bleibt der blinde Fleck der Cloud: Die Abfrage der Anbieter-APIs (verwaltete Load Balancer, CDN, verwaltete TLS-Terminierungen) fördert Zertifikate zutage, die weder CT noch der Scan leicht sehen, weil sie in undurchsichtigen Diensten leben. Diese drei Quellen zu kreuzen ist der einzige Weg, sich der Vollständigkeit zu nähern.
Die daraus entstehende Bestandsaufnahme muss für jedes Zertifikat drei nicht verhandelbare Metadaten festhalten. Zunächst seinen Eigentümer: das Team oder die Person, die verantwortlich ist, ohne die eine Warnung niemanden zum Ansprechen hat. Sein Ablaufdatum, das die gesamte Erneuerungsmechanik auslöst. Und seinen Schlüsselalgorithmus, die Angabe, die am Tag X eine gezielte kryptografische Migration ermöglicht. Ohne diese drei Felder tappen die folgenden Phasen im Dunkeln: Es ist unmöglich, die richtige Person zu alarmieren, dringende Erneuerungen zu priorisieren oder einen Algorithmuswechsel zu planen. Eine Bestandsaufnahme ohne Eigentümer ist keine Bestandsaufnahme. Sie ist eine Liste von Verdächtigen.
Phase 2: Ausstellung
Die Ausstellung ist der Moment, in dem die CA das Zertifikat erzeugt. Sie geht von einer CSR (Certificate Signing Request) aus, einer signierten Anfrage, die den öffentlichen Schlüssel und die Identität der Domain enthält. Der private Schlüssel verlässt den Server hingegen niemals. Eine Sicherheitsinvariante, nicht verhandelbar.
Ein zu oft vernachlässigter Schritt bedingt diese Phase: der CAA-Eintrag. Ein DNS-Eintrag vom Typ CAA legt fest, welche Zertifizierungsstellen für Ihre Domain ausstellen dürfen. Zielt Ihr Automatisierungsclient auf eine CA, die der CAA nicht erlaubt, schlägt die Ausstellung stillschweigend fehl. Den CAA korrekt zu konfigurieren ist also eine Voraussetzung für jede belastbare Automatisierung; der vollständige Leitfaden zu CAA-Einträgen beschreibt das Vorgehen. Und im Zeitalter häufiger Erneuerungen zerstört ein CAA-Fehler nicht eine einzelne Erneuerung: Er zerstört alle künftigen Erneuerungen.
Phase 3: Bereitstellung
Ein Zertifikat auszustellen bringt nichts, wenn es nicht den Server erreicht, der es erwartet. Die Bereitstellungsphase kopiert das neue Zertifikat und seinen Schlüssel an die richtige Stelle und lädt dann den Dienst (Webserver, Load Balancer, TLS-Terminierung) neu, damit er es berücksichtigt.
Hier kommt ein Kernstück ins Spiel: die Deploy Hooks. Ein Deploy Hook ist ein Skript, das nach dem Erhalt eines neuen Zertifikats automatisch ausgeführt wird. Der kritische Punkt ist nicht das Neuladen, sondern die Validierung vor dem Neuladen. Ein guter Hook prüft, dass das neue Zertifikat gültig ist, dass seine Kette vollständig ist und dass der private Schlüssel tatsächlich zum öffentlichen passt, bevor er den Produktionsdienst berührt. Mit einem beschädigten Zertifikat oder einer unvollständigen Kette neu zu laden verwandelt einen Routinevorgang in einen Ausfall. Die Regel steht in fünf Worten: validieren, dann neu laden, niemals umgekehrt.
Dieses Detail trennt eine belastbare Automatisierung von einer, die in falscher Sicherheit wiegt. Eine Erneuerung kann auf CA-Seite gelingen (das Zertifikat wird ordnungsgemäß ausgestellt) und auf der Bereitstellungsseite scheitern (die Datei wird nicht kopiert, das Neuladen stürzt ab, das Zwischenzertifikat fehlt). Ohne Validierung nach der Bereitstellung bleiben diese Fehler unsichtbar, bis ein Besucher auf einen Zertifikatsfehler stößt. Ein gut entworfener Hook geht über die bloße Prüfung hinaus: Er öffnet nach dem Neuladen eine echte TLS-Verbindung zum Dienst, bestätigt, dass das ausgelieferte Zertifikat tatsächlich das neue ist, und behält im Fehlerfall die alte gültige Konfiguration, statt auf eine kaputte umzuschalten. Das ist die atomare Bereitstellung, angewandt auf Zertifikate: Man geht nur dann in Produktion, wenn die neue Version nachweislich funktioniert, andernfalls zieht man ein noch gültiges Zertifikat einer Unterbrechung vor.
Phase 4: Erneuerung
Die Erneuerung stellt das Zertifikat vor seinem Ablauf neu aus. Es ist die heikelste Phase: Ihr Scheitern führt direkt zum Ausfall. Entgegen einer verbreiteten Vorstellung ist eine Erneuerung keine Verlängerung. Sie ist eine vollständige Neuausstellung, mit einer neuen Domain-Validierung, wenn das DCV-Fenster abgelaufen ist.
Die gesamte Strategie steckt im Erneuerungsfenster, also im Zeitpunkt, zu dem man den Vorgang vor dem Ablauf auslöst. Zu früh vergeudet man Laufzeit. Zu spät hat man bei einer Panne keinen Spielraum mehr. Die 47 Tage wurden gerade so kalibriert, dass ein komfortabler Puffer bleibt, wenn man rund dreißig Tage vor Fälligkeit erneuert: Es bleiben dann rund fünfzehn Tage, um einen Fehler vor der Unterbrechung zu erkennen und zu beheben. Doch dieser Puffer gilt nur, wenn die Erneuerung früh genug versucht wird und der Fehler erkannt wird, solange die Zeit läuft. Daher die entscheidende Rolle der Überwachung.
Klassischer Fehler: das Scheitern einer Erneuerung als seltenes Ereignis zu behandeln, das man von Fall zu Fall regelt. Bei einer Erneuerung pro Jahr ging das durch. Bei acht Erneuerungen pro Jahr und Zertifikat, über einen ganzen Bestand, werden Fehler statistisch sicher. Ein vorübergehend nicht verfügbarer DNS-Anbieter, ein versehentlich geänderter CAA-Eintrag, ein erreichtes API-Kontingent, eine vergessene Credential-Rotation: Jeder dieser banalen Vorfälle blockiert eine Erneuerung. Die Frage ist also nicht, ob eine Erneuerung scheitert, sondern wie viele jeden Monat scheitern und ob Ihre Kette sie selbstständig auffängt (geplanter neuer Versuch) und rechtzeitig meldet. Eine reife Pipeline behandelt das Scheitern als Regelfall, nicht als Ausnahme.
Phase 5: Widerruf
Der Widerruf macht ein Zertifikat vor seinem natürlichen Ablauf ungültig, zum Beispiel nach dem Diebstahl eines privaten Schlüssels. Historisch stützt er sich auf zwei Mechanismen: die Sperrlisten (CRL) und das OCSP-Protokoll. Nur sind beide in der Praxis weitgehend kaputt (CRL zu umfangreich, OCSP im Soft-Fail, den die Browser ignorieren), ein Punkt, der im Leitfaden zur Laufzeitreduzierung ausgeführt wird.
Die gute Nachricht ist, dass kurze Zertifikate den Widerruf weniger kritisch machen. Ein kompromittiertes 47-Tage-Zertifikat läuft von selbst in wenigen Wochen ab, was das Ausnutzungsfenster begrenzt, ohne von einem defekten Widerrufsmechanismus abzuhängen. Der Widerruf bleibt bei schweren Kompromittierungen nützlich, ist aber nicht mehr die einzige Verteidigungslinie. Die kurze Laufzeit erledigt schon einen Teil der Arbeit.
Phase 6: Überwachung
Die Überwachung ist das Sicherheitsnetz, das die Versäumnisse der fünf anderen Phasen auffängt, bevor sie zum Ausfall werden. Sie warnt bei nahendem Ablauf, typischerweise bei 60, 30, 15 und 7 Tagen vor Fälligkeit, mit einer Eskalation, die steigt, je näher das Datum rückt.
Ein Prinzip zählt hier mehr als die anderen: Die Überwachung muss unabhängig vom Automatisierungsclient sein. Ist das System, das Ihre Zertifikate erneuert, zugleich dasjenige, das Sie vor ihrem Ablauf warnt, so beraubt Sie sein Ausfall der Erneuerung und der Warnung, im schlimmsten Moment. Der Blickwinkel muss also extern sein und das tatsächlich über das Netzwerk ausgelieferte Zertifikat beobachten statt des internen Zustands der Erneuerung. Das ist der Unterschied zwischen "mein Client glaubt, erneuert zu haben" und "die Welt sieht ein gültiges Zertifikat".
Diese Unabhängigkeit ist keineswegs eine theoretische Feinheit: Sie zielt auf die heimtückischste Ausfallklasse. Das Zertifikat wurde ordnungsgemäß ausgestellt, der Automatisierungsclient zeigt "Erfolg" an, die internen Protokolle sind grün, aber die Datei ist nicht auf dem richtigen Server gelandet, oder ein alter Knoten eines Clusters liefert noch das alte Zertifikat aus, oder eine zwischengeschaltete TLS-Terminierung wurde nicht neu geladen. All das bleibt aus dem Inneren des Erneuerungssystems unsichtbar. Nur eine externe Sonde, die aus dem Internet eine echte TLS-Verbindung öffnet und das Ablaufdatum des tatsächlich präsentierten Zertifikats liest, sieht es. Die Überwachung als letzte Instanz glaubt nicht, was die Erneuerung behauptet: Sie prüft, was der Dienst ausliefert. Dieselbe Logik, die einen Unit-Test von einem End-to-End-Test trennt, angewandt auf Zertifikate.
Die ACME-Automatisierung: vom manuellen zum Zero-Touch-Betrieb
Die sechs Phasen halten dem hohen Rhythmus nur stand, wenn sie automatisiert sind. Das Protokoll, das dies ermöglicht, heißt ACME. Seine Erweiterung ARI macht es flüssig und vorhersehbar. Zusammen verwandeln sie einen manuellen Zyklus in eine Zero-Touch-Schleife, in der die Erneuerung ohne jede menschliche Hand geschieht.
Das ACME-Protokoll (RFC 8555)
ACME (Automatic Certificate Management Environment), standardisiert in RFC 8555, beschreibt den automatisierten Dialog zwischen einem Client (Ihrem Server) und einer Zertifizierungsstelle. Drei Schritte: Der Client weist nach, dass er die Domain kontrolliert, die CA prüft den Nachweis und stellt dann das Zertifikat aus.
Eine Feinheit verdient einen Halt: ACME kennt keinen Begriff der "Erneuerung". Keinen "Renew"-Endpunkt. Eine Erneuerung ist in ACME nur eine neue Ausstellung, identisch zur ersten. Das Fehlen ist gewollt: Es garantiert, dass jedes Zertifikat aus einer frischen Validierung hervorgeht, ohne persistenten Zustand, der abweichen könnte. Diese Konzeption erklärt auch, warum die Verkürzung des DCV-Fensters so schwer wiegt. Da jede Erneuerung eine neue Ausstellung ist, löst sie eine neue Validierung aus, sobald der vorherige Nachweis abgelaufen ist. Keine Abkürzung.
Der Nachweis der Domain-Kontrolle läuft über zwei Haupt-Challenges. Bei DNS-01 veröffentlicht der Client einen TXT-Eintrag unter _acme-challenge.captaindns.com, der einen aus einem von der CA gelieferten Token abgeleiteten Wert enthält; die CA fragt anschließend das DNS ab, um seine Anwesenheit zu prüfen. Es ist die einzige Challenge, die mit Wildcard-Zertifikaten (*.captaindns.com) kompatibel ist, und sie funktioniert selbst dann, wenn der Zielserver nicht ins Internet exponiert ist, was sie ideal für automatisierte Umgebungen und interne Infrastrukturen macht. Bei HTTP-01 legt der Client eine Datei unter einer bestimmten URL (/.well-known/acme-challenge/) ab, die die CA per HTTP abruft; einfacher auf einem bereits exponierten Webserver zu platzieren, aber sie beherrscht keine Wildcards und setzt voraus, dass Port 80 von außen erreichbar ist. Die Wahl hängt von Ihrer Topologie ab, doch DNS-01 setzt sich durch, sobald es Wildcards, Umgebungen ohne exponierten Webserver oder den Wunsch gibt, die Ausstellung von der Verfügbarkeit des Dienstes zu entkoppeln. In jedem Fall setzt die Automatisierung der Challenge voraus, dass Ihr DNS-Anbieter eine API bereitstellt. Ohne sie wird DNS-01 wieder manuell und damit bei hohem Rhythmus unbrauchbar.
Die ARI-Erweiterung (RFC 9773)
ACME automatisiert die Ausstellung, lässt aber eine Frage offen: wann erneuern? Die naive Antwort ("bei 30 Tagen vor Ablauf") skaliert nicht. Wenn alle Clients einer CA an derselben Schwelle erneuern, bekommt die CA Lastspitzen, und ein Notfall-Widerruf ihrerseits kann den Clients nicht signalisiert werden.
ARI (ACME Renewal Information), standardisiert in RFC 9773, regelt das. Die CA stellt nun für jedes Zertifikat ein vorgeschlagenes Erneuerungsfenster bereit, das der Client regelmäßig über einen eigenen Endpunkt abfragt. Statt fest "bei 30 Tagen vor Ablauf erneuern" zu codieren, fragt der Client die CA "wann soll ich dieses konkrete Zertifikat erneuern?" und folgt der Antwort. Drei Vorteile.
Zunächst die Glättung. Die CA verteilt die vorgeschlagenen Fenster über die Zeit, um Wellen gleichzeitiger Erneuerungen zu vermeiden. Ohne ARI neigten Millionen am selben Tag ausgestellte Zertifikate dazu, sich am selben Tag zu erneuern und die Last zu bündeln; mit ARI streckt die CA sie über mehrere Tage, zum Nutzen ihrer eigenen Infrastruktur wie auch der Stabilität des Ökosystems. Dann die Reaktivität. Muss die CA ein Bündel von Zertifikaten massenhaft widerrufen (etwa nach einem Compliance-Vorfall, der sie zur vollständigen Neuausstellung zwingt), zieht sie das vorgeschlagene Fenster vor, und die Clients, die ARI beachten, erneuern vor dem Widerruf, ohne Unterbrechung. Ein Notfallkanal von der CA zu ihren Clients, dort wo ein Massenwiderruf früher Kaskadenausfälle auslöste. Der dritte Vorteil liegt beim Durchsatz: Von ARI gesteuerte Erneuerungen umgehen im Allgemeinen die Rate Limits der CA, was bei hohem Rhythmus unverzichtbar wird. Ein Client, der pro Jahr und Zertifikat achtmal erneuert, über Tausende von Zertifikaten, würde die Standardkontingente schnell sättigen. ARI macht die Erneuerung so aus einer einseitigen Entscheidung des Clients zu einer laufenden Verhandlung mit der CA. Praktisches Ergebnis: Die ARI-Unterstützung zu verlangen ist eines der schärfsten Kriterien bei der Wahl eines Clients oder einer Plattform.
Den Client wählen: Skripte oder Plattform?
Das Protokoll ist standardisiert, also betrifft die Wahl den Client, der es umsetzt. Für einen einzelnen Server genügt certbot renew (der Referenzclient der EFF), gestartet von einer geplanten Aufgabe: Er fragt die Fälligkeit ab, erneuert bei Bedarf und löst die konfigurierten Deploy Hooks aus. acme.sh, ein Shell-Skript ohne Abhängigkeiten, bietet vergleichbare Flexibilität und unterstützt Dutzende DNS-APIs für die DNS-01-Challenge.
Die eigentliche Grenze trennt den Skript-Ansatz vom Plattform-Ansatz. Skripte (certbot, acme.sh, ein Server mit nativem ACME wie manche Reverse Proxies) eignen sich für eine Handvoll gut beherrschter Server: keine Einstiegskosten, aber Bestandsaufnahme, übergreifende Überwachung und Governance bleiben auf Ihren Schultern. Eine CLM-Plattform zentralisiert diese Funktionen über Hunderte oder Tausende heterogener Zertifikate: automatische Erkennung, Ablauf-Dashboard, Ausstellungsrichtlinien, CAA-Kontrolle. Der Auslöser für den Wechsel ist nicht die Zahl der Zertifikate allein, sondern die Heterogenität des Bestands und der Bedarf an zentraler Governance.
Der Fall Let's Encrypt: der Vorreiter der kurzen Laufzeiten
Let's Encrypt spielt seit zehn Jahren die Rolle des Freiluftlabors der kurzen Zertifikate. Die Zertifizierungsstelle kündigte am 2. Dezember 2025 den Wechsel ihrer Standardlaufzeit von 90 auf 45 Tage an und griff dem regulatorischen Zeitplan vor, um dem Ökosystem Zeit zu geben, seine Pipelines zu validieren. Sie bietet bereits Short-Lived-Zertifikate mit 6 Tagen Laufzeit für vollständig automatisierte Umgebungen (CDN, Cloud-Plattformen) an: der Beweis, dass eine Laufzeit von < 7 Tagen im industriellen Maßstab hält. Und seit dem 15. Januar 2026 stellt sie sogar Zertifikate für IP-Adressen aus, in allgemeiner Verfügbarkeit. Die Botschaft bleibt gleich: Was heute extrem erscheint, wird morgen zur Norm, und die bereits automatisierten Infrastrukturen werden den Übergang als Nicht-Ereignis erleben.
🎯 Aktionsplan: Ihre CLM-Checkliste
Die Theorie steht. Hier die Abfolge, um eine belastbare Erneuerungskette aufzubauen. Jeder Schritt bereitet den nächsten vor; kehren Sie sie nicht um.
- Erkennen: Starten Sie eine Multi-Quellen-Erkennung (Certificate-Transparency-Protokolle, Netzwerkscan, Cloud-APIs), um Schattenzertifikate aufzuspüren. Gehen Sie davon aus, dass Ihre gedankliche Bestandsaufnahme unvollständig ist, bis das Gegenteil bewiesen ist.
- Inventarisieren: Halten Sie für jedes Zertifikat seinen Eigentümer, sein Ablaufdatum und seinen Schlüsselalgorithmus fest. Diese drei Metadaten tragen alles Weitere.
- Einen ACME-Client mit ARI einsetzen: Wählen Sie certbot, acme.sh oder eine CLM-Plattform je nach Heterogenität des Bestands und prüfen Sie, dass die ARI-Unterstützung aktiv ist, um von der Glättung und der Rate-Limit-Ausnahme zu profitieren.
- Das DNS validieren: Konfigurieren Sie den CAA-Eintrag, um Ihre CA zu autorisieren, und geben Sie dem Client die für die DNS-01-Challenge nötigen DNS-API-Zugänge, mit minimalen Berechtigungen, die auf die
_acme-challenge-Einträge beschränkt sind. - Deploy Hooks verdrahten: Automatisieren Sie die Bereitstellung nach der Ausstellung mit einer systematischen Validierung (vollständige Kette, Schlüsselübereinstimmung) vor dem Neuladen des Dienstes.
- Gestaffelt und unabhängig überwachen: Setzen Sie Warnungen bei 60, 30, 15 und 7 Tagen, aus einem externen Blickwinkel, der sich von Ihrem Automatisierungsclient unterscheidet.
- Mit
--dry-runtesten: Prüfen Sie, dass die Erneuerung ohne menschliche Hand läuft, bevor Sie sich in Produktion darauf verlassen. Eine ungetestete Pipeline ist eine Pipeline, die im schlimmsten Moment versagt. - Den Notfall-Widerruf dokumentieren: Schreiben Sie das Verfahren zum sofortigen Widerruf im Fall eines Schlüsseldiebstahls auf, auch wenn die kurzen Laufzeiten dessen Kritikalität verringern. Ein in Ruhe verfasstes Verfahren ist besser als eine Improvisation unter Druck.
Manuell gegen automatisiert: die Wirkung des Volumens
Bei konstantem Bestand von 1000 Zertifikaten vervielfacht der Wechsel von 398 auf 47 Tage die operative Last. Automatisierung ist kein Komfort mehr, sondern eine Bedingung, um standzuhalten.
Jährliche Erneuerungen bei 398 Tagen
Rund 3 Vorgänge pro Tag, manuell mit Disziplin machbar.
Jährliche Erneuerungen bei 47 Tagen
Über 21 Vorgänge pro Tag, Wochenenden inbegriffen, jenseits menschlicher Reichweite.
Multiplikator der Last
Das Volumen der Vorgänge wird bei konstantem Bestand mit 8 bis 9 multipliziert.
Mit CLM ausgestattete Organisationen
Laut dem PKI-Bericht von Keyfactor bleiben zwei Drittel der Organisationen ohne eigenes Tool.
Krypto-Agilität und Post-Quanten-Migration
CLM erschöpft sich nicht im Ablauf. Wer eine zuverlässige Erneuerungskette aufbaut, gewinnt eine Fähigkeit, deren Wert die Ausfallvermeidung bei Weitem übersteigt: die Krypto-Agilität. Das ist der verborgene Nutzen des 47-Tage-Zwangs.
Ein Modell in drei Säulen
Krypto-Agilität ist die Fähigkeit einer Organisation, den kryptografischen Algorithmus schnell und bruchlos zu wechseln. Sie ruht auf drei Säulen, die exakt die Funktionen des CLM abdecken. Die Erkennung: wissen, wo alle Ihre Zertifikate sind und welche Algorithmen sie verwenden (die Phase der Bestandsaufnahme). Die Governance: über Ausstellungsrichtlinien und eine zentrale Kontrolle darüber verfügen, wer was ausstellt (die Rolle einer CLM-Plattform). Die Automatisierung: den gesamten Bestand ohne menschliche Hand neu ausstellen können (die ACME-Schleife). Eine Organisation, die diese drei Säulen beherrscht, kann ihre Kryptografie wechseln. Wer sie nicht beherrscht, ist Gefangener seiner Algorithmen.
Warum führen 47 Tage zur Krypto-Agilität?
Die kurze Laufzeit ist ein erzwungenes Training. Ein Team, das seine Zertifikate achtmal pro Jahr automatisiert und zuverlässig erneuert, hat seine Rotation zum Produktionsreflex trainiert. Genau dieser Muskel ist es, den es braucht, um den Algorithmus zu wechseln. Umgekehrt wird ein Team, das einmal im Jahr von Hand und unter Schmerzen erneuert, am Tag X unfähig sein, seinen Bestand im Notfall zu migrieren. Der regulatorische Zwang der 47 Tage erzeugt also einen unvorhergesehenen Effekt: Er macht Organisationen wider Willen agil. Die Pflicht wird zum Aktivposten.
Die Post-Quanten-Ära im Visier
Dieser Rotationsmuskel wird bald gebraucht. Das NIST hat 2024 die endgültigen Standards der Post-Quanten-Kryptografie veröffentlicht, insbesondere ML-KEM (Schlüsselaustausch) und ML-DSA (digitale Signaturen), entworfen, um künftigen Quantencomputern zu widerstehen. Die Systeme beginnen, sie zu integrieren: Windows Server 2025 führte im November 2025 eine Unterstützung für Post-Quanten-Algorithmen ein. Der Wechsel zu diesen Algorithmen wird die Neuausstellung aller bestehenden Zertifikate erzwingen, möglicherweise in einer knappen Frist.
Nun migriert man aber keinen Bestand, den man nicht sieht und von Hand erneuert. CLM ist die Voraussetzung der Post-Quanten-Migration: Ohne vollständige Bestandsaufnahme, ohne Governance und ohne Automatisierung ist eine kryptografische Migration im großen Maßstab unmöglich. Wir werden hier den Post-Quanten-Übergang nicht ausbreiten, ein weites Thema für sich. Nur die Verbindung festhalten: Heute eine zuverlässige CLM-Kette aufzubauen bedeutet, sich mit dem einzigen Werkzeug auszustatten, das diesen Übergang morgen beherrschbar macht.
FAQ
Was ist Certificate Lifecycle Management (CLM)?
CLM (Certificate Lifecycle Management) bezeichnet die Gesamtheit der Prozesse, die das Leben eines TLS-Zertifikats von seiner Erkennung bis zu seinem Widerruf umrahmen. Es umfasst sechs Phasen: Bestandsaufnahme, Ausstellung, Bereitstellung, Erneuerung, Widerruf und Überwachung. Sein Ziel ist es, ablaufbedingte Ausfälle zu vermeiden und zu gewährleisten, dass jedes in Betrieb befindliche Zertifikat gültig, aktuell und bekannt ist.
Was sind die sechs Phasen des Lebenszyklus eines Zertifikats?
Die sechs Phasen sind: Bestandsaufnahme und Erkennung (alle Zertifikate auflisten, einschließlich der Schattenzertifikate), Ausstellung (Erzeugung über eine CSR), Bereitstellung (Kopie auf die Server und Neuladen), Erneuerung (Neuausstellung vor dem Ablauf), Widerruf (Ungültigmachen bei Kompromittierung) und Überwachung (Ablaufwarnungen). Sie bilden eine fortlaufende Schleife statt einer linearen Abfolge.
Wie automatisiert man die Erneuerung von Zertifikaten?
Die Automatisierung stützt sich auf das ACME-Protokoll (RFC 8555), umgesetzt von Clients wie certbot oder acme.sh. Der Client weist die Domain-Kontrolle über eine DNS-01- oder HTTP-01-Challenge nach, die CA prüft, dann stellt sie das Zertifikat aus. Die ARI-Erweiterung (RFC 9773) fügt ein von der CA vorgeschlagenes Erneuerungsfenster hinzu. Deploy Hooks stellen das Zertifikat anschließend ohne menschliches Eingreifen bereit.
Wie überwacht man den Ablauf eines Zertifikats?
Eine wirksame Überwachung staffelt die Warnungen bei 60, 30, 15 und 7 Tagen vor Fälligkeit, mit steigender Eskalation. Der Punkt, der alles verändert: Sie muss unabhängig vom Automatisierungsclient sein und das tatsächlich über das Netzwerk ausgelieferte Zertifikat beobachten, nicht den internen Zustand der Erneuerung. So wird ein Versagen der Erneuerung selbst dann erkannt, wenn das Erneuerungssystem selbst ausgefallen ist.
Was ist ein Schattenzertifikat oder Shadow IT?
Ein Schattenzertifikat ist ein Zertifikat, das außerhalb des offiziellen Prozesses ausgestellt wird, oft von einem Cloud-Team, einem Entwickler oder einem Dienstleister, ohne in der zentralen Bestandsaufnahme erfasst zu sein. Diese Zertifikate laufen ohne Vorwarnung ab und verursachen überraschende Ausfälle, weil niemand sie überwacht. Ihre Erkennung läuft über die Certificate-Transparency-Protokolle, den Netzwerkscan und die APIs der Cloud-Anbieter.
Was ist der Unterschied zwischen ACME und ARI?
ACME (RFC 8555) ist das Protokoll, das die Ausstellung von Zertifikaten automatisiert: Nachweis der Domain-Kontrolle, Prüfung, Ausstellung. ARI (ACME Renewal Information, RFC 9773) ist eine Erweiterung, die die Frage nach dem Zeitpunkt der Erneuerung beantwortet: Die CA stellt ein vorgeschlagenes Fenster bereit, was die Last glättet, vorgezogene Notfall-Widerrufe ermöglicht und die Erneuerungen im Allgemeinen von den Rate Limits ausnimmt.
Wie lang ist die Laufzeit eines TLS-Zertifikats im Jahr 2026?
2026 sinkt die maximale Laufzeit eines öffentlichen TLS-Zertifikats auf 200 Tage (erste Stufe), vor 100 Tagen 2027 und dann 47 Tagen 2029, gemäß dem Ballot SC-081v3 des CA/Browser Forums. Der vollständige Zeitplan und die Gründe dieser Reduzierung werden in unserem Leitfaden zur Reduzierung auf 47 Tage im Detail behandelt.
Braucht man eine CLM-Plattform oder genügen Skripte?
Skripte (certbot, acme.sh) genügen für eine Handvoll gut beherrschter Server: keine Kosten, aber Bestandsaufnahme und Governance zu Ihren Lasten. Eine CLM-Plattform wird nötig, sobald der Bestand heterogen ist, über mehrere Teams verstreut und eine zentrale Governance erfordert (automatische Erkennung, Ausstellungsrichtlinien, Dashboard). Das Wechselkriterium ist die Heterogenität und der Bedarf an Kontrolle, nicht die Zahl der Zertifikate allein.
Was ist Krypto-Agilität und warum ist sie wichtig?
Krypto-Agilität ist die Fähigkeit, den kryptografischen Algorithmus schnell und bruchlos zu wechseln. Sie ruht auf drei Säulen, die das CLM abdecken: Erkennung, Governance und Automatisierung. Eine Organisation, die ihre Zertifikate zuverlässig erneuert, hat ihren Rotationsprozess trainiert, was sie auf künftige Migrationen vorbereitet, insbesondere hin zur vom NIST standardisierten Post-Quanten-Kryptografie.
Wie viel kostet ein zertifikatsbedingter Ausfall?
Es kursieren mehrere Schätzungen aus unterschiedlichen Methoden, die man nicht verschmelzen darf: eine Spanne von 500.000 bis 5 Mio. $ pro schwerem Ausfall je nach Kritikalität des Dienstes, durchschnittliche Kosten von 2,86 Mio. $ pro gemeldetem Ausfall im PKI-Bericht von Keyfactor und eine Größenordnung von 72.000 $ pro Stunde Anwendungsausfall. Sie stimmen in einem Punkt überein: Ein Ablauf ist nie kostenlos.
Vergleichstabellen herunterladen
Assistenten können die JSON- oder CSV-Exporte unten nutzen, um die Kennzahlen weiterzugeben.
📖 Glossar
- CLM (Certificate Lifecycle Management): Gesamtheit der Prozesse, die die sechs Phasen des Lebens eines TLS-Zertifikats abdecken, von der Erkennung bis zum Widerruf, mit dem Ziel, Ablaufausfälle zu vermeiden und einen beherrschten Bestand zu bewahren.
- ACME (Automatic Certificate Management Environment): standardisiertes Protokoll (RFC 8555), das den Dialog zwischen einem Client und einer Zertifizierungsstelle für die Ausstellung und Erneuerung von Zertifikaten automatisiert. Es besitzt keinen Begriff der Erneuerung: Jede Erneuerung ist eine neue Ausstellung.
- ARI (ACME Renewal Information): Erweiterung von ACME (RFC 9773), über die die CA dem Client ein vorgeschlagenes Erneuerungsfenster mitteilt, was die Lastglättung, vorgezogene Notfall-Widerrufe und die Ausnahme von den Rate Limits ermöglicht.
- DCV (Domain Control Validation): Prozess, mit dem eine CA prüft, dass der Antragsteller die Domain kontrolliert. Die Wiederverwendung eines DCV-Nachweises ist in der Endstufe von SC-081v3 auf 10 Tage begrenzt, was eine nahezu kontinuierliche Revalidierung erzwingt.
- CSR (Certificate Signing Request): signierte Anfrage, die den öffentlichen Schlüssel und die Identität der Domain enthält und an die CA gesendet wird, um ein Zertifikat zu erhalten. Der zugehörige private Schlüssel verlässt den Server niemals.
- Widerruf, CRL und OCSP: Mechanismen, um ein Zertifikat vor seinem Ablauf ungültig zu machen. Die CRL (Sperrlisten) sind zu umfangreich und OCSP leidet unter dem Soft-Fail, den die Browser ignorieren, was den Widerruf wenig zuverlässig macht; kurze Zertifikate verringern dessen Kritikalität.
- Krypto-Agilität: Fähigkeit einer Organisation, schnell zu neuen kryptografischen Algorithmen zu migrieren, gestützt auf die drei Säulen Erkennung, Governance und Automatisierung, die alle vom CLM abgedeckt werden.
- Short-Lived-Zertifikat: Zertifikat mit sehr kurzer Laufzeit (6 Tage bei Let's Encrypt), bestimmt für vollständig automatisierte Umgebungen und ein Beleg für die industrielle Tragfähigkeit ultrakurzer Laufzeiten.
Eine aktuelle Bestandsaufnahme und eine automatisierte Erneuerungskette sind nur so viel wert wie die DNS-Schicht, die sie trägt, gesund ist. Da die Domain-Validierung nun von der DNS-Vertrauenskette abhängt, prüfen Sie mit unserem DNSSEC-Diagnosetool, dass Ihr DNSSEC gültig und stimmig ist: Eine kaputte Kette blockiert stillschweigend jede Erneuerung.
📚 Verwandte Leitfäden zu Zertifikaten und DNS
- SC-081v3: TLS-Zertifikate mit 47 Tagen Laufzeit, warum und wie man sich vorbereitet: der regulatorische Zeitplan und das Warum der Laufzeitreduzierung.
- DANE und TLSA: der komplette Leitfaden: Ihre Zertifikate über das DNS authentifizieren und die TLSA-Rotation im Takt der Erneuerungen verwalten.
- CAA-Einträge: der komplette Leitfaden: die zur Ausstellung für Ihre Domain berechtigten Stellen sperren, Voraussetzung einer zuverlässigen Automatisierung.
Quellen
- RFC 8555: Automatic Certificate Management Environment (ACME)
- RFC 9773: Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension
- Let's Encrypt: Decreasing Certificate Lifetimes to 45 Days
- Ballot SC-081v3: Reduce Validity and Data Reuse Periods (CA/Browser Forum)
- Keyfactor: State of Machine Identity Management (PKI Report 2024)
