Letzte Aktualisierung: 15. September 2025

In den vergangenen drei Jahrzehnten sind digitale (X.509-)Zertifikate schrittweise zu einem Bestandteil kritischer Infrastrukturen geworden. Unternehmen verlassen sich auf sie, um wesentliche Geschäftsprozesse zu unterstützen. Dennoch haben viele Organisationen den Übergang zu bewährten Verfahren nicht vollzogen, da sich die Nutzung digitaler Zertifikate über die Zeit allmählich ausgeweitet hat; sie verwalten Zertifikate weiterhin ohne zentrale Aufsicht oder Kontrolle. Diese Vorgehensweise erhöht unternehmerische Risiken, führt zu unbekannten Sicherheitslücken und ist häufig Ursache für Ausfälle.

Dieses Dokument ist wie folgt strukturiert: Im ersten Teil betrachten wir Certificate Lifecycle Management (CLM)-Tools und deren Fähigkeiten. Wir diskutieren private und öffentliche PKIs und erläutern ihre Vor- und Nachteile. Im zweiten Teil skizzieren wir ein CLM-Programm Schritt für Schritt, das für Organisationen jeder Größe anwendbar ist. Wer diesen Leitfaden befolgt, ist in der Lage, die Kontrolle über seinen Bestand digitaler Zertifikate zu übernehmen – von den Grundlagen über Transparenz und Kontrolle bis hin zu Automatisierung und besten Sicherheitspraktiken.

Certificate Lifecycle Management ist ein umfassender Prozess zur Verwaltung digitaler Zertifikate über deren gesamten Lebenszyklus hinweg. Es handelt sich um einen entscheidenden Aspekt der Cybersicherheit, der sicherstellt, dass digitale Identitäten und Netzwerkkommunikation der Organisation sicher und vertrauenswürdig sind. Ein erfolgreiches CLM-Programm erfüllt zwei Hauptanforderungen: 1) Unterstützung bei der Erkennung und Überwachung von Zertifikaten einer Organisation und 2) Bereitstellung operativer Unterstützung für Zertifikatsprozesse, einschließlich Automatisierung bei Ausstellung, Bereitstellung, Rotation und Widerruf.

Aktivitäten im Zusammenhang mit Zertifikatsmanagement werden am besten im größeren Kontext der Kryptographie-Governance betrachtet. Kryptographie-Erkennung und Bestandsaufnahme sind zwei miteinander verwobene Initiativen, die eng mit dem Certificate Lifecycle Management verbunden sind. CLM ist am wirkungsvollsten als kontinuierliches Programm, das die organisatorischen Anforderungen an Verfügbarkeit, Compliance und Sicherheit erfüllt.

Certificate Lifecycle Management ist für die meisten Unternehmen eine unabdingbare Funktion. Derzeit sind jedoch zwei Entwicklungen im Gange, die sofortiges Handeln erfordern:

• Verkürzte Zertifikatslaufzeiten: Im Bereich der öffentlichen PKI werden die Zertifikatslaufzeiten vom aktuellen Maximum von einem Jahr zunächst auf 200 Tage im März 2026, dann auf 100 Tage im März 2027, und schließlich auf nur 47 Tage im März 2029 reduziert. Sofern die Zertifikatsverlängerung nicht automatisiert ist, erhöhen diese Änderungen die direkten operativen Kosten und die Ausfallwahrscheinlichkeit erheblich. Weitere Informationen zu diesen Änderungen finden Sie in unserem Blogbeitrag zu diesem Thema.
• Post-Quanten-Migration: Die drohende Gefahr eines kryptografisch relevanten Quantencomputers erfordert einen Umstieg auf neue Public-Key-Algorithmen. Der Konsens ist, dass die Migration wichtiger Systeme innerhalb der nächsten fünf Jahre abgeschlossen sein sollte.

Public Key Infrastructure (PKI) ist ein System zum Management digitaler Identitäten. Eine digitale Identität setzt sich zusammen aus einem privaten Schlüssel – dem Kern der Identität – und dem zugehörigen Zertifikat, das wiederum den öffentlichen Schlüssel und relevante Metadaten enthält. Die Identitäten sowie die Regeln zu Ausstellung, Nutzung, Widerruf und weiteren Operationen bilden zusammengenommen eine PKI.

Eine PKI wird in der Regel für einen bestimmten Zweck geschaffen und konzipiert. Tatsächlich ist es eine bewährte Praxis, PKIs mit unterschiedlichen Einsatzzwecken zu trennen, um die Sicherheit durch Kompartimentierung zu erhöhen.

Einige PKIs sind für organisationsübergreifende Zusammenarbeit ausgelegt und werden als öffentlich bezeichnet. Schafft eine Organisation PKIs für eigene Zwecke, spricht man von privaten PKIs. Der Hauptunterschied besteht darin, dass bei öffentlichen PKIs meist eine eigenständige Governance-Struktur existiert; alle Teilnehmer müssen sich an die gleichen Regeln halten. Bei privaten PKIs haben Organisationen die vollständige Kontrolle über das Design und die Verwendung und können sie exakt an ihre Anforderungen anpassen.

• Für organisationsübergreifende Zusammenarbeit und Interoperabilität konzipiert.
• Unabhängige Governance; alle müssen die gleichen Spielregeln beachten.
• Viele Aufgaben werden von Dritten wie Root-Programmen und CAs übernommen.
• Änderungen erfolgen langsam und können durch politische Prozesse oder auf den langsamsten Teilnehmer warten müssen.

• Für den privaten Organisationsgebrauch konzipiert.
• Volle Kontrolle über Design und Betrieb der PKI.
• Erfordert einen höheren Implementierungsaufwand, da alle Aspekte bedacht werden müssen.
• Kann sich mit der Geschwindigkeit der Organisation weiterentwickeln.

Es gibt verschiedene öffentliche PKIs, mit denen wir uns beschäftigen können. Die Internet PKI bezeichnet das globale System, das das Internet absichert. Hierbei werden digitale Zertifikate zur Validierung von Verbindungen zwischen Netzwerkteilnehmern eingesetzt, in der Regel mittels des Protokolls Transport Layer Security (TLS). Die Web PKI kann als eine Teilmenge der Internet PKI betrachtet werden, die nur von Browsern genutzt und an die speziellen Anforderungen angepasst ist. Beide PKIs überschneiden sich, die Begriffe werden oft synonym verwendet. S/MIME PKI dient dem Schutz der E-Mail-Kommunikation und arbeitet nach eigenen Regeln.

Diese öffentlichen PKIs werden im Wesentlichen durch die großen Root-Programme – etwa die von Apple, Chrome, Microsoft und Mozilla – verwaltet. Sie stellen die Regeln auf und bestimmen, welche CAs mitmachen dürfen. Darüber hinaus reguliert das CA/Browser Forum als Branchenverband technische Aspekte der öffentlichen PKIs.

Wesentliche Merkmale sind:

• Jede Person oder Organisation kann teilnehmen
• Ausstellung erfolgt auf Basis des Nachweises der Kontrolle über die Infrastruktur
• Kurze Zertifikatslaufzeiten machen Automatisierung faktisch erforderlich
• Zertifikate sind in der Regel kostenfrei
• Alle Zertifikate werden in öffentlichen Logs dokumentiert
• Schwache Kryptographie ist nicht erlaubt
• Feste Zertifikatsprofile
• Begrenzte Möglichkeiten zur Prüfung von Sperrungen

Der Hauptvorteil öffentlicher PKIs besteht darin, dass sie von großen, globalen Organisationen betrieben werden. Die Kosten für die Teilnahme sind dadurch gering oder gar nicht existent. Das bietet Interoperabilität – jedoch auf Kosten der Flexibilität. Für viele Anwendungsfälle ist dieser Kompromiss sinnvoll, vor allem heute, wo öffentliche Zertifikate kostenlos verfügbar sind. Auch große Organisationen nutzen häufig öffentliche Zertifikate für ihre privaten Infrastrukturen.

Es gibt jedoch Anwendungsfälle, in denen öffentliche PKIs zu einschränkend sind:

• Keine starke Authentisierung bei der Ausstellung
• Keine Kontrolle über die Laufzeiten der Zertifikate
• Zertifikate geben Informationen über private Infrastruktur preis
• Keine Unterstützung für Client- oder Geräte-Zertifikate
• Keine Unterstützung für Code- und Dokumentensignierung
• Keine Unterstützung für individuelle Zertifikatsprofile
• Ratenbegrenzung bei der Ausstellung
• Begrenzte Protokollaustauschoptionen für die Ausstellung
• Langsame Übernahme neuer Standards (z. B. Post-Quantum-Kryptographie)

Je nach Anwendungsfall, Expertise und Budget kann eine Organisation eine PKI intern aufbauen und betreiben oder eine der von Cloud-Providern und Zertifizierungsstellen angebotenen Managed-Services-Lösungen nutzen.

Wir haben festgestellt, dass Zertifikate in ihren jeweiligen PKIs erstellt werden. Dank des inzwischen weit verbreiteten Automated Certificate Management Environment (ACME) Protokolls können einzelne Server ihre Zertifikate direkt durch Kommunikation mit den bevorzugten CAs erhalten. Diese Vorgehensweise nutzen kleine und große Organisationen gleichermaßen.

Organisationen, die mehr Kontrolle oder Transparenz wünschen, setzen möglicherweise dedizierte Certificate Lifecycle Management Tools ein. Beispielsweise kann eine Organisation zur Verbesserung der Übersichtlichkeit ein CLM-Produkt einführen, das Erkennung und Überwachung von Zertifikaten ermöglicht.

Große Organisationen verlassen sich womöglich auf ein oder mehrere CLM-Tools, um eine zentrale Ausstellung sicherzustellen und die Kontrolle darüber zu behalten, welche CAs wo eingesetzt werden. Das gilt insbesondere dann, wenn sie für ihre interne Infrastruktur eigene private PKIs betreiben. 

Wie bei allen Initiativen ist der Schlüssel zum erfolgreichen CLM-Programm das Verständnis der zugrunde liegenden Geschäftsanforderungen. Beispiele für Sicherheits- und Compliance-Anforderungen:

• Risikomanagement und Governance: Überblick über alle ausgestellten Zertifikate verschaffen, um die Grundlage für Kontrolle und Überwachung zu schaffen.
• Regulatorische Anforderungen und Compliance: Sicherstellen, dass die Zertifikate allen relevanten Vorschriften entsprechen.
• Verbesserte Sicherheit: Überwachung der Zertifikatsbereitstellung, um sicherzustellen, dass ausreichend starke Kryptografie verwendet wird.
• Kryptographische Agilität: Die Organisation muss in der Lage sein, ihre kryptografischen Assets zu identifizieren und bei Bedarf schnell neue kryptografische Verfahren zu übernehmen. 
• Migration auf Post-Quantum-Kryptografie: Als dringliches Anliegen die Umstellung auf sichere Verfahren gegenüber angreifbaren Public-Key-Algorithmen unterstützen.
• Kostenreduktion und Sicherheitsratings: Kosten senken durch den Einsatz passender, den Richtlinien entsprechender Zertifikate. Außerdem Verbesserung der öffentlich sichtbaren Aspekte der IT-Sicherheit, was zu geringeren Cyber-Versicherungskosten führen kann.

Im Bereich der operativen Anforderungen gibt es zwar weniger, diese erfordern jedoch fehlerfreie Umsetzung, da Fehler zu Ausfällen führen können:

• Automatisierung: Mit genehmigten Certification Authorities (CAs) kommunizieren, Zertifikate automatisiert ausstellen, bereitstellen, rotieren und widerrufen.
• Verfügbarkeit und Interoperabilität: Sicherstellen, dass Zertifikate für die Zielgruppen geeignet sind und die Anforderungen an Interoperabilität, Performance und Ausfallsicherheit erfüllen.
• Ausfallprävention und Verfügbarkeit: Ausfälle durch Überwachung der Zertifikate auf Ablauf, unerwarteten Widerruf oder sonstige Probleme minimieren.

Angesichts der Komplexität von PKI ist es nicht überraschend, dass es zahlreiche CLM- und PKI-Tools gibt, die jeweils auf spezielle Anwendungsfälle fokussiert sind – ein Allround-Tool, das alles kann, existiert jedoch nicht. Die Funktionalität fällt meist in eine dieser Kategorien:

• Einfache Ausgabeautomatisierung: Tools, die die Ausstellung und Verlängerung automatisieren und direkt auf der Infrastruktur laufen, die die Zertifikate nutzt. Meist per ACME und zunehmend direkt in Server-Software integriert.
• Private PKI-Produkte: Tools zur Erstellung und Verwaltung privater PKIs – entweder selbst gehostet oder managed, oftmals von großen Cloud-Anbietern und CAs bereitgestellt.
• Erkennung und Transparenz: Tools zum Aufbauen eines Zertifikatsinventars und vollständiger Übersicht über alle Zertifikate einer Organisation, inkl. ihrer Nutzung und Position.
• Lebenszyklusautomatisierung: Tools für die fortgeschrittene Orchestrierung der Zertifikatsausstellung, meist mit Integration in mehrere private oder öffentliche PKIs und Anbindung an viele Plattformen und Server über Plugins.
• Zertifikatsüberwachung: Oft Bestandteil von Tools für Netzwerk- und Verfügbarkeitsüberwachung oder IT Operations Management.

Bei der Auswahl sollten Organisationen ihre Ziele und Fragestellungen am Anfang klären, die Angebote der verschiedenen Anbieter sichten und das wählen, was den eigenen Anforderungen entspricht.

Mit der zunehmenden Verbreitung von ACME gibt es immer mehr Tools zur Unterstützung der Ausstellung und Verlängerung von Zertifikaten. ACME-Client-Funktionen sind zunehmend in Server-Software und Appliances integriert, was das Zertifikatsmanagement erheblich vereinfacht. Schon jetzt – oder spätestens bald – wird die Mehrzahl der Software, die Zertifikate nutzt, ACME direkt unterstützen, wodurch Basisfunktionen des Zertifikatsmanagements leicht verfügbar werden.

Diese einfache Automatisierung bei der Ausstellung ist oft ausreichend, bietet aber nicht den vollen Funktionsumfang der Lebenszyklusautomatisierung. Einige Aufgaben – etwa der Wechsel der ausstellenden CA oder das vorzeitige Austauschen von Zertifikaten – müssen möglicherweise manuell erfolgen.

CLM-Produkte mit vollständiger Lebenszyklusautomatisierung bringen diese Fähigkeiten meist direkt mit. Sie nutzen ACME oder proprietäre Integrations-Plugins. Die Entscheidung besteht also darin, ob Sie auf einfache Automatisierung setzen und im Bedarfsfall manuell nachbessern – oder die vollständige Automatisierung mit mehr Einrichtungsaufwand, aber weniger manueller Arbeit später bevorzugen. Prüfen Sie vorab, ob Ihr CLM-Produkt die Integration mit Ihren Plattformen und Ihrer Server-Software unterstützt. Führen Sie ein repräsentatives Proof of Concept durch, bevor Sie eine umfassende Implementierung planen.

Die richtige Auswahl an Tools für das Certificate Lifecycle Management ist anspruchsvoll, da sie viele verschiedene Funktionen bieten und meist nicht alle Bedürfnisse mit einem einzigen Produkt abdecken. Stellen Sie bei Ihren Bewertungskriterien sicher, dass die Tools folgende Fragen beantworten können:

• Haben wir eine vollständige Inventarliste aller Zertifikate?
• Verwenden alle Zertifikate starke Kryptographie?
• Welche CAs werden genutzt?
• Werden die richtigen CAs an den richtigen Orten eingesetzt?
• Wo im Netzwerk sind Zertifikate installiert?
• Werden die Zertifikate und Protokolle korrekt und sicher implementiert?
• Setzen wir für wichtige Eigenschaften bereits Post-Quantum Key Exchange ein?
• Werden Zertifikate automatisch ausgestellt und erneuert?
• Können wir Zertifikate bei Bedarf rotieren?
• Können wir auf unerwartete Widerrufungen reagieren?
• Wer stellt unsere Zertifikate wann und wo aus?
• Welche Dritten stellen Zertifikate in unserem Namen aus?
• Gibt es betrügerisch ausgestellte Zertifikate auf unsere Namen?

Im zweiten Teil dieses Dokuments bieten wir eine Schritt-für-Schritt-Anleitung für ein Programm zum Certificate Lifecycle Management, mit dem Sie die Kontrolle über Ihre öffentliche PKI-Infrastruktur übernehmen können. Das gesamte Themenfeld von Certificate Lifecycle Management und PKI lässt sich im Wesentlichen auf drei Schritte herunterbrechen:

1. Kontrolle über Ihre öffentliche PKI-Infrastruktur etablieren
2. Verwaltung und Weiterentwicklung privater PKI-Deployments
3. Einsatz von einem oder mehreren CLMs zur vollständigen Automatisierung des Lebenszyklus

Wir haben dieses Programm entwickelt, weil alle Organisationen an öffentlicher PKI teilnehmen, aber nur wenige ausreichend Transparenz und noch weniger die Kontrolle über die Zertifikatsausstellung für ihre Systeme besitzen. Dieser Teil kann losgelöst betrachtet und vergleichsweise schnell abgeschlossen werden. Mit der Übernahme der Kontrolle über Ihre öffentliche PKI gewinnen Sie wertvolle Erfahrung, die Ihre Bedürfnisse klärt und spätere Entscheidungen zu Private PKIs und Zertifikatsautomatisierung informierter macht.

Die anstehende Verkürzung der Zertifikatslaufzeiten auf unter ein Jahr zwingt Sie praktisch, Ihre öffentlichen Zertifikate vorrangig zu behandeln. Mit der ersten Reduktion auf 200 Tage im März 2026 müssen Sie rasch handeln, um deutlich mehr manuellen Erneuerungsaufwand zu vermeiden.

Beginnen Sie damit, Ihre individuellen Anforderungen und Ziele explizit aufzulisten. Kein Umfeld gleicht dem anderen, besonders im PKI-Bereich. Eine Auswahl gängiger Ziele ist im ersten Teil dieses Leitfadens erläutert. Bewerten Sie diese Ziele nach Priorität – das erleichtert spätere Entscheidungen und schafft Kontext.

Zudem haben Branchentrends und regulatorische Anforderungen einen erheblichen Einfluss auf Ihre Priorisierung. Prüfen Sie die regulatorische Landschaft, um die geltenden Compliance-Anforderungen zu verstehen. Kryptografie steht in den letzten Jahren weit oben auf der Agenda. DORA, NIS2, NIST, FIPS, PCI DSS, HIPPA und andere machen umfangreiche Vorgaben zum Umgang mit Kryptografie und Schlüsselmanagement. Der weltweite Übergang zur Post-Quantum-Kryptografie ist im Gange, mit großem Aufwand und engen Zeitfenstern; erfahren Sie was Sie bis wann tun müssen.

Ein Vorteil der Internet-PKIs ist die vergleichsweise einfache Möglichkeit, vollständige Zertifikatstransparenz zu erreichen – insbesondere im Vergleich zu privaten PKIs. Grund dafür ist Certificate Transparency (CT), ein System, das alle öffentlichen Zertifikate zur Auditierung und Überwachung sammelt und veröffentlicht. Technisch gesehen ist CT zwar nicht verpflichtend, aber da Apple, Google und Microsoft die Anerkennung von Zertifikaten an CT koppeln, erfüllen praktisch alle öffentlichen Zertifikate diese Anforderung.

Mit dem passenden Tool lässt sich sofortige Sichtbarkeit auf alle Ihre öffentlichen Zertifikate erzielen, weil die Hersteller auf eine vollständige Datenbank aller gültigen öffentlichen Zertifikate zurückgreifen. Ausgehend von einer Liste aller Domains im Besitz der Organisation durchsucht das Tool Milliarden von Zertifikaten, um solche zu finden, die zur Organisation und zu Subdomains gehören. Red Sift Certificates ist unser Produkt für diesen Zweck.

Die Nutzung von Certificate Transparency fördert allerdings ein anderes Problem zutage: Viele Organisationen haben keine vollständige Liste ihrer Domains. In vielen Fällen wird diese erst bei Bedarf zusammengestellt – mit erheblichem Aufwand.

Um das zu adressieren, lässt sich CLM mit anderen Werkzeugen ergänzen, die die IT-Infrastruktur der Organisation automatisch entdecken. Diese Fähigkeit nennt man meist Attack Surface Monitoring (ASM). Beginnend mit wenigen bekannten Seed-Domains und Datenbanken zur Überwachung der weltweiten Infrastruktur, erstellen diese Produkte eine stets aktuelle Ressourcenliste. Umfassende Anbindung an Domain-Registrare, DNS-Provider und CAs sorgt für ein vollständiges Domain-Inventar. Die automatische Infrastruktur-Erkennung ist in Red Sift Certificates integriert.

Gewünschte Ergebnisse:

• Vollständige Liste aller im Unternehmen registrierten Domainnamen
• Automatisches Abgleichen der Domains mit autoritativen Quellen
• Fortlaufende Erfassung aller Subdomains
• Fortlaufende Entdeckung neuer registrierbarer Domains
• Komplette Liste aller ausgestellten öffentlichen Zertifikate
• Berichte zu ausstellenden CAs und Zertifikatsproblemen

Ein vollständiges Zertifikatsinventar ist ein sehr guter Anfang, der eigentliche Nutzen entsteht jedoch dadurch, dass Sie wissen, wo und wie die Zertifikate verwendet werden. Dies erfordert aktives Netzwerk-Monitoring, um die Installationsorte und weitere Informationen zu jedem Zertifikat zu ermitteln.

• Monitoring von Domains und Subdomains: Ein Überwachungstool scannt fortlaufend auf Basis des Domain-Inventars alle relevanten IPs. Öffentliche Dienste sind damit lückenlos abgedeckt.
• Firewall-Rekonfiguration: Manche Dienste laufen auf öffentlichen Servern, sind aber nicht öffentlich zugänglich. Eine Firewall-Ausnahme für das Monitoring-Tool sorgt mit wenig Aufwand für bessere Übersicht.
• Überwachung statischer Netzbereiche: Durch Scans der Netzwerksegmente, die ausschließlich von der Organisation genutzt werden, lassen sich vergessene Domains aufspüren oder Dienste auf blanken IPs identifizieren. Ideal ist ein gemanagter (agentenloser) Ansatz, um den Arbeitsaufwand gering zu halten.
• Überwachung privater Netzwerke: Viele Organisationen haben Infrastruktur, die nicht öffentlich sichtbar ist. Hier ist Agent-basierte Überwachung nötig, was in der Regel je Umgebung ein Agenten-Setup erfordert und aufwendiger ist.

Gewünschte Ergebnisse:

• Erkennung aller Zertifikatseinsätze
• Auflistung angebundener Dritter und deren Sicherheitsumfeld
• Ermittlung ablaufgefährdeter Erst- und Drittanbieterzertifikate
• Identifikation fehlerhaft konfigurierter Zertifikate
• Auflistung verfügbarer Dienste, Protokolle und Kryptographiekonfiguration
• Berichte zur Abdeckung der Post-Quantum-Migration
• Berichte zur Abdeckung der Automatisierungsimplementierung
• Reporting zu gemeinsam genutzten Zertifikaten zwischen Diensten

Zu diesem Zeitpunkt sollten Sie vollständige Transparenz über alle Zertifikate und deren Nutzung haben. Im Unterschied zu den ersten drei, stets sequenziell sinnvoll verlaufenden Schritten, erfolgt die weitere Vorgehensweise meist organisch. Oft lassen sich bereits jetzt kritische Probleme erkennen – etwa abgelaufene Zertifikate oder Konfigurationsfehler, zum Beispiel fehlende Post-Quantum-Unterstützung (dazu später mehr). Es ist sinnvoll, solche Probleme frühzeitig zu beheben, denn die weiteren Schritte dauern meist länger und erfordern Abteilungsübergreifende Zusammenarbeit.

Das Ziel dieses Schrittes ist die logische Aufteilung Ihrer PKI-Landschaft in sinnvolle Gruppen, z. B. nach Geschäftsbereichen, Bedeutung und Datenart. Um das nötige Detailniveau für eine sinnvolle Einteilung zu erreichen, ist meist intensive interne Kommunikation erforderlich.

Im nächsten Schritt werden die Teams bestimmt, die für die jeweiligen Gruppen zuständig sind. Das ist entscheidend, damit erkannte Probleme zielgerichtet an die jeweils zuständigen Stellen gemeldet werden können. In diesem Zuge identifizieren Sie auch Drittanbieter, auf die Sie für bestimmte Dienste angewiesen sind. Je nach Art der Zusammenarbeit können Sie diese als eigene Teams behandeln – oder auch nicht.

Sind Gruppen und Teams festgelegt, sollte die Einrichtung der Benachrichtigungen nur noch ein Knopfdruck sein. Idealerweise sehen Sie ab dann nie wieder ein abgelaufenes Zertifikat.

Dieser Schritt ist das Fundament aller weiteren Maßnahmen. Nehmen Sie sich Zeit, alle Beteiligten einzubinden. Überlegen Sie zudem, ob es sinnvoll ist, Ihr PKI-Tool mit anderen Systemen zu koppeln, um Zertifikatsinformationen dort verfügbar zu machen, wo sie gebraucht werden.

Gewünschte Ergebnisse:

• Identifikation kritischer Systeme mit unmittelbarem Handlungsbedarf
• Festlegung der Geschäftseinheiten und Teams
• Gruppierung der Systeme nach Dringlichkeit und Verantwortung
• Konfiguration von Benachrichtigungen zur Ausfallprävention, gezielt an die Verantwortlichen
• Identifikation eingebetteter oder ausgelieferter Drittanbieterdienste auf den eigenen Domains
• Integration der Benachrichtigung in externe Systeme per API

2025 ist Automatisierung in aller Munde – denn die bisher manuell verlängerten Zertifikate, aktuell noch jährlich, müssen ab März 2026 bereits halbjährlich erneuert werden. Ab diesem Zeitpunkt gilt eine maximale Laufzeit von 200 Tagen. Die Intervalle verkürzen sich weiter, auf 100 Tage ab März 2027 und nur noch 47 Tage ab März 2029. Finden Sie also schnell heraus, wo noch nicht automatisiert wird, und stellen Sie sicher, dass Ihre gesamte Organisation die manuelle Erneuerung abschafft.

Die Verbreitung des ACME-Protokolls wächst rasant und bald wird ACME der Standardweg für alle Zertifikate sein. ACME erlaubt einen Anbieterwechsel zu jedem kompatiblen CA. Umfangreiche CLMs bieten teils zusätzliche Integrationen, binden Sie dann jedoch stärker an den Anbieter. ACME ist die sicherere Wahl, ein späteres Upgrade auf ein proprietäres CLM ist jederzeit möglich – ggf. nur für besonders wichtige Systeme.

Auch die Wahl der einzusetzenden CAs ist kontextabhängig. Bei der öffentlichen PKI bieten kostenfreie CAs meist den größten Nutzwert, denn das Produkt ist das gleiche, nur kostenlos. Let's Encrypt ist sogar oft bei neuen Features und Sicherheitsfunktionen führend. Im Bereich privater PKIs benötigen Sie dagegen u. U. mehr Service, Werkzeuge und Fachberatung.

Gewünschte Ergebnisse:

• Klare Automatisierungsstrategie
• Liste aller Umgebungen, in denen Zertifikate benötigt werden
• Dokumentation zur Automatisierungsunterstützung in allen Umgebungen
• Entscheidung ACME vs. proprietäre CLM-Integration
• Kurzliste vertrauenswürdiger CAs

Ein weiterer Vorteil der wichtigsten öffentlichen PKIs ist das eingebaute Monitoring- und Auditing-System via Certificate Transparency (CT). Schon im ersten Schritt war CT entscheidend, um alle zu Ihrer PKI gehörenden Zertifikate zu erfassen. Damit ließen sich alle noch gültigen Zertifikate aufspüren. Dasselbe System dient der Echtzeit-Entdeckung neuer Zertifikate, sobald sie ausgestellt und in den CT-Logs eingetragen werden. Dies ist nicht nur für sofortige Einsicht wünschenswert, sondern vor allem zur Erkennung unautorisierter Ausstellungen.

Domänenbesitzer haben in der öffentlichen PKI keine technische Kontrolle über die Ausstellung. Jede zertifizierte CA kann für jede beliebige Domain der Welt Zertifikate ausstellen, ohne die Zustimmung des Eigentümers einzuholen. Monitoring ist deshalb essenziell, um betrügerische Aktivitäten frühzeitig zu erkennen. 

CT hilft auch beim Infrastruktur-Discovery: Ein ausgestelltes Zertifikat enthält die gültigen Domains. Damit lässt sich sofort erkennen, wenn neue Subdomains auftreten.

Öffentliche Zertifikate werden in frei zugänglichen CT-Logs erfasst. Mit einem guten Tool können Sie diese Einträge leicht sichten – insbesondere, wenn Automatisierungen zur Einordnung und Auswertung vieler Zertifikate enthalten sind. Auch Open-Source-Tools stehen hierfür zur Verfügung.

Anfangs mag eine E-Mail-Benachrichtigung für jedes neue Zertifikat noch spannend sein – doch das legt sich schnell. Vielmehr stellt sich die Frage, was mit den Informationen anzufangen ist und wie man eigene Zertifikate von betrügerischen Differenzieren kann. Für diese Aufgaben ist Automatisierung prädestiniert.

CT-Monitoring-Tools konzentrieren sich meist auf Zertifikate unter bekannten Domains. Öffentliches PKI-Monitoring kann jedoch erweitert werden, um Anzeichen betrügerischer Aktivität im gesamten Zertifikatsraum aufzuspüren, z. B. gezielt auf täuschend ähnlich benannte unbekannte Domains als Vorbereitung auf Phishing-Angriffe. Diese Gegner werden meist von eigenen Produkten zur Domain- und Markenreputationsüberwachung enttarnt. Red Sift's Brand Trust ist eines davon.

Gewünschte Ergebnisse:

• Echtzeit-Erfassung neu ausgestellter Zertifikate
• Automatisierte Bearbeitung routinemäßiger Ausstellungen zur Geräuschunterdrückung
• Erkennung ungewöhnlicher Ausstellungen zur weiteren Prüfung
• Erkennung nachgeahmter Ausstellungen im gesamten öffentlichen PKI-Bereich

Eine Besonderheit der öffentlichen PKI ist der Mangel an traditioneller Authentisierung bei der Ausstellung. Jeder kann ein Zertifikat anfordern, sofern er die Kontrolle über den gewünschten Infrastruktur-Bestandteil nachweist. Funktioniert dies meist wie vorgesehen, kann es aber auch zu unerwünschten Zertifikatsausstellungen bei Fehlkonfigurationen kommen. Beispiel: Dangling DNS – wenn ein Domainname noch auf eine IP verweist, die nicht mehr unter Ihrer Kontrolle ist (z. B. vergessenes Update nach dem Löschen eines Cloud-Servers). Dann kann eine fremde Person für diese IP ein Zertifikat mit Ihrem Domainnamen erhalten.

Ein vergleichsweise neuer Standard namens Certification Authority Authorization (CAA) schafft mehr Ordnung und Kontrolle bei der Zertifikatsausstellung. Mit CAA können Domainbesitzer Ausstellungsrichtlinien als DNS-Records veröffentlichen, die alle CAs zu beachten haben. Dies ist zwar immer noch keine Authentifizierung im klassischen Sinne (die Kontrolle liegt weiter bei den CAs), aber der sicherste Weg in der bestehenden öffentlichen PKI.

CAA-Richtlinien werden als DNS-Records unter den zu kontrollierenden Domains veröffentlicht. Damit lassen sich gezielt einzelne oder mehrere vertrauenswürdige CAs auswählen und alle anderen ausschließen. Die Kontrolle erstreckt sich auf normale und Wildcard-Zertifikate, S/MIME, BIMI und möglicherweise weitere Typen. Wird ein einzelner CA zugelassen, ist mit weitergehender Konfiguration noch höhere Sicherheit möglich.

CAA lässt sich flexibel einsetzen. Grob gesagt ist die Ausgangslage ohne CAA, dass jeder CA ausstellen darf; eine breite CAA für viele CAs ist einfach auszurollen und reduziert die Angriffsfläche spürbar; eine eng zugeschnittene CAA für wertvolle Systeme bietet das höchste Schutzniveau. 

HINWEIS: Im Juni 2025 hat das CA/Browser Forum beschlossen, dass DNSSEC-Prüfungen für alle DNS-Operationen im Kontext der Zertifikatsausstellung – auch bei der CAA-Validierung – verpflichtend werden. Ab März 2026 sorgen Sie mit DNSSEC dafür, dass Ihre CAA-Policies kryptografisch überprüfbar sind und damit die Manipulationsgefahr deutlich sinkt.

Das zuvor behandelte CT-Monitoring funktioniert in Verbindung mit konsequent umgesetzten CAA-Policies besonders effektiv; beide Methoden filtern gemeinsam erfolgreich unbekannte oder nicht autorisierte Zertifikate heraus.

Gewünschte Ergebnisse:

• Kurze Liste vertrauenswürdiger/fähiger CAs (geringe Fehler-/Kompromittierungsgefahr)
• Weite Standard-CAA-Konfiguration für alle zu kontrollierenden Domains ausrollen
• „Deny-all“-CAA-Konfiguration auf geparkten Domains umsetzen
• Strikte CAA-Konfiguration für besonders schützenswerte Systeme einrichten
• Fortschrittliches CT-Monitoring, das mit Ihrer CAA-Konfiguration integriert ist

Der weltweite Wechsel zur Post-Quantum-Kryptographie läuft – um sich vor kryptografisch relevanten Quantencomputern (CRQC) zu schützen, die die aktuell eingesetzten Public-Key-Algorithmen gefährden. Je nach System dauert der Übergang fünf Jahre (wichtige Systeme) bzw. zehn Jahre (Rest). Wann der sogenannte Q-Day kommt, ist unklar, aber wir hoffen, dass wir es rechtzeitig schaffen.

Für die öffentliche PKI besteht vorerst nur eine unmittelbare Maßnahme: Erhöhen Sie die Abdeckung mit Post-Quantum-Schlüsselaustauschverfahren auf Ihren Systemen. Auch wenn derzeit niemand Zugriff auf einen CRQC hat, besteht das Risiko von „Store Now, Decrypt Later“-Angriffen (also Abfangen verschlüsselter Kommunikation heute, Entschlüsselung später, wenn CRQC verfügbar sind). Falls Sie noch Informationen über Jahre hinweg geheimhalten müssen, könnte es schon bald zu spät sein.

Wir haben einen detaillierten Leitfaden zur Post-Quantum-Migration für Sie vorbereitet.

Gewünschte Ergebnisse:

• Sofortiger Einsatz post-quantum Schlüsselaustausch bei kritischen Systemen
• Klarer Plan für den Rest der Systeme

Der letzte Schritt auf dem Weg zum erfolgreichen Management Ihrer öffentlichen PKI-Infrastruktur betrifft eine Vielzahl an Konfigurationsthemen, die Ihre Sicherheit untergraben könnten. Kontrollieren Sie hier nicht, haben Sie zwar die Zertifikate unter Kontrolle, erreichen aber kein höheres tatsächliches Sicherheitsniveau. Zu klärende Punkte:

• Public-Key-Algorithmus und -Stärke: Stellen Sie sicher, dass angemessene Schlüssel und Algorithmen verwendet werden. Im öffentlichen PKI-Bereich verweigern CAs schwache Schlüssel, aber spezielle Probleme sind auch hier möglich; in privaten PKIs kommen sie häufiger vor.
• Kryptographische Protokoll-Konfiguration: Nur sichere Protokolle verwenden, den Konfigurationsbedarf für Zielgruppen beachten, ggf. Kompromisse bei der Interoperabilität älterer Clients eingehen.
• Richtigkeit der Zertifikatskette: Alle Zertifikate mit einer vollständigen, korrekten Kette bis zu einer akzeptierten Root ausrollen. Fehlerhafte Ketten können Zertifikate unbrauchbar machen und sind schwierig zu erkennen.
• HTTP Strict Transport Security: Auf allen Domains HSTS bereitstellen und pre-loaden, sodass ungültige Zertifikatswarnungen nicht umgangen werden können und Klartextzugriffe immer auf TLS umgeleitet werden. HSTS verhindert, dass Benutzer bei Netzwerkangriffen Warnmeldungen einfach wegklicken.
• Sichere HTTP-Cookies: Nur als „secure“ markierte Cookies verteilen, zudem Cookie Name Prefixes (RFC 6265bis) nutzen, um historische Schwächen in Browsern auszuschließen. Andernfalls ist Session-Hijacking auch auf sicheren Websites möglich.
• HTTP Mixed Content: Sicherstellen, dass nicht nur die Hauptsite, sondern auch alle eingebundenen Inhalte verschlüsselt ausgeliefert werden. Alle externen Links sollen ebenfalls verschlüsselt sein.
• CAA Policy: Bereits weiter oben erläutert. Für jede Site eine passende CAA-Beschränkung implementieren.

Nutzen Sie Ihre PKI-Tools, um all diese Aspekte automatisiert zu prüfen. Nicht alle Tools unterstützen alle genannten Standards – vor allem beim letzten Abschnitt (Web-Konfiguration „auf der letzten Meile“) sind Funktionen seltener. Wir decken diese Checks in den Red Sift-Produkten vollständig ab. Nutzen Sie bei Bedarf kostenlos unser Tool auf hardenize.com für diese Themen, etwa wenn Sie mit Dritten zusammenarbeiten, die keinen Zugang zu Ihren Tools haben.

Weitere Hintergrundinfos finden Sie in unserem umfassenden Leitfaden zur SSL/TLS- und PKI-Konfiguration, der diese und viele weitere Themen vertieft behandelt.

Gewünschte Ergebnisse:

• Best-Practice-Leitfaden für Kryptographie
• Neue Systeme nach Best-Practice-Prinzipien ausgerollt
• Plan zur Nachbesserung bestehender Systeme nach Best Practice
• Governance-Plan für kontinuierliche Richtlinienüberprüfung und Weiterentwicklung