Der blinde Fleck der privaten PKI: Warum Unternehmen ihre eigenen Zertifikate nicht einsehen können

Die meisten Unternehmen glauben, ihre Zertifikate im Griff zu haben . Sie überwachen die SSL/TLS-Zertifikate ihrer kundenorientierten Websites, reagieren auf Benachrichtigungen ihrer Zertifizierungsstellen bezüglich deren Gültigkeitsdauer und führen möglicherweise eine Liste der ihnen bekannten Zertifikate. Sie gehen mit dem berechtigten Vertrauen davon aus, dass sie rechtzeitig über den Ablauf eines wichtigen Zertifikats informiert werden.

Dieses Vertrauen ist oft unbegründet. Laut einer globalen Studie des Ponemon Institute aus dem Jahr 2026 haben nur 47 % der Unternehmen einen praktischen Überblick darüber, wie viele Zertifikate sie besitzen und wo diese eingesetzt werden. 38 % nennen diese Lücke als größtes Hindernis für die PKI-Sicherheit . Die Zertifikate, die sie nicht einsehen können, sind der Ursprung abgelaufener Anmeldeinformationen und von Ausfällen. Der Druck wächst stetig: Die Entscheidung des CA/Browser Forums aus dem Jahr 2025, die Gültigkeitsdauer öffentlicher TLS-Zertifikate bis 2029 auf bis zu 47 Tage zu verkürzen, lässt Unternehmen, die ihre private PKI-Infrastruktur bereits jetzt nicht einsehen können, keinen Spielraum.

In diesem Blog erklären wir, wo Ihre unsichtbaren Zertifikate gespeichert sind, warum die blinde Stelle in privaten PKI-Umgebungen immer größer wird, welche Kosten entstehen, wenn ein unbekanntes Zertifikat abläuft, und wie die automatisierte Zertifikatserkennung, die für private PKI-Umgebungen entwickelt wurde, diese Lücke schließt.

Was sind Zertifikatstransparenz-Logs?

Certificate Transparency (CT) ist ein öffentliches Prüfframework für die Web-PKI. Wenn eine öffentlich vertrauenswürdige Zertifizierungsstelle ein TLS-Zertifikat ausstellt, muss sie nachweisen, dass dieses gemäß den Anforderungen des Browser-Root-Programms an die Certificate Transparency-Protokolle übermittelt wurde, bevor gängige Browser dem Zertifikat vertrauen. CT-Protokolle sind kryptografisch verifizierbare Datensätze, in denen Einträge hinzugefügt, aber nicht unbemerkt geändert oder entfernt werden können. Dies bietet Domaininhabern, Sicherheitsforschern und automatisierten Überwachungssystemen eine nachvollziehbare Liste öffentlich vertrauenswürdiger Zertifikate, einschließlich solcher, die sie nicht angefordert haben.

Der Mechanismus, der ein Zertifikat mit einem CT-Log verknüpft, ist der Signed Certificate Timestamp (SCT). Wenn ein Log die Übermittlung eines Zertifikats akzeptiert, sendet es einen SCT zurück. Dieser ist ein kryptografisches Versprechen des Logs, dass das Zertifikat innerhalb der maximalen Zusammenführungsverzögerung (Maximum Merge Delay, MMD), typischerweise 24 Stunden gemäß RFC 9162 , in das Log aufgenommen wird . Der SCT kann im Zertifikat eingebettet, über eine OCSP-Antwort übermittelt oder während des TLS-Handshakes bereitgestellt werden. Browser überprüfen die Signatur des SCT bei der Zertifikatsvalidierung und fragen CT-Logs im Allgemeinen nicht in Echtzeit während des Verbindungsprozesses ab.

Die Vertrauenswürdigkeitsprüfung (CT) wird durch die Root-Programmrichtlinien des Browsers und nicht durch das Zertifikat selbst durchgesetzt. Daher müssen öffentlich vertrauenswürdige TLS-Zertifikate in der Regel in den CT-Protokollen erfasst werden. Private und interne Zertifizierungsstellen (CAs) sind nicht in den Browser-Vertrauensspeichern enthalten und unterliegen daher nicht diesen Protokollierungsanforderungen. Folglich fehlen Zertifikate interner CAs üblicherweise in den öffentlichen CT-Protokollen, es sei denn, sie werden absichtlich übermittelt oder über eine private CT-Implementierung protokolliert.

Warum Zertifikatstransparenzprotokolle Ihnen nicht das vollständige Bild zeigen

Die Zertifikatstransparenz wurde als Reaktion auf aufsehenerregende Sicherheitslücken bei Zertifizierungsstellen im Jahr 2011 eingeführt. Der Angriff auf die Registrierungsstelle Comodo am 15. März 2011 führte zur Ausstellung von neun gefälschten Zertifikaten für sieben Domains, darunter mail.google.com, www.google.com, login.yahoo.com und login.skype.com – alles ohne Wissen der Domaininhaber. Fünf Monate später, im August 2011, wurde der DigiNotar-Angriff öffentlich bekannt, als ein Chrome-Nutzer im Iran ein gültiges Wildcard-Zertifikat für *.google.com entdeckte, das zum Abfangen von Gmail-Datenverkehr verwendet wurde. Eine anschließende Untersuchung von Fox-IT identifizierte mindestens 531 betrügerische Zertifikate in der DigiNotar-Infrastruktur.

Certificate Transparency (CT) wurde entwickelt, um die unautorisierte Ausstellung von Zertifikaten öffentlich sichtbar und erkennbar zu machen. Heutzutage müssen öffentlich vertrauenswürdige TLS-Zertifikate einen Nachweis über die Protokollierung von CT-Daten erbringen, bevor sie von den gängigen Browser-Root-Programmen als vertrauenswürdig eingestuft werden. Dadurch entsteht ein nachvollziehbarer Datensatz, anhand dessen Domaininhaber, Forscher und automatisierte Überwachungssysteme unerwartete oder unautorisierte Zertifikatsausstellungen identifizieren können.

Dies stellt eine bedeutende Sicherheitsverbesserung für das öffentliche Web dar. Ein weit verbreitetes Missverständnis besteht darin, dass viele Organisationen die Überwachung vertrauenswürdiger Zertifikate (CT-Monitoring) mit der Zertifikatssichtbarkeit gleichsetzen. Das ist jedoch nicht der Fall. CT bezieht sich primär auf das Web-PKI-Ökosystem öffentlich vertrauenswürdiger Zertifikate. Von privaten oder internen Zertifizierungsstellen ausgestellte Zertifikate werden in der Regel nicht in öffentlichen CT-Protokollen erfasst und sind daher für CT-Überwachungsdienste typischerweise unsichtbar. Externe Scans können sie nicht zuverlässig aufspüren, und ihre Sichtbarkeit hängt vollständig von der internen PKI-Governance, den Inventarisierungsprozessen und den Zertifikatsverwaltungspraktiken der jeweiligen Organisation ab.

Hier die praktische Konsequenz dieser Architektur für eine typische Unternehmensumgebung:

Art des Zertifikats	CT-Protokollstatus	Externe Scan-Sichtbarkeit
Öffentliches TLS (browser-vertrauenswürdig)	Ja: in den CT-Protokollen protokolliert	Sichtbar
Interne Zertifizierungsstellen-/Active Directory-Zertifikatdienste (AD CS)-Zertifikate	Nein: private PKI	unsichtbar
Interner Dienst/API TLS	Nein: CT deckt das nicht ab	unsichtbar
Geräte-/Endpunktzertifikate	Nein: Privatplatzierung	unsichtbar
Container-/Workload-Zertifikate	Nein: Von DevOps herausgegeben, kurzlebig	unsichtbar
Code-Signatur-Zertifikate	Nein: CT deckt nur TLS/SSL ab.	unsichtbar

Die in der obigen Tabelle als unsichtbar gekennzeichneten Zertifikate stellen keine Sonderfälle dar. In den meisten Unternehmen machen interne CA-Zertifikate, die interne Dienste, Geräteauthentifizierung, VPN-Endpunkte, API-Gateways und die Betriebsinfrastruktur abdecken, den größten Teil des Zertifikatsbestands aus. Die von CT-Protokollen erfassten, öffentlich zugänglichen TLS-Zertifikate sind nur ein Bruchteil davon.

Wo Ihre unsichtbaren Zertifikate tatsächlich gespeichert sind

Private PKI-Zertifikate werden nicht zentral gespeichert. Sie werden von verschiedenen Teams auf allen Ebenen der Unternehmensinfrastruktur ausgestellt und eingesetzt, oft ohne zentrale Koordination und fast immer ohne einheitliches Nachverfolgungssystem. Zu verstehen, wo sie konzentriert sind, ist der erste Schritt, um sie zu finden.

Windows-Zertifikatspeicher und Active Directory-Zertifikatdienste

In Umgebungen, die stark auf Microsoft Windows und Active Directory basieren, werden Zertifikate über NDES (Network Device Enrollment Service) mithilfe der Active Directory-Zertifikatdienste (AD CS) direkt an Computer-, Benutzer-, Dienst- und Netzwerkgerätekonten ausgestellt. Diese Zertifikate werden im Windows-Zertifikatspeicher auf jedem Endpunkt, Server und Domänencontroller gespeichert. Ohne einen Erkennungsagenten, der diese Speicher direkt abfragt, gibt es keinen Mechanismus, um festzustellen, welche Zertifikate vorhanden sind, wer sie ausgestellt hat, wann sie ablaufen oder ob Zertifikate bereits überfällig sind. Der Bestand an von AD CS ausgestellten Zertifikaten ist typischerweise die größte einzelne Quelle unsichtbarer Zertifikate in Unternehmensumgebungen.

Interne Webdienste und APIs

Die meisten Unternehmen betreiben eine umfangreiche interne HTTP-Infrastruktur: Intranetportale, HR-Plattformen, Finanzsysteme, Entwicklungstools, Monitoring-Dashboards und interne Dokumentation. Diese Dienste nutzen TLS-Zertifikate, die in der Regel von einer internen Zertifizierungsstelle ausgestellt oder selbstsigniert sind und fast nie zusammen mit öffentlichen Zertifikaten verwaltet werden. Sie werden erneuert, sobald eine Browserwarnung oder ein Dienstausfall gemeldet wird. Sie laufen stillschweigend ab, wenn niemand dies bemerkt.

Netzwerkinfrastruktur

Load Balancer, Reverse-Proxys, API-Gateways, VPN-Konzentratoren und Netzwerkgeräte terminieren TLS-Verbindungen und verwalten Zertifikate. Diese werden häufig einmalig bei der Erstinstallation bereitgestellt und anschließend vergessen. Das Zertifikat ist keinem Lebenszyklus-Tracking-System zugeordnet. Erste Anzeichen für ein abgelaufenes Zertifikat sind typischerweise ein fehlgeschlagener Authentifizierungsvorgang, ein fehlerhafter API-Aufruf oder eine Sicherheitswarnung, die erst im Nachhinein eingeht.

Container und Cloud-Workloads

In containerisierten Umgebungen werden Zertifikate für Workloads, Microservices und Service-Mesh-Sidecars ausgestellt, teilweise automatisch über die integrierten Zertifizierungsstellen (CAs) der Service-Mesh-Steuerungsebenen wie Istiod oder der Identity-Komponente von Linkerd. Die Gültigkeitsdauer von Zertifikaten ist in diesen Umgebungen oft bewusst kurz, was jedoch nicht automatisch Selbstverwaltung bedeutet. Ein Workload-Zertifikat, das nie erkannt wird, kann nicht überwacht werden, und eine Lücke in der automatisierten Erneuerungspipeline bleibt unentdeckt, bis die Authentifizierung des Workloads fehlschlägt. In Kubernetes- und Service-Mesh-Umgebungen werden Secure Production Identity Framework for Everyone ( SPIFFE ) und seine Implementierung SPIFFE Runtime Environment ( SPIRE ) zunehmend für die Workload-Identität eingesetzt und stellen Workloads automatisch kurzlebige X.509-SVIDs aus. SPIFFE reduziert die manuelle Ausstellung, doch auch diese Zertifikate erfordern Transparenz und die Integration in Governance-Systeme.

IoT- und Betriebstechnologiegeräte

Gerätezertifikate für physische Endgeräte (Industriesensoren, Zutrittskontrollsysteme, Drucker, Netzwerkgeräte und medizinische Geräte) gehören zu den am wenigsten verwalteten Zertifikatsbeständen in Unternehmen. Sie werden bei der Gerätebereitstellung ausgestellt und anschließend selten überprüft. In großen Geräteflotten ist die Wahrscheinlichkeit hoch, dass ein Teil der Gerätezertifikate abgelaufen ist oder demnächst abläuft. Die Wahrscheinlichkeit, dass jemand im Unternehmen einen aktuellen und genauen Überblick über diese Zertifikate hat, ist sehr gering.

Code-Signatur-Zertifikate

Interne Codesignaturzertifikate , die zum Signieren von Software-Builds, Skripten, Treibern und Firmware verwendet werden, stellen einen bedeutenden Anteil der privaten PKI in Finanz-, Verteidigungs- und Softwareunternehmen dar. Da sie von internen Zertifizierungsstellen und nicht von öffentlichen ausgestellt werden, bergen sie dasselbe Problem der Unsichtbarkeit wie andere interne Zertifikate, jedoch mit einem zusätzlichen Risiko: Ein kompromittierter oder abgelaufener Codesignaturschlüssel kann entweder legitime Releases blockieren oder, schlimmer noch, einem Angreifer ermöglichen, Schadcode zu signieren, dem nachgelagerte Systeme vertrauen.

Der Faktor Maschinenidentität: Warum der blinde Fleck wächst

Das Problem der Transparenz privater PKI ist nicht statisch. Es verschärft sich, vor allem aufgrund des rasanten Wachstums nicht-menschlicher Identitäten: Dienstkonten, Workload-Anmeldeinformationen, API-authentifizierte Dienste und automatisierte Agenten, die in den meisten Unternehmensumgebungen die menschlichen Identitäten mittlerweile bei Weitem übertreffen.

Untersuchungen von Rubrik Zero Labs schätzen, dass Maschinenidentitäten in modernen Unternehmen die menschlichen Identitäten um etwa das 82-Fache übertreffen. Branchenspezifische Studien berichten von deutlich höheren Verhältnissen in bestimmten Sektoren. Die automatisierte Lebenszyklusverwaltung von Maschinenidentitäten ist nach wie vor die Ausnahme, weshalb die meisten Organisationen auf manuelle Nachverfolgung oder Ad-hoc-Prozesse angewiesen sind, die bei diesen Verhältnissen nicht skalierbar sind.

Anders als bei menschlichen Identitäten, deren Lebenszyklus durch HR-gesteuerte Prozesse wie Onboarding und Offboarding strukturiert ist, werden Maschinenidentitäten von Entwicklern, Infrastruktur-Pipelines und automatisierten Tools erstellt – oft ohne zentrale Kontrolle. Ein Servicekonto-Zertifikat, das 2023 für ein Proof-of-Concept-Projekt erstellt wurde, kann 2026 noch aktiv sein und Zugriffsrechte gewähren, die seit Projektende nicht mehr überprüft wurden. Ein Workload-Zertifikat kann die Gültigkeit des von ihm authentifizierten Workloads überdauern und noch lange nach der Außerbetriebnahme des Dienstes in einem Truststore verbleiben.

Das Ergebnis ist eine Zertifikatsflut: eine Anhäufung von Maschinenidentitätszertifikaten in verschiedenen Umgebungen, die keinem einzelnen Team gehören, die von keinem Inventarsystem erfasst wurden und die ohne Vorwarnung ablaufen, weil nie ein Erneuerungsprozess für sie eingerichtet wurde.

Was es kostet, wenn ein unbekanntes Zertifikat abläuft

Die geschäftlichen Folgen eines abgelaufenen Zertifikats, dessen Existenz niemand bemerkt hat, sind nicht nur theoretischer Natur. Laut Red Sift belaufen sich die durchschnittlichen Kosten eines einzelnen zertifikatsbedingten Ausfalls auf 500,000 bis 5 Millionen US-Dollar. Diese Kosten umfassen Ausfallzeiten, Reaktionszeiten der Techniker, Auswirkungen auf Kunden und Reputationsschäden. Bei internen Diensten wie Authentifizierungsplattformen, API-Gateways und internen SaaS-Integrationen sind die Folgen oft noch gravierender, da sie sich auf alle Dienste auswirken, die von der fehlgeschlagenen Authentifizierung abhängen.

Laut einer Studie des Ponemon Institute aus dem Jahr 2026 meldeten 56 % der Unternehmen im Vorjahr ungeplante Ausfallzeiten aufgrund abgelaufener oder falsch konfigurierter Zertifikate. Für den privaten PKI-Teil des Zertifikatsbestands, der von den meisten Überwachungstools nicht erfasst wird, dürfte diese Zahl die tatsächliche Ausfallrate unterschätzen. Denn viele zertifikatsbezogene Fehler in der internen Infrastruktur werden fälschlicherweise als „Dienstbeeinträchtigungen“ oder „Authentifizierungsfehler“ eingestuft, anstatt zum Zeitpunkt ihres Auftretens korrekt als abgelaufene Zertifikate erkannt zu werden.

Neben Ausfällen gewinnt die Offenlegung von Zertifikaten zunehmend an Bedeutung für die Einhaltung regulatorischer Vorgaben. Regulatorische Rahmenwerke wie PCI-DSS , ISO 27001 und NIST 800-53 enthalten explizite Anforderungen an die Verwaltung kryptografischer Assets: Inventarisierung, Lebenszykluskontrolle, Algorithmenstandards und Widerrufsmöglichkeiten. NIST 800-53 Rev. 5 sieht hierfür spezifische Kontrollen vor: SC-12 regelt die Erstellung und Verwaltung kryptografischer Schlüssel, während SC-17 die Ausstellung und Verwaltung von PKI-Zertifikaten regelt. Auditoren stellen vermehrt gezielte Fragen zur Verwaltung privater PKIs, und die Antwort „Wir überwachen unsere öffentlichen Zertifikate“ genügt diesen Anforderungen nicht, wenn der Großteil der Zertifikate intern verwaltet wird.

Wie man die Transparenzlücke in der privaten PKI schließt: ein 4-Schritte-Ansatz

Die Schließung der Lücke in der privaten PKI ist kein einmaliges Projekt. Es geht um einen Wandel von reaktiver, unvollständiger Transparenz hin zu kontinuierlicher, umfassender Zertifikatsverwaltung. Die folgenden vier Schritte stellen den praktischen Weg dar, den Organisationen mit ausgereiften Zertifizierungsprogrammen beschreiten:

1. Kontinuierliche automatisierte Erkennung bereitstellen
   Führen Sie einen automatisierten Erkennungsagenten in jeder Umgebung aus: Windows-Zertifikatspeicher, IISLinux-Server, Load Balancer, Netzwerkgeräte, Cloud-Workloads, Kubernetes-Umgebungen und Container. Die Erkennung muss kontinuierlich erfolgen und darf nicht nur eine einmalige Prüfung sein. Neue Zertifikate werden fortlaufend ausgestellt; manuelle Snapshots sind daher immer veraltet, bevor sie abgeschlossen sind.
2. Jedes Zertifikat klassifizieren und einen Verantwortlichen zuweisen
   Jedes gefundene Zertifikat muss einem Systemverantwortlichen und einem Geschäftskontext zugeordnet werden: welches Team zuständig ist, welcher Dienst dadurch geschützt wird, wann es ausgestellt wurde und wann es abläuft, wer die ausstellende Zertifizierungsstelle (CA) ist und welcher Algorithmus und welche Schlüssellänge verwendet werden. Zertifikate ohne Verantwortlichen laufen stillschweigend ab.
3. Zusammenführung von öffentlichen und privaten Inventaren auf einer einzigen Plattform
   Alle gefundenen Zertifikate – öffentliche und private, interne und externe, für Menschen und Maschinen – sollten in einem zentralen, verwalteten Inventar mit standardisierten Metadaten zusammengeführt werden. Separate Inventare für verschiedene Zertifikatstypen führen zu denselben Sicherheitslücken, die sie eigentlich verhindern sollen.
4. Lebenszyklusrichtlinien durchsetzen und Verlängerung automatisieren
   Mit einem vollständigen, eigenen Bestandsverzeichnis wird die Lebenszyklusautomatisierung zuverlässig. Legen Sie Erneuerungsschwellenwerte für jeden Zertifikatstyp fest und konfigurieren Sie die ACME-basierte automatische Erneuerung, sofern unterstützt (ACME, RFC 8555, wird von vielen modernen CA-Plattformen und CLM-Tools unterstützt, insbesondere für öffentliche PKI-Umgebungen; Umgebungen ohne native ACME-Unterstützung können EST verwenden (RFC 7030), CMP (RFC 4210), oder SCEP für ältere Geräteumgebungen), und stellen Sie sicher, dass eine Warnung ausgelöst wird, wenn ein Zertifikat abläuft, ohne dass bereits ein Erneuerungsprozess läuft.

Sicherheitsüberlegungen

Die Transparenz privater PKI-Zertifikate zu erlangen, ist ein unerlässlicher erster Schritt, doch die für die Umsetzung dieser Transparenz erforderlichen betrieblichen und sicherheitstechnischen Maßnahmen verdienen ebenso viel Aufmerksamkeit. Die Widerrufsinfrastruktur für private PKI ( interne CRL-Verteilungspunkte und OCSP-Responder ) muss ebenfalls während der Ermittlung geprüft werden: Ein gefundenes Zertifikat, dessen Widerrufsendpunkt der ausstellenden Zertifizierungsstelle jedoch nicht erreichbar oder falsch konfiguriert ist, stellt auch nach Aufnahme in den verwalteten Bestand eine Governance-Lücke dar.

Bei einer ersten Bestandsaufnahme entdeckte Zertifikate weisen häufig auf eine Anhäufung schwacher Algorithmen, veralteter Schlüssellängen oder Zertifikate mit zu breiten SANs hin. Die Behebung dieser Mängel sollte neben den ablaufbasierten Erneuerungsprozessen priorisiert werden. Eine genaue Bestandsaufnahme ist zudem Voraussetzung für die Post-Quantum-Bereitschaft : Unternehmen müssen wissen, welche Zertifikate RSA oder ECC verwenden, bevor sie die Migration zu den NIST-standardisierten PQC-Algorithmen (ML-KEM, ML-DSA und SLH-DSA gemäß FIPS 203/204/205) planen können.

Wildcard-Zertifikate, die alle Subdomains der ersten Ebene einer Domain anstatt einzelner Hostnamen sichern, kommen häufig in internen PKI-Umgebungen vor und werden oft für viele Dienste wiederverwendet. Sie sollten sorgfältig überwacht werden; ein einziges kompromittiertes oder abgelaufenes Wildcard-Zertifikat kann eine große Anzahl abhängiger Dienste gleichzeitig beeinträchtigen. Nach Ablauf der Gültigkeit ermöglicht ein kompromittierter privater Wildcard-Schlüssel einem Angreifer, sich als jeder von diesem Wildcard-Zertifikat abgedeckte Dienst auszugeben – ein besonders folgenreiches Szenario in internen Umgebungen, in denen Mutual TLS zur Dienstauthentifizierung verwendet wird.

Die Zuordnung der Zertifikatsinhaberschaft ist einer der schwierigsten Aspekte einer ersten Bestandsaufnahme, da viele Zertifikate von Personen ausgestellt wurden, die das Unternehmen inzwischen verlassen haben. Legen Sie klare Richtlinien für die Zuordnung der Inhaberschaft verwaister Zertifikate fest, bevor deren Ablauf eine Krisenentscheidung erzwingt.

Überwachen Sie die Erkennungspipeline selbst, nicht nur die gefundenen Zertifikate. Ein Erkennungsagent, der keine Ergebnisse mehr meldet, liefert nicht null Ergebnisse, sondern gar keine. Dies mag in einem schlecht überwachten Inventarsystem zwar gleich aussehen, bedeutet aber, dass es ein Problem mit der Transparenz und nicht mit der Abdeckung gibt.

Bei Zertifikaten, die auf IoT- oder OT-Geräten gefunden werden und nicht ohne Weiteres kurzfristig ersetzt werden können, sollten diese sofort gekennzeichnet und mit der Planung von Ersatz- oder Erneuerungsverfahren mit verlängerter Gültigkeit begonnen werden, die den Einschränkungen der Geräteverwaltung in diesen Umgebungen Rechnung tragen.

Wie CertSecure Manager die Schwachstelle der privaten PKI behebt

CertSecure Manager ist die Enterprise-Plattform für das Zertifikatslebenszyklusmanagement von Encryption Consulting. Sie wurde entwickelt, um Sicherheits- und Betriebsteams die zentrale Kontrolle über ihren gesamten Zertifikatsbestand in internen und öffentlichen Zertifizierungsstellen sowie in hybriden Umgebungen zu ermöglichen. Die Plattform schließt die Lücke in der Transparenz privater PKI-Systeme, die durch externe Scans und die Überwachung von CT-Logs nicht abgedeckt werden kann.

Die Erkennungsfunktionen von CertSecure Manager umfassen sowohl agentenbasierte als auch agentenlose Methoden und ermöglichen so den Zugriff auf Zertifikatsbestände, die bei reinen Netzwerkscans nicht erfasst werden. Unter Windows fragt es Zertifikatsspeicher auf in die Domäne eingebundenen Endpunkten und Servern direkt ab und deckt damit die sonst unsichtbaren, von ADCS ausgestellten Zertifikate auf. Unter Linux und in der Netzwerkinfrastruktur identifiziert es TLS-Zertifikate auf Diensten und Appliances, ohne dass Agenten benötigt werden, wenn diese nicht installiert werden können.

Die Plattform normalisiert alle gefundenen Zertifikate unabhängig von ausstellender Zertifizierungsstelle, Bereitstellungsumgebung oder Zertifikatstyp in einem einzigen Inventar mit einheitlichen Metadaten: Ablaufdatum, ausstellende Zertifizierungsstelle, Algorithmus, Schlüssellänge, Bereitstellungsort und zugewiesener Inhaber. Auf Basis dieses einheitlichen Inventars lassen sich Lebenszyklusrichtlinien konsistent anwenden, die Erneuerungsautomatisierung konfigurieren und Benachrichtigungen für den gesamten Zertifikatsbestand einrichten, anstatt nur für einen bekannten Teil davon.

• Umfassende Entdeckung: Umgebungsübergreifende Erkennung von Windows Stores, IIS, Linux-Endpunkten, Load Balancern und Netzwerkinfrastruktur in einem einzigen Durchgang.
• Einzellagerbestand: Einheitliches Inventar, das öffentliche und private Zertifikate mit vollständigen Metadaten normalisiert, ohne separate Systeme für verschiedene Zertifikatstypen.
• Richtlinienbasierte Warnmeldungen: Konfigurierbare Benachrichtigungen bei Ablauf von Schwellenwerten, Algorithmenveraltung, Änderungen der CA-Vertrauenswürdigkeit und Richtlinienverstößen, die sich auf das gesamte Objekt beziehen, nicht nur auf eine Teilansicht.
• Erneuerungsautomatisierung: ACME-Protokoll Integration für die automatisierte Verlängerung, sofern unterstützt, und workflowgesteuerte Verlängerung für Umgebungen, die manuelle Schritte erfordern.
• Compliance-Berichterstattung: Auditfähige Berichterstattung, die die Governance des gesamten Lebenszyklus sowohl öffentlicher als auch privater Zertifikatsbestände als Nachweis der Konformität aufzeigt.

Encryption Consulting unterstützt Sie in jeder Phase der Zertifikatstransparenz – von einer ersten strukturierten Analyse bis hin zu einem vollständig automatisierten CLM-Programm für hybride Umgebungen. Unsere CLM-Readiness-Assessments gleichen Ihren Zertifikatsbestand mit bekannten und unbekannten Datenbeständen ab, identifizieren Lücken in Ihren bestehenden Tools und erstellen einen priorisierten Aktionsplan, der Ihre Compliance-Anforderungen und Ihr operationelles Risikoprofil berücksichtigt. Unser Implementierungsteam verfügt über praktische Erfahrung in der Bereitstellung von Discovery-Lösungen für Windows AD CS, Linux, Netzwerkgeräte und Containerumgebungen.

Fazit

Die Lücke in der Transparenz privater PKIs schließt sich nicht von selbst. Die Anzahl der Zertifikate steigt quartalsweise. Die Anzahl der Maschinenidentitäten nimmt zu. Die Diskrepanz zwischen dem, was Organisationen zu verwalten glauben, und dem, was tatsächlich in ihrer Infrastruktur existiert, vergrößert sich kontinuierlich und unbemerkt, da die Zertifikate, die dieses Wachstum antreiben, für alle Tools, die auf öffentlichen Daten basieren, unsichtbar sind.

Um diese Lücke zu schließen, ist eine automatisierte Erkennung erforderlich, die speziell für private PKI-Umgebungen entwickelt wurde: eine Erkennung, die kontinuierlich läuft, jede Umgebung erreicht, in der Zertifikate bereitgestellt werden, die Ergebnisse in einem einheitlichen Inventar normalisiert und die Lebenszyklusrichtlinie von diesem Inventar an durchsetzt.

Um mehr darüber zu erfahren, wie CertSecure Manager die Transparenzlücke Ihrer privaten PKI schließt, oder um eine Zertifikatserkennungsbewertung mit unserem Team zu besprechen, wenden Sie sich an Encryption Consulting.