47-Tage-TLS-Zertifikate: Wie DigiCert die eigene Infrastruktur modernisierte

Der Wechsel auf 47-tägige TLS-Zertifikatslebenszyklen stellt Unternehmen vor erhebliche operative Herausforderungen. DigiCert hat diesen Übergang zunächst im eigenen Haus vollzogen – unter dem Projektnamen „Customer Zero“. Welche strukturellen Hürden dabei auftraten, welche Lösungsansätze sich bewährt haben und was andere Organisationen daraus für ihre eigene Modernisierung ableiten können, zeigt der erste Teil einer zweiteiligen Einblicksserie.

Vom internen Testfall zur Blaupause

Als einer der zentralen Akteure im globalen Trust-Ökosystem nimmt DigiCert eine besondere Rolle ein: Das Unternehmen gestaltet Branchenstandards aktiv mit – und ist ihnen gleichzeitig selbst verpflichtet. Mit der bevorstehenden Umstellung auf 47-tägige TLS-Zertifikatslebenszyklen entstand daraus eine klare Konsequenz: DigiCert wollte den Übergang nicht nur begleiten, sondern ihn zuerst in der eigenen Infrastruktur unter Realbedingungen erproben.

So entstand die Initiative „Customer Zero“ – ein internes Modernisierungsprojekt, das auf dem DigiCert Trust Lifecycle Manager (TLM) aufbaut und als Grundlage für die spätere Kundenberatung dienen soll. Der Ansatz folgt einer einfachen Logik: Wer Empfehlungen ausspricht, sollte den beschriebenen Weg selbst gegangen sein.

Gewachsene Strukturen als Ausgangsproblem

Die Ausgangslage zu Beginn des Projekts entsprach dem, was in vielen größeren Unternehmen anzutreffen ist – einschließlich solcher, die selbst als Zertifizierungsstellen agieren. Die Zertifikatsverwaltung hatte sich über Jahre hinweg organisch und dezentral entwickelt, begleitet von Unternehmenswachstum, Teamwechseln und dem schrittweisen Einsatz unterschiedlicher Werkzeuge. Konkret bedeutete das:

• Mehrere CertCentral-Konten, die parallel genutzt wurden
• Zertifikatsbestände, die über Skripte, Tabellenkalkulationen und verschiedene Tools verteilt verwaltet wurden
• Unterschiedliche Transparenz- und Konsistenzgrade je nach Team und Anwendungsfall
• Eigentumsmodelle, die zwar existierten, aber nicht einheitlich gepflegt wurden

Eine umfassende Bestandsaufnahme der gesamten Umgebung bestätigte das Bild: Ohne zentrale Übersicht, klar definierte Verantwortlichkeiten und weitreichende Automatisierung lässt sich eine wachsende Zertifikatsinfrastruktur langfristig nicht zuverlässig betreiben. Bei sinkenden Zertifikatslaufzeiten und steigendem Erneuerungsvolumen verschärft sich dieses Problem spürbar. Die Modernisierung war damit kein optionaler Schritt, sondern eine betriebliche Notwendigkeit.

Zentralisierung als strukturelle Grundlage

Die erste und folgenreichste architektonische Entscheidung des Projekts war die Einrichtung eines einzigen autoritativen Aufzeichnungssystems. Alle Zertifikatsaktivitäten wurden in einem zentralen TLM-Mandanten konsolidiert. Um die operative Eigenständigkeit der einzelnen Teams zu erhalten, wurden diese verschiedenen Geschäftseinheiten zugeordnet – mit der Möglichkeit, innerhalb definierter Grenzen autonom zu agieren, während übergreifende Richtlinien und Reporting-Strukturen zentral durchgesetzt wurden.

Der Aufbau folgte einer klar definierten Abfolge, von der nicht abgewichen wurde:

1. Bestandsaufnahme – vollständige Erfassung aller Zertifikate und Eigentumsverhältnisse
2. Richtlinien – Festlegung verbindlicher Vorgaben für Ausstellung, Erneuerung und Verwaltung
3. Automatisierung – technische Umsetzung auf Basis der bereinigten Datenbasis
4. Beobachtbarkeit – Aufbau von Monitoring und Betriebssignalen

Die Reihenfolge war kein formaler Schritt, sondern aus konkreten Überlegungen abgeleitet: Automatisierung ohne vollständigen und bereinigten Bestand erzeugt Fehlsteuerung statt Effizienz. Richtlinien ohne klar zugewiesene Verantwortlichkeiten bleiben ohne Wirkung. Das Fundament musste zuerst stehen.

Bestandsaufnahme: aufwendiger als die Automatisierung selbst

Was auf den ersten Blick wie ein administrativer Vorbereitungsschritt wirkte, erwies sich als der zeitaufwendigste Teil des Projekts. Die Inventur legte zahlreiche Inkonsistenzen offen, die sich über die Jahre angesammelt hatten – sogenannte „Geister“ im System:

• Duplikate: Dasselbe Zertifikat war in mehreren Systemen erfasst, was zu widersprüchlichen Verlängerungsbenachrichtigungen führte
• Veraltete Einträge: Widerrufene Zertifikate wurden noch als aktiv gelistet
• Verwaiste Artefakte: Abgelaufene Zertifikate verblieben auf Endpunkten, ohne dass ein Eigentümer zugeordnet werden konnte

Die eingesetzten Sensoren arbeiteten dabei präzise – in einigen Fällen so präzise, dass identische Zertifikate mehrfach erfasst wurden, was die Anzahl der ausgelösten Warnmeldungen in die Höhe trieb und eine zunehmende Eskalationsmüdigkeit bei den zuständigen Teams erzeugte. Relevante Hinweise drohten im Rauschen unterzugehen.

Die Bereinigung erforderte ein Maß an Tagging-Disziplin, das typischerweise bei der Pflege einer CMDB (Configuration Management Database) anzutreffen ist. Die zentrale Erkenntnis: Die Qualität der Bestandsdaten bestimmt unmittelbar die Qualität der darauf aufbauenden Automatisierung. Fehlerhafte oder unvollständige Metadaten führen zu Fehlverlängerungen, falschen Zuordnungen oder – im ungünstigsten Fall – zu stillen Ausfällen, die erst bemerkt werden, wenn ein Dienst nicht mehr erreichbar ist. Solange Eigentumsverhältnisse nicht eindeutig geklärt waren, konnte der Erneuerungsrhythmus nicht sicher beschleunigt werden.

Automatisierung: klare Erfolge, hartnäckige Ausnahmen

Nach der Stabilisierung des Bestands wurde eine protokollorientierte Automatisierungsstrategie eingeführt, die auf bewährten Industriestandards aufbaute:

• ACME für Webserver und moderne Plattformen
• SCEP und EST für Geräteidentitäten
• Konnektoren und APIs für Endpunkte, auf denen kein Agent betrieben werden kann

Die Ergebnisse waren deutlich: Rund 50 Prozent der Systeme unterstützten ACME ohne zusätzlichen Konfigurationsaufwand. Weitere 40 Prozent ließen sich über SCEP oder EST anbinden. Für diese Systeme verlief der Übergang reibungslos – nach der Einrichtung wurde die Erneuerung zum automatisierten Hintergrundprozess, der keine manuelle Aufmerksamkeit mehr erforderte.

Die verbleibenden zehn Prozent stellten die eigentliche Herausforderung dar. Diese Systeme – überwiegend ältere Plattformen mit eingeschränkter Protokollunterstützung – erforderten entweder individuelle Skripte oder manuelle Koordination. Bei jährlichen Zertifikatszyklen ist dieser Mehraufwand handhabbar. Bei einem Intervall von 47 Tagen vervielfacht sich der Aufwand entsprechend: Systeme, die kein Standardprotokoll wie ACME unterstützen, erzeugen einen dauerhaften und mit der Zeit wachsenden operativen Widerstand, der sich ohne gezielte Maßnahmen nicht abbauen lässt.

Betriebliche Schwachstellen unter kürzeren Laufzeiten

Der interne Echtbetrieb machte operative Engpässe sichtbar, die bei längeren Zertifikatslaufzeiten kaum ins Gewicht fallen, bei häufigeren Zyklen jedoch zu strukturellen Problemen werden:

• API-Ratenlimits: Schwellenwerte, die für Jahreszyklen ausgelegt wurden, werden bei einem 47-Tage-Rhythmus zum Engpass – nicht weil die Limits falsch gesetzt sind, sondern weil das Anfragevolumen grundlegend anders ist
• Stille Ausfälle: Automatisierungsaufträge wechselten ohne klares Fehlersignal in den Wartestatus, was die Fehlersuche erschwerte und Reaktionszeiten verlängerte
• Benachrichtigungsmüdigkeit: Eine hohe Anzahl von Warnmeldungen überlagerte tatsächlich relevante Hinweise und erhöhte das Risiko, dass wichtige Signale übersehen wurden

Besonders deutlich wurde ein systemisches Muster: Automatisierungskomponenten wie Sensoren, Konnektoren und Agenten können nicht als wartungsfreie Einmalinstallationen betrachtet werden. Sie sind Produktionsabhängigkeiten, die aktiv überwacht, gepflegt und in reguläre Betriebszyklen eingebunden werden müssen.

Gleichzeitig verändert sich das Zeitfenster für die Fehlerkorrektur grundlegend. Bei einem Jahreszyklus bleibt bei einer verzögerten Erneuerung ausreichend Zeit für eine ruhige Analyse und Korrektur. Bei 47 Tagen führt dieselbe Verzögerung innerhalb kurzer Zeit zu einem Ausfall – ohne dass manuelle Eingriffe das Problem noch rechtzeitig auffangen können.

Vom Einzeleinsatz zur institutionellen Routine

Der tiefgreifendste Wandel im Rahmen von Customer Zero war nicht technischer, sondern organisatorischer Natur. Im bisherigen Betriebsmodell mit Jahreszertifikaten war es durchaus üblich, ein drohendes Ablaufdatum durch kurzfristigen Einzeleinsatz erfahrener Mitarbeitender aufzufangen. Dieser Ansatz war stressig, funktionierte aber – weil er selten gefragt war.

Auf einen 47-Tage-Rhythmus übertragen ist dieses Modell nicht tragfähig. Der Erneuerungsaufwand steigt auf das Achtfache, ohne dass die Kapazitäten entsprechend wachsen. Die Folge wäre eine dauerhafte Überlastung, eine erhöhte Fehleranfälligkeit durch Zeitdruck und letztlich ein höheres Ausfallrisiko als im Ausgangszustand.

DigiCert hat daraus operative Konsequenzen gezogen und individuelle Ausnahmen durch verbindliche Standards ersetzt:

• Einheitliche Laufzeiten: Alle öffentlichen Zertifikate werden auf 47-Tage-Zyklen umgestellt, um Sonderfälle und damit verbundene Ausnahmebehandlungen zu vermeiden
• Verpflichtende Modernisierung: TLS 1.3 ist auf allen Endpunkten standardmäßig aktiviert
• Richtliniengesteuertes Gateway: Der TLM dient als einziger, zentral verwalteter Ausstellungspunkt für jedes Zertifikat – ohne Umgehungsmöglichkeiten

Erneuerungen werden nicht mehr als Notfallprojekte behandelt, sondern als routinemäßiger Betriebsvorgang, der ohne manuellen Eingriff abläuft.

Ergebnisse im laufenden Betrieb

Die Umstellung zeigt messbare Wirkung: Über 99 Prozent der berechtigten Zertifikate in der DigiCert-Produktionsumgebung werden inzwischen automatisch erneuert. Manuelle Eingriffe sind die Ausnahme und lassen sich überwiegend auf Einschränkungen bei Drittanbietersystemen zurückführen – nicht auf interne Lücken. Trotz der gestiegenen Erneuerungsfrequenz bleibt die operative Stabilität konstant. Diese Konsistenz ist die Grundlage dafür, dass ein 47-Tage-Rhythmus im laufenden Betrieb ohne erhöhte Volatilität funktioniert.

Im zweiten Teil der Serie werden der messbare Geschäftsnutzen, die Risikoreduzierung sowie die tatsächlichen Kostenstrukturen der Automatisierung im 47-Tage-Modell beleuchtet.

Auch interessant:

---

Bild/Quelle: https://depositphotos.com/de/home.html

Folgen Sie uns auf X

Folgen Sie uns auf Bluesky

Folgen Sie uns auf Mastodon

Hamsterrad Rebell – Cyber Talk