Was sind 47-Tage-Zertifikate: Was ändert sich, warum ist das wichtig und wie kann man sich darauf vorbereiten?

DasCertification Authority/Browser (CA/B) Forum hat offiziell eine Verkürzung der maximalen Gültigkeitsdauer für öffentlich vertrauenswürdige TLS auf nur noch 47 Tage bis 2029 beschlossen. Diese Änderung bedeutet eine grundlegende Umstellung für Unternehmen im Hinblick auf das Zertifikatslebenszyklusmanagement (CLM). Die Sicherheitsvorteile liegen auf der Hand, doch die betrieblichen Auswirkungen sind erheblich. Unternehmen, die sich auf manuelle Prozesse verlassen, werden diese neue Realität als untragbar empfinden, sodass Automatisierung und Governance nicht nur empfohlene Praktiken, sondern betriebliche Notwendigkeiten sind. 

Was sind 47-Tage-Zertifikate und welche Zertifikate sind davon betroffen?

Die 47-Tage-Zertifikatsvorschrift gilt speziell für öffentlich vertrauenswürdige TLS – die digitalen Berechtigungsnachweise, die Websites, öffentlich zugängliche Anwendungen und bestimmte Edge-Infrastrukturen sichern. Diese Zertifikate authentifizieren Server und verschlüsseln Daten während der Übertragung und bilden damit das Rückgrat einer sicheren Internetkommunikation. 

• Öffentlich vertrauenswürdige TLS werden von Zertifizierungsstellen (CAs) ausgestellt, die von Browsern und Betriebssystemen standardmäßig erkannt werden. Sie ermöglichen sichere HTTPS-Verbindungen für externe Benutzer, ohne dass eine manuelle Vertrauenskontrolle erforderlich ist. Die 47-Tage-Beschränkung gilt ausschließlich für diese Zertifikate. 

• Private oder interne Zertifikate, die von der eigenen privaten PKI-Infrastruktur einer Organisation ausgestellt werden, sind von dieser Vorschrift nicht direkt betroffen. Organisationen können weiterhin interne Zertifikate mit längerer Gültigkeitsdauer ausstellen, wenn ihre Anwendungsfälle dies rechtfertigen. Viele sicherheitsbewusste Organisationen entscheiden sich jedoch dafür, bewährte Verfahren für öffentliche Zertifikate in ihrer privaten PKI zu übernehmen, um eine einheitliche Sicherheitsstrategie und einheitliche Betriebsprozesse zu gewährleisten. 

Die Einführung erfolgt schrittweise und nicht sofort auf 47 Tage: 

• März 2026: Die maximale Gültigkeitsdauer sinkt auf 200 Tage. 

• 2027: Weitere Reduzierung auf 100 Tage 

• 2029: Letzter Schritt hin zu einer maximalen Gültigkeitsdauer von 47 Tagen 

Diese Gültigkeitsdauer umfasst integrierte Verlängerungsfenster. Das 47-Tage-Zertifikat beispielsweise ist für eine geplante Betriebsdauer von etwa 30 Tagen plus einer Pufferzeit von 17 Tagen für Verlängerungsaktivitäten ausgelegt. Diese Struktur bedeutet, dass Unternehmen Zertifikate etwa einmal pro Monat verlängern müssen, was je nach der Höhe der Pufferzeit zu 8 bis 12 Verlängerungszyklen pro Jahr und Zertifikat führt. 

Die von dieser Änderung betroffenen Zertifikate gehören oft zu den wichtigsten Vermögenswerten eines Unternehmens. Sie befinden sich nicht isoliert auf einem einzelnen Webserver. Eine typische Bereitstellung kann Folgendes umfassen: 

• Webserver und Anwendungsserver 

• Lastenausgleichsmodule, die TLS beenden 

• Cloud-Workloads und containerisierte Anwendungen 

• Edge-Infrastruktur und Content Delivery Networks 

• API-Gateways und Microservices-Endpunkte 

Ein Zertifikat kann gleichzeitig an mehreren Standorten eingesetzt werden – beispielsweise auf einem Load Balancer, mehreren Anwendungsservern und Backup-Systemen. Diese Vielfältigkeit erhöht die operative Herausforderung häufiger Erneuerungen. 

Wie kam es zu dieser Umstellung von 10-Jahres-Zertifikaten auf 47 Tage?

Der Weg zu 47-Tage-Zertifikaten erstreckt sich über mehr als ein Jahrzehnt schrittweiser Reduzierungen: 

• Vor 2012: Zertifikate konnten 10 Jahre lang gültig sein. 

• 2012: Maximale Gültigkeitsdauer auf 5 Jahre reduziert 

• 2015: Weitere Reduzierung auf 3 Jahre 

• 2018: Rückgang auf 2 Jahre (825 Tage) 

• 2020: Derzeitiger Standard von 398 Tagen (ca. 13 Monate) 

• 2026–2029: Schrittweise Reduzierung auf 47 Tage 

Der Übergang zu 398 Tagen im Jahr 2020 liefert wichtige Erkenntnisse für die aktuelle Umstellung. Google schlug zunächst kürzere Zertifikatslaufzeiten vor und brachte die Maßnahme im CA/B-Forum zur Abstimmung. Der Vorschlag wurde abgelehnt. Apple kündigte jedoch unabhängig davon an, dass sein nativer Browser Safari keine Zertifikate mit einer Gültigkeitsdauer von mehr als 398 Tagen akzeptieren würde, wodurch die gesamte Branche unter Druck gesetzt wurde. Die Zertifizierungsstellen hatten keine andere Wahl, als sich daran zu halten, und andere Browser folgten diesem Beispiel. 

Die aktuelle Umstellung auf 47-Tage-Zertifikate folgt einem anderen Muster. Diesmal wird die Änderung durch die Zertifizierungsstellen im Rahmen eines formellen Abstimmungsprozesses vorangetrieben und nicht einseitig von einem Browserhersteller auferlegt. Apple hat den Antrag SC081v3 eingebracht, der einen stufenweisen Reduzierungsplan vorsieht, und dieser wurde im Rahmen des Abstimmungsprozesses des CA/B-Forums angenommen. Da Zertifizierungsstellen keine Zertifikate mehr ausstellen werden, die diese neuen Gültigkeitsdauerüberschreitungen überschreiten, haben Unternehmen keine andere Wahl, als sich anzupassen. 

Die Reaktionen der Branche sind gemischt. Während Sicherheitsanbieter und Zertifizierungsstellen die Änderung generell unterstützen, äußern Systemadministratoren und PKI-Teams erhebliche Bedenken. Online-Diskussionen zeigen die Spannung zwischen Sicherheitsidealen und betrieblichen Realitäten. Ein Administrator stellte die Frage, ob der nächste logische Schritt „Ein-Sekunden-Zertifikate“ sein würden, und betonte damit seine Frustration über das Tempo der Veränderungen. Andere wiesen darauf hin, dass viele Altsysteme und die aktuelle Infrastruktur automatisierte Verlängerungsprotokolle nicht von Haus aus unterstützen, was zu einem erheblichen technischen Schuldenproblem führt. 

Warum drängen Browser und Zertifizierungsstellen auf 47-Tage-Zertifikate?

Das Bestreben, auf 47-Tage-Zertifikate umzustellen, geht auf drei miteinander verbundene Ziele zurück, die über einfache Sicherheitsverbesserungen hinausgehen. 

Höhere Sicherheit und geringerer Explosionsradius 

Kürzere Zertifikatslaufzeiten verringern direkt das Zeitfenster, in dem Angreifer kompromittierte Zertifikate oder private Schlüssel ausnutzen können. Das Sicherheitsprinzip entspricht den Richtlinien zur Passwortrotation: Je häufiger sich Anmeldedaten ändern, desto weniger Zeit haben Angreifer, um gestohlene oder kompromittierte Anmeldedaten zu nutzen. 

Dies ist besonders relevant im Zusammenhang mit „Harvest now, decrypt later“-Angriffen. Angreifer mit ausreichenden Ressourcen können heute verschlüsselten Datenverkehr abfangen und speichern, in der Hoffnung, dass sie irgendwann die Entschlüsselungscodes erhalten oder dass Quantencomputer die aktuellen Verschlüsselungsalgorithmen angreifbar machen. Eine häufigere Schlüsselrotation erschwert die erfolgreiche Umsetzung dieser Strategie erheblich. Jedes neue Zertifikat verwendet ein neues Schlüsselpaar, wodurch die Menge des historischen Datenverkehrs, den ein einzelner kompromittierter Schlüssel entschlüsseln kann, begrenzt wird. 

Wenn Zertifikate kompromittiert werden – durch Serververletzungen, Fehlkonfigurationen oder Angriffe auf die Lieferkette – begrenzt eine kürzere Lebensdauer den Schaden. Ein kompromittiertes Zertifikat mit einer Gültigkeit von 47 Tagen stellt ein viel geringeres Risiko dar als eines, das ein Jahr lang gültig ist. 

Die Umstellung auf Automatisierung und moderne PKI-Verfahren erzwingen 

Apple und Google nutzen die Verkürzung der Zertifikatslaufzeit ausdrücklich als Mechanismus, um die Branche zuCLM automatisiertenCLM zu bewegen. Manuelle Verlängerungsprozesse, die bei jährlichen Zertifikaten noch tolerierbar sein mögen, werden völlig unhaltbar, wenn Zertifikate alle paar Wochen erneuert werden müssen. 

Diese Zwangsfunktion ist beabsichtigt. Die manuelle Zertifikatsverwaltung in großem Maßstab führt zu menschlichen Fehlern, verursacht betriebliche Engpässe und macht Unternehmen anfällig für Ausfälle aufgrund abgelaufener Zertifikate. Indem manuelle Prozesse operativ unmöglich gemacht werden, zwingt die Branche Unternehmen effektiv dazu, moderne Automatisierungsverfahren einzuführen. 

Die Vorteile der Umstellung gehen über die reine Vermeidung von Ausfällen hinaus. Die automatisierte Zertifikatsverwaltung ermöglicht: 

• Konsequente Durchsetzung der Richtlinien für alle Zertifikate 

• Reduzierte Betriebskosten und weniger Burnout im Team 

• Bessere Übersicht über den Bestand und die Verwendung von Zertifikaten 

• Schnellere Reaktion auf Sicherheitsvorfälle, die einen Austausch von Zertifikaten erfordern 

• Stiftung für die Bewältigung künftiger kryptografischer Übergänge 

Vorbereitung auf Post-Quanten- und Krypto-Agilität 

Der Zeitpunkt der Frist 2029 ist kein Zufall. Das NIST hat einen Zeitplan für den Übergang zur Post-Quanten-Kryptografie (PQC) festgelegt, wobei 2030 als das Jahr markiert ist, in dem aktuelle Algorithmen wie RSA und ECC zugunsten quantenresistenter Alternativen auslaufen werden. 

Unternehmen, dieCLM 2029CLM automatisiert haben, werden für den Übergang zur Post-Quanten-Ära deutlich besser aufgestellt sein. Der Austausch kryptografischer Algorithmen in Tausenden oder Millionen von Zertifikaten erfordert dieselbe Automatisierungsinfrastruktur, die auch für häufige Erneuerungen benötigt wird. Die 47-tägige Zertifikatsfrist gibt Unternehmen im Wesentlichen fünf Jahre Zeit, um die Automatisierungsfähigkeiten aufzubauen, die sie für den Übergang zur Quanten-Ära benötigen. 

Krypto-Agilität – die Fähigkeit, kryptografische Algorithmen und Schlüsseltypen in einer gesamten Infrastruktur schnell zu ändern – wird zu einem Wettbewerbsvorteil und einer Sicherheitsnotwendigkeit. Unternehmen, die bis 2030 warten, um sich mit Automatisierung zu befassen, werden sich einem chaotischen Wettlauf um den Austausch von Algorithmen gegenübersehen und gleichzeitig kurzlebige Zertifikate verwalten müssen. 

Was wird sich durch 47-Tage-Zertifikate für PKI- und Systemadministrations-Teams im Alltag ändern?

Die operativen Auswirkungen von 47-Tage-Zertifikaten gehen weit über die einfache häufigere Erneuerung von Zertifikaten hinaus. Die Änderung wirkt sich grundlegend auf Arbeitsabläufe, Teamdynamik, Validierungsprozesse und Infrastrukturmanagement aus. 

Erneuerungshäufigkeit explodiert 

Die offensichtlichste Änderung ist die drastische Erhöhung der Erneuerungshäufigkeit. Unternehmen, die derzeit ihre Zertifikate jährlich erneuern, werden auf Erneuerungen alle paar Wochen umstellen. Ein Zertifikat, das zuvor einmal pro Jahr überprüft werden musste,erfordert nun8 bis 12 Erneuerungszyklen pro Jahr. 

Untersuchungen von Gartnerzeigen, dass die End-to-End-Zertifikatserneuerung – von der Generierung des Schlüsselpaars bis zur abschließenden Überprüfung der Bereitstellung – in der Regel 3 bis 6 Stunden manuellen Arbeitsaufwand erfordert. Dazu gehören: 

• Generieren des Schlüsselpaars auf dem Zielsystem 

• Erstellen und Senden der Zertifikatssignierungsanforderung (CSR) 

• Einholung der Genehmigung durch die zuständigen Interessengruppen 

• Warten auf CA-Validierung und Ausstellung 

• Herunterladen und Installieren des neuen Zertifikats 

• Überprüfung der ordnungsgemäßen Installation und Funktionalität 

• Möglicherweise Neustart der Dienste, um das neue Zertifikat zu aktivieren 

Multiplizieren Sie diese 3 bis 6 Stunden mit 8 bis 12 Erneuerungszyklen pro Zertifikat und anschließend mit der Gesamtzahl der öffentlich vertrauenswürdigen Zertifikate in Ihrer Umgebung. Für Unternehmen mit Hunderten oder Tausenden von öffentlichen Zertifikaten ist diese Berechnung ohne Automatisierung nicht mehr zu bewältigen. 

Operative Belastung und Burnout-Risiko 

Die Zertifikatsverwaltung obliegt selten ausschließlich dem PKI-Team. Der End-to-End-Prozess umfasst in der Regel: 

• PKI- oder Sicherheitsteams, die CA-Beziehungen und -Richtlinien verwalten 

• Anwendungsbesitzer, die Serviceabhängigkeiten verstehen 

• Infrastrukturteams, die Server und Load Balancer verwalten 

• Netzwerkteams, die sich mit DNS befassen 

• Change-Management-Teams, die Wartungsfenster koordinieren 

Jeder Erneuerungszyklus erfordert die Koordination zwischen diesen Gruppen. Der mehrstufige Charakter der Zertifikatserneuerung – Schlüsselgenerierung, CSR-Erstellung, CA-Validierung, Ausstellung, Bereitstellung, Überprüfung und mögliche Neustarts des Dienstes – schafft mehrere Punkte, an denen Verzögerungen oder Fehler auftreten können. 

Die menschlichen Kosten gehen über den Zeitaufwand für die Erneuerung hinaus. Ständiger Kontextwechsel, dringende Erneuerungsanfragen und der Stress, Ausfälle zu verhindern, tragen zur Erschöpfung des Teams bei. Wenn die Erneuerung von Zertifikaten zu einer wöchentlichen oder zweiwöchentlichen Aufgabe statt zu einem jährlichen Ereignis wird, kann dies die Bandbreite des Teams dominieren und die Arbeit an strategischen Initiativen verhindern. 

Validierungsfenster verkleinert sich 

Die Anforderungen an die Domainvalidierung (DV) werden ebenso wie die Gültigkeitsdauer von Zertifikaten verschärft. Derzeit bleibt die Validierung der Domain-Inhaberschaft in der Regel ein Jahr lang gültig. Nach dem neuen Rahmen sinkt die Gültigkeitsdauer der DV auf etwa 10 Tage. 

Das bedeutet, dass Unternehmen DNS oder HTTP-Validierungsdateien viel häufiger verwalten müssen. Für Unternehmen mit großen Domain-Portfolios bedeutet dies, dass die Validierung nicht mehr nur einmal im Jahr, sondern kontinuierlich durchgeführt werden muss. Der Validierungsprozess muss automatisiert werden, da er sonst zu einer weiteren manuellen Aufgabe wird, die nicht nachhaltig ist. 

Legacy- und Multi-Hop-Bereitstellungen werden offengelegt 

Viele Zertifikatsbereitstellungen sind komplexer, als sie erscheinen. Ein einzelnes Zertifikat muss möglicherweise auf folgenden Systemen installiert werden: 

• Ein Load Balancer, der TLS beendet 

• Mehrere Anwendungsserver hinter dem Load Balancer 

• Backup- oder Failover-Systeme 

• Entwicklungs- und Staging-Umgebungen, die die Produktion widerspiegeln 

Teilweise Erneuerungen – bei denen ein Zertifikat auf 9 von 10 Servern aktualisiert wird – bergen versteckte Ausfallrisiken. Der zehnte Server verwendet weiterhin das alte Zertifikat, bis es abläuft, und fällt dann aus. Bei jährlichen Erneuerungen können diese teilweisen Bereitstellungen monatelang unbemerkt bleiben. Bei monatlichen Erneuerungen steigt die Wahrscheinlichkeit von teilweisen Bereitstellungen und daraus resultierenden Ausfällen dramatisch an. 

Das 47-tägige Mandat wird diese komplexen, mehrstufigen Bereitstellungsmuster aufdecken und Unternehmen dazu zwingen, sie ordnungsgemäß zu dokumentieren und zu automatisieren. 

Was sind die größten Risiken, wenn Sie sich nicht anpassen? 

Unternehmen, die sich nicht auf 47-Tage-Zertifikate vorbereiten, sind mit verschiedenen Risiken konfrontiert, die von Betriebsstörungen bis hin zu strategischen Schwachstellen reichen. 

Ausfälle aufgrund abgelaufener oder teilweise erneuerter Zertifikate 

Ausfälle aufgrund abgelaufener Zertifikate folgen einem vorhersehbaren Muster: Ein kritisches System funktioniert nicht mehr, Benutzer können keine Verbindung herstellen, es entstehen Umsatzverluste und Teams bemühen sich, die Ursache zu ermitteln. Schließlich entdeckt jemand ein abgelaufenes Zertifikat. Zu diesem Zeitpunkt haben alle, die an der Reaktion auf den Vorfall beteiligt waren, bereits Stunden verschwendet, und das Unternehmen hat einen Reputations- und finanziellen Schaden erlitten. 

Das „Schwarze-Peter-Spiel bei Zertifikatsausfällen“ ist in IT-Kreisen zu einem Running Gag geworden: Wenn ein System ausfällt, verstecken sich alle und versuchen herauszufinden, wer dafür verantwortlich ist. Unweigerlich wird das PKI-Team beschuldigt, selbst wenn die eigentliche Ursache ein fehlender Prozess, eine unzureichende Dokumentation oder unklare Zuständigkeiten waren. 

Bei 47-Tage-Zertifikaten steigt die Häufigkeit potenzieller Ausfälle proportional, wenn die Prozesse manuell bleiben. Die wichtigsten Zertifikate – diejenigen, die kundenorientierte Dienste und kritische Geschäftsanwendungen sichern – sind diejenigen, die bei Ablauf am ehesten zu sichtbaren, kostspieligen Ausfällen führen. 

Schatten-IT und nicht genehmigte Käufe öffentlicher Zertifikate 

Wenn die offiziellen Verfahren zur Beschaffung von Zertifikaten langsam oder umständlich sind, umgehen Geschäftsbereiche diese oft vollständig. Anwendungsinhaber, die „nicht auf das PKI-Team warten können“, wenden sich direkt an eine öffentliche Zertifizierungsstelle und kaufen Zertifikate mit Firmenkreditkarten. 

Diese Schattenzertifikate existieren außerhalb der offiziellen Inventarisierungs- und Verwaltungssysteme. Sie unterliegen denselben 47-tägigen Gültigkeitsbeschränkungen wie offiziell verwaltete Zertifikate, sind jedoch weder automatisiert noch sichtbar. Wenn sie ablaufen, erhält niemand eine Benachrichtigung, und es gibt keinen Verlängerungsprozess. 

Das 47-tägige Mandat wird wahrscheinlich zunächst zu einem Anstieg der Käufe von Schatten-IT-Zertifikaten führen, da Teams nach schnellen Lösungen für häufige Verlängerungsanforderungen suchen. Unternehmen müssen die offizielle Beschaffung von Zertifikaten schnell und einfach gestalten, sonst verlieren sie den Überblick über einen erheblichen Teil ihres Zertifikatsbestands. 

Wildcard-Zertifikate als Single Points of Failure 

Wildcard-Zertifikate, die alle Subdomains unter einer Domain (*.example.com) sichern, sind zwar praktisch, bergen jedoch ein konzentriertes Risiko. Ein einziges Wildcard-Zertifikat kann auf Hunderten von Servern und Diensten eingesetzt werden. 

Wenn ein Wildcard-Zertifikat abläuft, fallen alle Systeme, die es verwenden, gleichzeitig aus. Ein Spieleanbieter dokumentierte seine Erfahrungen mit dem Ablauf eines Wildcard-Zertifikats, wodurch seine gesamte Backend-Infrastruktur ausfiel und Tausende von Benutzern betroffen waren. Der Vorfall wurde zu einer öffentlichen Fallstudie darüber, was man mit Wildcard-Zertifikaten nicht tun sollte. 

Das 47-tägige Mandat erhöht das Risiko von Wildcard-Zertifikaten. Je häufiger ein Zertifikat erneuert werden muss, desto größer ist die Wahrscheinlichkeit, dass die Erneuerung fehlschlägt. Ein Wildcard-Zertifikat, das an 100 Standorten eingesetzt wird, muss jeden Monat erfolgreich erneuert und an allen 100 Standorten eingesetzt werden. Wenn auch nur eines davon fehlt, kommt es zu einer unvollständigen Bereitstellung, die zu einem Ausfall führen kann. 

Post-Quanten-Scramble im Jahr 2030 

Unternehmen, die bis 2029 keine Automatisierung des Zertifikatslebenszyklus implementiert haben, werden 2030 mit einer Krise konfrontiert sein, wenn die Umstellung auf Post-Quanten-Kryptografie beginnt. Es ist schlichtweg nicht machbar, Tausende von Zertifikaten durch neue Algorithmen zu ersetzen und gleichzeitig deren 47-tägige Lebensdauer manuell zu verwalten. 

Unternehmen, die jetzt in Automatisierung investieren, werden den Übergang zur Post-Quanten-Ära als Konfigurationsänderung behandeln – sie aktualisieren die Algorithmusparameter und überlassen die Einführung der Automatisierung. Unternehmen ohne Automatisierung stehen vor einem mehrjährigen Projekt, bei dem sie jedes Zertifikat manuell ersetzen und gleichzeitig versuchen müssen, die Automatisierung zu implementieren, die sie schon vor Jahren hätten einführen sollen. 

Wo stehen die meisten Organisationen heute? 

Das Verständnis des aktuellen Stands der Zertifikatsverwaltung in den meisten Unternehmen hilft dabei, die bevorstehende Herausforderung in einen Kontext zu setzen. Trotz der Fortschritte in der PKI-Technologie verlassen sich viele Unternehmen nach wie vor auf veraltete Ansätze. 

Fragmentierte Tools und Sichtbarkeitslücken 

Typische Zertifikatsverwaltungsumgebungen bestehen aus: 

• Tabellenkalkulationen zur Verfolgung des Zertifikatsbestands (oft veraltet) 

• Von einzelnen Teams gepflegte Ad-hoc-Datenbanken 

• Netzwerk-Scan-Tools, die Zertifikate im Netzwerk erkennen 

• Mehrere CA-Portale für verschiedene Zertifikatsanbieter 

• Benutzerdefinierte Skripte für bestimmte Anwendungsfälle 

Keines dieser Tools bietet vollständige Echtzeit-Transparenz. Die wichtigsten Zertifikate – diejenigen, die kritische Dienste sichern – fehlen oft in offiziellen Bestandsaufnahmen. Ein Fachmann drückte es so aus: „Die wichtigsten Zertifikate sind diejenigen, die nicht in Ihrer Tabelle aufgeführt sind.“ 

Keine klare Eigentumsverhältnisse oder Verantwortlichkeiten 

In vielen Unternehmen ist die Verantwortung für Zertifikate auf mehrere Teams verteilt, ohne dass eine klare Zuständigkeit besteht. Das PKI-Team verwaltet möglicherweise die Beziehungen zu Zertifizierungsstellen, aber Anwendungsteams fordern Zertifikate an und installieren sie, Infrastrukturteams verwalten Server und Sicherheitsteams legen Richtlinien fest. 

Diese Diffusion der Verantwortung führt zu einer Tragödie der Allmende: Wenn jeder Zertifikate besitzt, besitzt niemand Zertifikate. Wenn etwas schiefgeht, wird Schuldzuweisung zur Standardreaktion, anstatt dass systematisch nach Lösungen gesucht wird. 

Manuelle, inkonsistente Prozesse 

Selbst Organisationen mit definierten Zertifikatsprozessen sind oft stark auf manuelle Schritte angewiesen: 

• Anwendungsbesitzer generieren manuell CSRs mit inkonsistenten Informationen. 

• Genehmigungsworkflows umfassen E-Mail-Ketten und Aktualisierungen von Tabellenkalkulationen. 

• Die Installation des Zertifikats erfordert manuelle SSH-Sitzungen oder RDP-Verbindungen. 

• Die Überprüfung hängt davon ab, dass Administratoren Dienste manuell testen. 

• Verlängerungen werden in Kalendern und Erinnerungssystemen nachverfolgt. 

Menschliche Fehler bei der Erstellung von CSR – Tippfehler in Domainnamen, falsche Schlüsselgrößen, fehlende alternative Namen – führen zu Verzögerungen und Nacharbeiten. Manuelle Prozesse sind zudem langsam, was zu Reibungen zwischen Sicherheitsteams, die Richtlinien durchsetzen wollen, und Anwendungsteams, die Dienste schnell bereitstellen wollen, führt. 

Übermäßige Abhängigkeit von öffentlichen Zertifikaten, wo private PKI ausreichen würde 

Viele Organisationen verwenden standardmäßig öffentlich vertrauenswürdige Zertifikate für interne Dienste, die niemals mit dem öffentlichen Internet in Berührung kommen. Dafür gibt es mehrere Gründe: 

• Private PKI-Infrastruktur war nicht verfügbar oder schwer zu verwenden. 

• Die Anwendungsteams benötigten schnell Zertifikate und wandten sich an öffentliche Zertifizierungsstellen. 

• Mangelndes Verständnis dafür, wann öffentliches Vertrauen tatsächlich notwendig ist 

• Historische Entscheidungen, die nie revidiert wurden 

Die Verwendung öffentlicher Zertifikate für interne Dienste verursacht unnötige Kosten, betrieblichen Aufwand und nun auch häufigere Erneuerungen als nötig. Die 47-Tage-Vorgabe bietet die Gelegenheit, neu zu bewerten, welche Dienste tatsächlich öffentliches Vertrauen erfordern, und entsprechende Workloads auf private PKI mit längerer Lebensdauer zu verlagern. 

Wie sieht ein moderner 47-Tage-Zertifikatslebenszyklus aus? 

Die Vorbereitung auf 47-Tage-Zertifikate erfordert ein Umdenken in der Zertifikatsverwaltung, die nicht mehr als eine Ansammlung manueller Aufgaben betrachtet werden sollte, sondern als integriertes System. Der Zielzustand umfasst mehrere wichtige Funktionen. 

Vollständige Bestandsübersicht und Transparenz in Echtzeit 

Eine effektive Zertifikatsverwaltung beginnt damit, dass man weiß, welche Zertifikate vorhanden sind, wo sie eingesetzt werden und wann sie ablaufen. Dazu sind mehrere Erkennungsmechanismen erforderlich: 

• CA-Integrationen, die Zertifikatsausstellungsdaten direkt von öffentlichen und privaten Zertifizierungsstellen abrufen, bieten eine zuverlässige Quelle für Informationen darüber, welche Zertifikate ausgestellt wurden. 

• Netzwerk-Erkennungslösungenscannen TLS in der gesamten Infrastruktur und identifizieren dabei aktiv verwendete Zertifikate. Auf diese Weise werden Zertifikate erkannt, die möglicherweise außerhalb der offiziellen Kanäle ausgestellt oder ohne ordnungsgemäße Dokumentation bereitgestellt wurden. 

• Die direkte Keystore- und Geräteerkennunguntersucht Zertifikatsspeicher, Load Balancer, Cloud-Dienste und Anwendungen direkt. Dieser Ansatz findet Zertifikate, die möglicherweise nicht aktiv TLS verwendet werden, aber dennoch in der Umgebung vorhanden sind. 

Die Kombination dieser Entdeckungsansätze sorgt für umfassende Transparenz. Keine einzelne Methode erfasst alles, aber zusammen ergeben sie ein vollständiges Bild. 

Definierte Governance, Eigentumsverhältnisse und Richtlinien 

Klare Zuständigkeiten und Verantwortlichkeiten verhindern Schuldzuweisungen, die typischerweise nach Zertifikatsvorfällen auftreten. Eine effektive Governance umfasst: 

Für jedes Zertifikat oder jede Zertifikatskategorie festgelegte Eigentümer, die für Erneuerungen, Aktualisierungen und die Reaktion auf Vorfälle verantwortlich sind. 

• Rollenbasierte Workflows, die Zertifikatsanfragen, Genehmigungen und Verlängerungen basierend auf dem Zweck und dem Risikograd des Zertifikats an die entsprechenden Teams weiterleiten. 

• Standardisierte Profile, die zulässige Schlüsselgrößen, Algorithmen, Lebensdauern, Namenskonventionen und Platzhalterrichtlinien definieren. Standardisierung reduziert Fehler und gewährleistet Konsistenz. 

• Durchsetzung von Richtlinien, die die Ausstellung von Zertifikaten verhindern, die nicht den Unternehmensstandards entsprechen, sodass Probleme erkannt werden, bevor Zertifikate eingesetzt werden. 

Automatisierung über den gesamten Lebenszyklus hinweg, nicht nur bei der Registrierung 

Echte Automatisierung geht über das bloße Anfordern und Empfangen von Zertifikaten hinaus. Sie umfasst: 

• ACME und ähnliche Protokollefür die automatisierte Registrierung, wo sie geeignet sind. ACME funktioniert gut für Webserver und Kubernetes-Umgebungen, löst jedoch nicht alle Anwendungsfälle. 

• Cert-Manager für Kubernetes-Umgebungenmit entsprechenden Integrationen zu Zertifizierungsstellen.  

• Integration von Infrastructure-as-Codemit Tools wie Terraform, wodurch die Bereitstellung von Zertifikaten Teil der automatisierten Infrastrukturbereitstellung werden kann. 

• Lebenszyklusmanagement (CLM) und Orchestrierungvon Zertifikatenfür komplexe Multi-Hop-Bereitstellungen und Legacy-Systeme, die keine modernen Protokolle unterstützen. Orchestrierungslösungen können Zertifikate auf verschiedenen Zielen bereitstellen, darunter Load Balancer, Anwendungsserver, Zertifikatsspeicher und Remote-Dateisysteme. 

• Warnung und Bestätigung, dass Zertifikate nicht nur ausgestellt, sondern auch tatsächlich eingesetzt und aktiv sind. Eine Ausstellung ohne Einsatz schafft ein falsches Gefühl der Sicherheit. 

Trennung von Anliegen für Neustarts und Änderungskontrolle 

EinigeCLM bieten die Möglichkeit, Dienste nach der Bereitstellung von Zertifikaten automatisch neu zu starten. Das klingt zwar praktisch, birgt jedoch Risiken. Der automatische Neustart von Produktionsdiensten ohne ordnungsgemäße Änderungskontrolle kann zu ungeplanten Ausfällen führen. 

Ein besserer Ansatz trennt die Bereitstellung von Zertifikaten vom Neustart von Diensten: 

• Automatisierungslösungen übernehmen die Erneuerung und Bereitstellung von Zertifikaten. 

• Das System benachrichtigt das Änderungsmanagement, dass ein neues Zertifikat vorliegt. 

• Das Änderungsmanagement koordiniert den Neustart von Diensten während genehmigter Wartungsfenster. 

• Durch ordnungsgemäße Überwachung und Alarmierung werden alle Probleme beim Neustartprozess erkannt. 

Diese Trennung stellt sicher, dass Zertifikatserneuerungen innerhalb des erforderlichen Zeitrahmens erfolgen, während der Neustart von Diensten den entsprechenden Änderungskontrollverfahren folgt. 

WieKeyfactor in die Umstellung auf 47-Tage-Zertifikate? 

Obwohl die Umstellung auf 47-Tage-Zertifikate von öffentlichen Zertifizierungsstellen und Browsern vorangetrieben wird, tragen Unternehmen – und nicht die Zertifizierungsstellen – die operative Last häufiger Erneuerungen. Die Aufgabe Keyfactorbesteht darin, ihnen dabei zu helfen, diese Umstellung effektiv zu bewältigen. 

Keyfactor die Sichtbarkeit aller Zertifikate 

Keyfactor Command bietet eine vollständige Erkennung aller von Zertifizierungsstellen ausgestellten Zertifikate, Netzwerkendpunkte und Zertifikatspeicher. Dieser mehrdimensionale Ansatz hilft Unternehmen dabei, unbekannte oder nicht verwaltete Zertifikate zu identifizieren, die Ausfallrisiken bergen. Die Plattform unterstützt sowohl öffentliche als auch private PKI-Umgebungen und bietet Teams eine einzige zuverlässige Quelle für ihr gesamtes Zertifikatsinventar, unabhängig davon, woher die Zertifikate stammen oder wie sie eingesetzt werden. 

CA-unabhängiges Management vereinfacht den Betrieb 

Unternehmen verlassen sich oft auf mehrere Zertifizierungsstellen – verschiedene Anbieter für unterschiedliche Anwendungsfälle, bestehende Beziehungen oder geografische Anforderungen. Die separate Verwaltung jeder einzelnen Zertifizierungsstelle wird bei kurzlebigen Zertifikaten unüberschaubar. Keyfactor Teams Prozesse und Richtlinien für alle Zertifizierungsstellen auf einer einzigen Plattform standardisieren. Dadurch werden Unstimmigkeiten und Ineffizienzen vermieden, die durch die Nutzung mehrerer Portale mit unterschiedlichen Benutzeroberflächen und Arbeitsabläufen entstehen. 

Automatisierung des gesamten Erneuerungsworkflows 

Kurze Lebenszyklen erfordern mehr als nur die Registrierung bei ACME. Unternehmen müssen die Bereitstellung, Überprüfung und kontinuierliche Überwachung sicherstellen. Keyfactor End-to-End-Lebenszyklusaufgaben und reduziert den manuellen Erneuerungsprozess von 3 bis 6 Stunden auf einen skalierbaren Workflow. Die Orchestrierungsfunktionen der Plattform stellen sicher, dass Zertifikate tatsächlich jeden Endpunkt in einer Multi-System-Bereitstellung erreichen, nicht nur den ersten Server in einer Kette. 

Entdecken Sie Kryptografie im gesamten Unternehmen 

Über Zertifikate hinaus benötigen Unternehmen Einblick in kryptografische Algorithmen, Schlüssel und Abhängigkeiten. Die Krypto-Erkennungslösungen Keyfactorhelfen Teams zu verstehen, wo Kryptografie eingesetzt wird und ob sie veraltet oder anfällig ist. Dies ist eine wichtige Vorbereitung für zukünftige Übergänge wie die Post-Quanten-Kryptografie. Teams können identifizieren, welche Systeme welche Algorithmen verwenden, den Umfang der erforderlichen Änderungen bewerten und Migrationsstrategien vor Ablauf der Frist im Jahr 2030 planen. 

Grundlagen für Krypto-Agilität schaffen 

Unternehmen, die jetzt die Zertifikatsverwaltung automatisieren, sind besser auf bevorstehende Veränderungen in der Branche vorbereitet.Keyfactor die Infrastruktur und Automatisierung, die für den großflächigen Austausch von Zertifikaten oder Algorithmen erforderlich sind. Wenn Post-Quanten-Algorithmen obligatorisch werden,CLM Unternehmen mitCLM ausgereiftenCLM den Übergang als Konfigurationsänderung behandeln und müssen kein mehrjähriges Krisenprojekt in Angriff nehmen. 

Wie sollten Unternehmen jetzt mit den Vorbereitungen beginnen? 

Die Vorbereitung auf 47-Tage-Zertifikate erfordert nicht, dass alles auf einmal umgesetzt wird, aber es muss jetzt damit begonnen werden. Unternehmen haben mehrere Jahre Zeit, um vor Ablauf der Frist im Jahr 2029 die erforderlichen Kapazitäten aufzubauen. 

• Beginnen Sie mit Transparenz und Bestandsaufnahme.Bevor Sie die Zertifikatsverwaltung automatisieren können, müssen Sie wissen, welche Zertifikate vorhanden sind. Führen Sie eine Erfassung über öffentliche und private Zertifizierungsstellen, Netzwerkendpunkte und Zertifikatspeicher hinweg durch. Dokumentieren Sie Schatten-IT-Zertifikate und Wildcard-Bereitstellungen. Das Verständnis Ihrer aktuellen Situation ist die Grundlage für alles Weitere. 

• Klassifizieren Sie Zertifikate nach Risiko, Umgebung und Automatisierungsmöglichkeit.Nicht alle Zertifikate sind gleich. Kundenorientierte Webdienste erfordern eine andere Behandlung als interne Entwicklungssysteme. Identifizieren Sie, welche Zertifikate für den Geschäftsbetrieb am wichtigsten und welche am einfachsten zu automatisieren sind. Diese Klassifizierung dient als Leitfaden für die Priorisierung. 

• Standardisieren Sie Richtlinien und beseitigen Sie offensichtliche Probleme.Bevor Sie schlechte Praktiken automatisieren, beheben Sie diese. Beseitigen Sie unnötige Wildcard-Zertifikate, verlagern Sie interne Dienste gegebenenfalls auf private PKI, standardisieren Sie Schlüsselgrößen und Algorithmen und legen Sie klare Namenskonventionen fest. Bereinigen Sie Ihre Zertifikatsumgebung, bevor Sie sie automatisieren. 

• Pilotieren Sie die Automatisierung in einem begrenzten Bereich.Wählen Sie für die anfängliche Automatisierung einen klar definierten Teilbereich Ihres Zertifikatsbestands aus – beispielsweise Web-Frontend-Server oder einen bestimmten Anwendungsstack. Implementieren Sie eine durchgängige Automatisierung für diesen Bereich, lernen Sie aus den Erfahrungen und dokumentieren Sie, was funktioniert. Weiten Sie die Automatisierung dann schrittweise auf weitere Bereiche aus. 

• Nutzen Sie die 47-tägige Änderung als Katalysator für die Modernisierung sowohl der öffentlichen als auch der privaten PKI.Obwohl die Vorschrift nur öffentliche Zertifikate betrifft, werden die von Ihnen aufgebauten Automatisierungs- und Governance-Funktionen Ihrer gesamten PKI-Infrastruktur zugutekommen. Unternehmen, die dies als ganzheitliche Modernisierungsmaßnahme und nicht nur als Compliance-Check betrachten, werden davon in größerem Umfang profitieren. 

Der Übergang zu 47-Tage-Zertifikaten ist unvermeidlich. Die Organisationen, die jetzt mit den Vorbereitungen beginnen, werden dies als kontrollierte Entwicklung erleben. Diejenigen, die warten, werden mit einer Krise konfrontiert sein.