ARTEFAKTUM / EXPERTISE / CYBERSICHERHEIT & DIGITAL TRUST
Warum unbekannte Zertifikate und fremde Root-CAs in sicherheitskritischen IT- und OT-Umgebungen zu einer Frage von Vertrauen, Kontrolle und digitaler Souveränität werden.
Die Verschlüsselung ist stark. Die Zertifikatskette ist formal gültig. Der Browser meldet keinen Fehler. Und trotzdem kann die Verbindung an einer Stelle enden, die der Betreiber nie autorisiert hat. Wer in sicherheitskritischen Netzen ausschließlich die Kryptografie prüft, übersieht mitunter die wichtigere Frage: Wer entscheidet eigentlich darüber, welchen digitalen Identitäten vertraut wird?
Die Antwort liegt in den Trust Stores von Betriebssystemen und Anwendungen, in privaten Zertifizierungsstellen, in Cloud-Diensten und den oft kaum dokumentierten Abhängigkeiten zwischen Unternehmen und Zulieferern. An genau diesen Übergängen entstehen Shadow Certificates – Zertifikate, die in einer IT- oder OT-Umgebung eingesetzt werden, ohne Teil des offiziell überwachten Zertifikatsbestands zu sein. Meist beginnt das unspektakulär: Ein Entwickler braucht kurzfristig mTLS für einen Teststand. Ein Dienstleister bringt eine eigene CA mit. Ein VPN-Gateway wird mit einem selbst ausgestellten Zertifikat in Betrieb genommen. Ein Cloud-Service rotiert Schlüssel außerhalb der zentralen Prozesse. Nicht die böse Absicht ist das verbindende Merkmal, sondern der Verlust der Kontrolle.
Für die Verteidigungsindustrie ist das mehr als ein operatives IT-Thema. Hier hängen digitale Identitäten an Konstruktionsdaten, Produktlebenszyklen, Zulieferketten, Testinfrastrukturen und gegebenenfalls staatlich eingestuften Informationen. Eine fehlerhafte Vertrauensentscheidung kann zur Schwachstelle werden, bevor eine Firewall oder ein Intrusion-Detection-System überhaupt einen Angriff erkennt. Das US-amerikanische NIST beschreibt in SP 1800-16 die Folgen unzureichenden TLS-Zertifikatsmanagements ausdrücklich als Risiko für Verfügbarkeit, Datenvertraulichkeit und Wiederherstellungsfähigkeit. Die Frage nach der Herkunft und Reichweite von Vertrauensankern geht jedoch noch darüber hinaus.
Die zentrale Erkenntnis: Ein technisch gültiges Zertifikat ist kein Beleg für eine organisatorisch vertrauenswürdige Gegenstelle. Seine Aussage ist nur so belastbar wie die Regeln, nach denen das Endgerät die ausstellende Zertifizierungsstelle akzeptiert.
Das eigentliche Schattenreich liegt hinter dem Zertifikat
In der Praxis wird der Begriff Shadow Certificate häufig zu eng verwendet. Gemeint sind dann vor allem nicht inventarisierte Serverzertifikate, deren Ablaufdatum niemand überwacht. Das ist bereits ein erhebliches Problem: Läuft das Zertifikat einer Produktionsschnittstelle oder eines Remote-Maintenance-Gateways ab, kann ein eigentlich funktionsfähiges System ausfallen. Ein wesentlich schwierigeres Risiko liegt aber eine Ebene höher. Denn zu jedem ausgestellten Zertifikat gehört eine Vertrauensbeziehung zu einer ausstellenden CA, und jede CA verweist in der Regel über eine Zertifikatskette auf einen Trust Anchor – einen lokal oder über Software vorgegebenen Vertrauensanker.
Ein X.509-Zertifikat enthält unter anderem Identitätsangaben, einen öffentlichen Schlüssel, Angaben zum Aussteller, Gültigkeitsgrenzen, zulässige Verwendungszwecke und eine Signatur. Es enthält nicht die Garantie, dass die Organisation hinter dem Aussteller vertrauenswürdig handelt. Diese Bewertung trifft letztlich die Vertrauenskonfiguration des prüfenden Systems. Ist dort eine Root-CA akzeptiert, können unter geeigneten technischen Voraussetzungen Zertifikate aus ihrer Hierarchie als gültig erscheinen. Bei einer fehlerhaft berechtigten Intermediate-CA kann sich dieselbe Problematik fortsetzen; Einschränkungen wie Basic Constraints, Name Constraints und Verwendungszwecke müssen dabei wirksam überprüft werden.
Damit sind drei unterschiedliche Sachverhalte sauber zu trennen: Ein unbekanntes Endzertifikat ist zunächst ein Inventar- und Prozessproblem. Eine unbekannte oder unzulässig berechtigte CA ist ein Problem der Authentizitätsprüfung. Und ein absichtlich installiertes, fremdgesteuertes Root-Zertifikat kann – in Verbindung mit Kontrolle über den Datenpfad – die technische Voraussetzung schaffen, TLS-Verbindungen unbemerkt aufzutrennen. Nicht jedes Shadow Certificate ist deshalb gefährlich. Umgekehrt kann eine einzelne unkontrollierte Root-CA gefährlicher sein als Tausende unverwaltete, aber sauber ausgestellte Serverzertifikate.
Wie eine fremde Root-CA zur Schaltstelle der Kommunikation wird
Bei einer regulären TLS-Verbindung prüft der Client die Identität des angesprochenen Dienstes anhand des Zertifikats und seiner Vertrauenskette. Ist diese Prüfung erfolgreich und der Handshake abgeschlossen, kommunizieren Client und Dienst über einen geschützten Kanal. Wird jedoch eine zusätzliche CA in die Vertrauensbasis des Clients aufgenommen, kann ein zwischengeschalteter TLS-Inspection-Proxy unter Verwendung eines von dieser CA akzeptierten Zertifikats als scheinbar legitimer Kommunikationspartner auftreten. Der Proxy baut dann typischerweise zwei getrennte TLS-Verbindungen auf: eine zum Client und eine zum eigentlichen Zielsystem. Im Proxy liegt der Datenverkehr zwischen Entschlüsselung und erneuter Verschlüsselung im Klartext vor.
Schematische Darstellung. Eine zusätzlich vertraute CA allein entschlüsselt noch keinen Verkehr: Erforderlich sind außerdem ein passender aktiver Kommunikationspfad und eine tatsächlich akzeptierte Zertifikatskette. Ende-zu-Ende-Verschlüsselung auf Anwendungsebene kann eine zusätzliche Schutzschicht bilden.
Das ist kein theoretischer Kryptografiefehler und auch keine „Entschlüsselung“ bereits aufgezeichneter, korrekt abgesicherter TLS-Sitzungen. Es handelt sich um die Verlagerung des Vertrauens auf einen anderen Endpunkt während des Verbindungsaufbaus. Kontrollierte TLS-Inspection kann als legitime Sicherheitsfunktion eingesetzt werden; sie braucht dann allerdings eine explizite Architekturentscheidung, abgesicherte Schlüssel, eng definierte Ausnahmen, Protokollierung und einen rechtlich wie organisatorisch tragfähigen Betriebsrahmen. Selbst die US-amerikanische NSA behandelt TLS-Inspection als eigenes Risikothema. Die sicherheitspolitisch brisante Variante entsteht dort, wo Dritte diese Vertrauensposition ohne wirksame Kontrolle des betroffenen Unternehmens erlangen.
Staatliche Zertifizierungsstellen: Belegte Vorfälle statt unbelegter Verdächtigungen
Im Juli 2019 berichteten Nutzer in Kasachstan, dass Internetprovider von ihnen die Installation eines staatlich ausgegebenen Root-Zertifikats verlangten. Nach den von Mozilla im August 2019 veröffentlichten Erkenntnissen wurde das Zertifikat zur Interception von Verbindungen zu zahlreichen populären Diensten verwendet. Mozilla und Google blockierten daraufhin das als „Qaznet Trust Network“ bekannte Zertifikat technisch; Google veröffentlichte dazu auch den SHA-256-Fingerprint und die Chrome-Gegenmaßnahmen. Im Dezember 2020 meldete Mozilla einen erneuten entsprechenden Vorgang; nach dieser Mitteilung reagierten Mozilla, Apple, Google und Microsoft mit Sperren.
Der Fall zeigt, warum ein staatliches Root-Zertifikat nicht allein als technische Vertrauenskomponente bewertet werden darf. Politischer oder regulatorischer Druck kann die Installation eines fremden Vertrauensankers erzwingen. Für den Nutzer kann die Wahl faktisch auf die Akzeptanz des Zertifikats oder den Verlust des Zugangs zu bestimmten Diensten reduziert sein. Entscheidend ist dabei die genaue Formulierung: Der dokumentierte Fall betrifft angeforderte Installationen, nicht den Beweis für weltweit heimlich vorinstallierte Staatszertifikate. Gerade weil solche Fragen politisch aufgeladen sind, muss ein CISO nachweisbare Vertrauensanker, Zertifikatspfade und Gerätekonfigurationen prüfen – nicht Herkunftsländer pauschal mit Kompromittierung gleichsetzen.
Ein weiterer, technisch aufschlussreicher Vorfall wurde 2013 bekannt. Google meldete unautorisierte Zertifikate für Google-Domains aus einer Intermediate-CA im Umfeld der französischen ANSSI. Nach der damals veröffentlichten Erklärung war diese Intermediate-CA in einem kommerziellen Gerät zur Überprüfung verschlüsselter Kommunikation innerhalb eines privaten Netzes mit Wissen der dortigen Nutzer verwendet worden; Google sperrte die betreffende Zertifikatskette. Das ist ausdrücklich kein Beleg staatlicher Spionage. Der Vorfall illustriert vielmehr, dass eine eigentlich vertrauenswürdige CA-Hierarchie auch durch zweckwidrige Ausgestaltung oder Delegation zur unerwarteten Identitätsautorität werden kann.
2014 dokumentierte Google weitere unautorisierte Zertifikate für Google-Domains aus der Hierarchie des indischen National Informatics Centre. Die Betroffenheit unterschied sich je nach Root Store und Plattform. Genau diese Unterschiede sind für große, heterogene Anlagen von Bedeutung: Eine Zertifikatskette kann auf einem Betriebssystem akzeptiert und auf einem anderen abgewiesen werden. „Der Hersteller vertraut der CA“ ist keine hinreichende Antwort auf die Frage, welche konkrete Anwendung auf welchem Gerät ihr tatsächlich vertraut.
Eine notwendige Präzisierung: Staatlich betrieben, staatlich reguliert und staatlich missbraucht sind drei verschiedene Kategorien. Aus der Herkunft einer CA folgt weder ihre Unzuverlässigkeit noch eine nachgewiesene Überwachung. Bewertet werden müssen ihre tatsächlichen technischen Rechte, ihre Governance und das konkrete Einsatzszenario.
Das unsichtbare Problem: Es gibt nicht den einen Trust Store
Viele Organisationen prüfen die Zertifikate ihrer öffentlichen Domains mit großer Sorgfalt und übersehen gleichzeitig die Vertrauensbasis ihrer Endgeräte. Windows unterhält eigene Vertrauens- und Sperrlisten, die unter bestimmten Bedingungen automatisch aktualisiert werden. Anwendungen können wiederum andere Quellen verwenden: Firefox, Java-Laufzeiten, containerisierte Workloads, eingebettete Systeme oder dedizierte Middleware folgen abhängig von Produkt, Version und Konfiguration unterschiedlichen Mechanismen. Microsoft dokumentiert die Aktualisierung und Verwaltung der Windows-Trust-Lists; das britische NCSC erklärt die zugrunde liegende Vertrauensarchitektur der Web-PKI.
Ein Nutzer sieht deshalb nicht zwangsläufig sämtliche für seine Anwendung maßgeblichen Vertrauensanker in einer einzigen grafischen Oberfläche. Mozilla dokumentiert einen bemerkenswert konkreten Fall: Unter Windows kann Firefox zusätzlich vertraute Zertifizierungsstellen aus dem Betriebssystem für die Serverauthentifizierung übernehmen, ohne sie zwingend im eigenen Zertifikatsmanager anzuzeigen. Das ist eine reguläre Verwaltungsfunktion und für sich genommen kein Angriff. Es zeigt allerdings, wie schnell eine oberflächliche Kontrolle zum falschen Ergebnis führen kann.
In verwalteten Umgebungen können Richtlinien, Mobile-Device-Management, vorinstallierte Images und Herstellerkomponenten die Konfiguration bestimmen und individuelle Änderungen verhindern. Das kann gewollt und sicherheitstechnisch sinnvoll sein. Problematisch wird es, wenn selbst die verantwortliche Organisation nicht nachvollziehen kann, wer einen Root-Eintrag erzeugt hat, welche Anwendung ihn berücksichtigt, welche Änderung ihn autorisiert und wie schnell er entzogen werden kann.
Gerade in der Rüstungsindustrie ist diese Differenz relevant. Ein Entwicklungsrechner kann mit einem anderen Root Store arbeiten als ein Prüfstand. Eine Java-Anwendung kann Zertifikate aus einem anwendungsspezifischen Keystore verwenden. Ein Container-Image kann eine veraltete CA-Liste mitbringen. Ein externer Service-Techniker kann über ein verwaltetes Notebook auf einer fremden Sicherheitsbaseline arbeiten. Ein eingebetteter Controller lässt möglicherweise nur über ein signiertes Firmware-Update Änderungen an seiner Vertrauensbasis zu. Für jedes dieser Beispiele gilt: Das Risiko ist nicht automatisch eine vorhandene Hintertür. Das Risiko liegt in der fehlenden Nachweisbarkeit der tatsächlich wirksamen Vertrauensbeziehungen.
Warum sich das Risiko in der Verteidigungsindustrie potenziert
Ein Rüstungsunternehmen betreibt keine homogene Büro-IT. Zwischen Entwicklung, Simulation, Fertigung, Qualifikation und Instandhaltung bestehen oft langlebige technische Vertrauensbeziehungen. Product-Lifecycle-Management-Systeme tauschen Konstruktionsstände mit Zulieferern aus. Prüfstände übermitteln Messdaten an Auswertungssysteme. Fernwartungszugänge verbinden Hersteller und Betreiber über Organisationsgrenzen. Software-Updates, signierte Pakete und Geräteidentitäten folgen wieder eigenen Zertifikats- und Schlüsselhierarchien. Die digitale Lieferkette ist damit nicht nur eine Kette von Unternehmen, sondern auch eine Kette delegierter technischer Autoritäten.
Man stelle sich ein ausdrücklich hypothetisches Szenario vor: Ein Zulieferer liefert eine Diagnosekomponente für einen Teststand. Ihre Dokumentation verlangt die Installation einer mitgelieferten Root-CA, damit die Software mit einem Remote-Dienst kommunizieren kann. Die IT genehmigt den Vorgang als betrieblichen Sonderfall; die Berechtigung wird später jedoch nie auf den ursprünglich benötigten Dienst begrenzt oder wieder entfernt. Wenn der Vertrauensanker für allgemeine Serverauthentifizierung akzeptiert wird und ein Angreifer darüber hinaus den Netzwerkpfad kontrollieren kann, entsteht eine mögliche Grundlage für die Nachbildung anderer Serveridentitäten. Ob dies tatsächlich gelingt, hängt von Zertifikatseinschränkungen, Applikationsvalidierung, Netzarchitektur und zusätzlichen Schutzmechanismen ab. Die Sicherheit des Teststands kann dennoch von einer externen Schlüssel- und Richtlinienverwaltung abhängen, die niemand im Hauptunternehmen auditiert.
Diese Konstellation ist besonders heikel, wenn Entwicklungswissen, kryptografisches Schlüsselmaterial, Quellcode, Stücklisten, Komponentenspezifikationen, Exportkontrolldaten oder Informationen mit einem besonderen Schutzbedarf über dieselben technischen Grenzen fließen. Die denkbaren Folgen reichen von der Offenlegung geistigen Eigentums bis zu verfälschten Konfigurationsständen und erschwerter forensischer Rekonstruktion. Bei missionskritischen Systemen kommt die Verfügbarkeit hinzu: Wer Zertifikatswechsel, Sperrung und Vertrauensanker-Updates nicht beherrscht, riskiert ungeplante Unterbrechungen in Test, Produktion oder Wartung.
Für Netze mit besonderen Geheimschutz-, Kunden- oder Akkreditierungsvorgaben muss die Beurteilung anhand der konkret geltenden Sicherheitsarchitektur erfolgen. Ein pauschaler Verweis auf ISO 27001, NIS2 oder ein TLS-konformes Produkt ersetzt weder eine projektspezifische Freigabe noch den Nachweis einer kontrollierten PKI. Auch die BSI TR-02102-2 formuliert Empfehlungen zur sicheren Verwendung von TLS; sie ist kein Freibrief für beliebige zusätzliche Vertrauensanker.
Warum Certificate Transparency und CAA das Problem nicht allein lösen
Certificate Transparency (CT) ist ein bedeutender Fortschritt für die öffentliche Web-PKI. Öffentlich vertrauenswürdige TLS-Zertifikate können in überprüfbaren Logs nachvollzogen werden; eine unerwartete Ausstellung für eine eigene Domain wird dadurch eher sichtbar. Die technische Grundlage ist unter anderem in RFC 9162 beschrieben. Doch CT ist kein universelles Register aller kryptografischen Identitäten. Chromes eigene Dokumentation erläutert ausdrücklich, dass für lokal vertraute, nicht öffentlich anerkannte CAs die öffentliche CT-Pflicht nicht greift. Gerade privat ausgestellte oder auf einem Endgerät zusätzlich legitimierte Zertifikate können daher außerhalb dieser Sichtbarkeit liegen.
Auch DNS-CAA-Einträge sind kein Ersatz für eine kontrollierte Vertrauensbasis. Sie erlauben Domaininhabern, zulässige öffentliche Zertifizierungsstellen für ihre Domains zu benennen; die Einzelheiten regelt RFC 8659. Ein lokal als vertrauenswürdig eingestufter, nicht öffentlich anerkannter Aussteller, der innerhalb einer TLS-Inspection-Infrastruktur Zertifikate erzeugt, wird dadurch aber nicht automatisch technisch unterbunden. Ebenso wenig beweist eine unauffällige Zertifikatswarnungsanzeige, dass tatsächlich eine durchgehend unvermittelte Verbindung bis zum vorgesehenen Zielsystem besteht.
Die Lage wird durch moderne Protokolle anspruchsvoller. In TLS 1.3 werden die Authentisierungsnachrichten mit den Zertifikatsinformationen nach dem Aufbau der Handshake-Schlüssel verschlüsselt; darauf verweist RFC 9846. Eine rein passive Netzwerkanalyse kann die tatsächlich genutzten Zertifikate daher nicht ohne Weiteres aus jeder Verbindung auslesen. Sicherheitsverantwortliche benötigen einen Methodenmix aus aktiven Prüfungen, Host- und Anwendungsinventarisierung, Konfigurationsanalysen und nachvollziehbaren Ereignissen aus Zertifikatsdiensten. Ein Dashboard, das nur öffentliche Websites abfragt, beantwortet nicht die Frage nach den Zertifikaten in einem Testnetz oder einer isolierten Entwicklungsumgebung.
Die operative Kontrollgrenze: CT zeigt, was in der öffentlichen Web-PKI ausgestellt wurde. Eine Trust-Store-Prüfung zeigt, wem das konkrete Gerät vertraut. Für sicherheitskritische Entscheidungen werden beide Perspektiven benötigt – ergänzt um die tatsächliche Zertifikatsnutzung in Anwendungen und Systemen.
Kürzere Laufzeiten lösen nur die halbe Aufgabe
Seit dem 15. März 2026 dürfen neu ausgestellte, öffentlich vertrauenswürdige TLS-Serverzertifikate nach dem beschlossenen Zeitplan des CA/Browser Forum grundsätzlich höchstens 200 Tage gültig sein. Für den 15. März 2027 ist die nächste Absenkung auf 100 Tage, für den 15. März 2029 auf 47 Tage vorgesehen. Die Details stehen in Ballot SC-081v3 und den Baseline Requirements. Diese Regeln betreffen den öffentlichen TLS-Zertifikatsmarkt – sie dürfen nicht undifferenziert auf interne Root-CAs, Firmware-Signaturen oder sämtliche anderen Zertifikatstypen übertragen werden.
Für IT-Betriebe steigt damit der Druck zur automatisierten Ausstellung und Erneuerung, etwa über ACME nach RFC 8555. Automation senkt das Risiko auslaufender Zertifikate; sie behebt jedoch nicht von selbst das Vertrauensproblem. Ein vollautomatisch erneuertes Zertifikat einer unerwünschten CA bleibt ein unerwünschtes Zertifikat. Und eine automatische Root-Store-Aktualisierung ist zwar häufig unverzichtbarer Bestandteil sicherer Plattformpflege, ersetzt aber nicht die Dokumentation und Bewertung der übernommenen Vertrauensänderungen. Wer dieses Problem durch pauschales Abschalten von Root-Updates lösen will, kann im Gegenteil wichtige Sperrentscheidungen und Sicherheitskorrekturen verpassen.
Von Certificate Management zu Trust Governance
Der erste Schritt ist eine technische Bestandsaufnahme, die über das übliche Certificate Lifecycle Management hinausgeht. Eine verantwortliche Stelle muss wissen, welche Zertifikate existieren, wo ihre privaten Schlüssel liegen, welche Identitäten sie repräsentieren, wer sie ausgestellt hat und von welchen Anwendungen sie akzeptiert werden. Dazu gehören öffentliche TLS-Endpunkte ebenso wie interne Server, mTLS-Clients, API-Gateways, Container, Orchestrierungsplattformen, Load Balancer, VPN-Zugänge, Entwicklungs- und Laborumgebungen, Gerätefirmware, Cloud-Zertifikatsdienste und spezielle Laufzeitumgebungen. Ohne Zuordnung zu einem technischen Eigentümer und einem konkreten Schutzbedarf wird aus einer Inventarliste noch keine wirksame Kontrolle.
Der zweite Schritt ist die getrennte Erfassung der Vertrauensanker. Für jeden relevanten Systemtyp sollten die effektiv verwendeten Root- und Intermediate-CAs einschließlich Fingerprints, Einsatzbereich, Verwendungszweck, Quelle der Installation und Änderungsweg nachvollziehbar sein. Wichtig ist der effektive Zustand: Was ein Basis-Image bei Auslieferung enthalten hat, muss nicht mit dem übereinstimmen, was eine Anwendung nach Richtlinien, Paketupdates oder lokalen Abweichungen tatsächlich verwendet. Eine definierte Baseline ermöglicht Differenzprüfungen. Neue Root-Zertifikate, veränderte Trust Policies und zusätzliche private CAs gehören in denselben kontrollierten Änderungsprozess wie neue privilegierte Identitäten oder Firewall-Vertrauenszonen.
Der dritte Schritt betrifft die Hoheit über Schlüssel und Zertifikatsausstellung. Wo eine interne PKI benötigt wird, sollten ausstellende Rollen klar abgegrenzt, Schlüsselmaterial dem Schutzbedarf angemessen gesichert und nicht benötigte Zertifikatszwecke technisch eingeschränkt werden. Private CAs dürfen keine universelle Abkürzung für jedes Integrationsproblem werden. Ein Lieferant, der die Installation einer zusätzlichen Root-CA verlangt, sollte Zweck, Geltungsbereich, Zertifikatsrichtlinien, Sperrprozess, Rotationsverfahren und gegebenenfalls den Zugriff auf private CA-Schlüssel darlegen. Ist der Schutzbedarf hoch, ist auch zu bewerten, ob die vertrauenswürdige Zertifikatskette an eine dedizierte Anwendung gebunden werden kann, statt dem ganzen Endgerät eine weitere allgemeine CA zu geben.
Viertens müssen die Fachbereiche für den Ernstfall übungsfähig sein. Ist eine CA kompromittiert oder muss ihr Vertrauen aus anderen Gründen entzogen werden, geht es nicht nur darum, ein einzelnes Zertifikat zu sperren. Zu klären sind die betroffenen Clients und Systeme, alternative Zertifikatsketten, mögliche Fehlbindungen an alte Trust Stores, das Risiko kompromittierter Schlüssel, Ausweichpfade und die Wiederanlauffähigkeit der Produktion. Die MITRE-Technik T1553.004 („Install Root Certificate“) unterstreicht, dass die unautorisierte Installation von Root-Zertifikaten ein bekannter Ansatz zur Unterwanderung von Vertrauenskontrollen ist. Die Überwachung entsprechender Änderungen gehört deshalb zur Endpoint- und Incident-Response-Strategie.
Schließlich braucht die Sicherheitsorganisation prüfbare Nachweise. Das sind nicht nur Screenshots aus einem Zertifikatsmanager, sondern reproduzierbare Aussagen: Welche Systeme wurden untersucht? Welche Stores wurden tatsächlich ausgelesen? Welche Segmente bleiben unerreichbar? Gibt es technische Ausnahmen? Welche CA kann für welche Identitäten Zertifikate ausstellen? Wie werden abweichende Fingerprints gemeldet, genehmigt oder blockiert? Und wie wird festgestellt, ob im Ernstfall die Sperre eines Vertrauensankers an allen betroffenen Standorten und in allen relevanten Anwendungen greift? Der Anspruch muss eine regelmäßig überprüfte Vertrauensarchitektur sein, nicht die Illusion einer einmalig „bereinigten“ Zertifikatslandschaft.
Was CIO, CISO und Sicherheitsbevollmächtigte entscheiden müssen
Für den CIO ist dies vor allem eine Frage von Architekturverantwortung und Lieferfähigkeit. Wer PKI als beiläufigen Betrieb einer Microsoft-CA oder eines Public-Certificate-Dashboards behandelt, übersieht die Identitäten in Cloud-, OT- und Produktumgebungen. Zentralität bedeutet dabei nicht zwingend eine einzige ausstellende CA. Zentral müssen vielmehr Richtlinien, Inventar, Verantwortlichkeiten und die Möglichkeit zur überprüfbaren Reaktion sein – auch über getrennte Sicherheitsdomänen hinweg.
Für den CISO steht die Zulässigkeit einer Vertrauensbeziehung im Vordergrund. Es genügt nicht, die kryptografischen Parameter einer TLS-Verbindung zu prüfen; auch die Berechtigung der ausstellenden Instanz und die Herkunft der Konfiguration gehören ins Bedrohungsmodell. Wo ein ausländischer Cloud-Anbieter, ein externer Wartungsdienst oder eine nationale Infrastruktur in die Vertrauenskette eingreift, muss zwischen rechtlich dokumentierter Betreiberkontrolle, technischer Zugriffsmöglichkeit und tatsächlichem Missbrauch unterschieden werden. Das ist anspruchsvoller als eine einfache Positiv- oder Negativliste von Ländern und Anbietern.
Für Sicherheitsbevollmächtigte (SiBe) im Geheimschutz und Informationssicherheitsbeauftragte in der unternehmensweiten Security Governance ergeben sich unterschiedliche, aber eng verbundene Prüfaufgaben: Existiert ein verbindlicher Prozess für zusätzliche Root-CAs und Intermediate-CAs? Werden Abweichungen in Lieferanten-Images und Anwendungspaketen erfasst? Ist dokumentiert, ob eine Komponente eine fremde Vertrauensbasis verlangt? Können relevante Nachweise im Audit erbracht werden? Und ist vor einer Freigabe erkennbar, ob die technische Lösung tatsächlich zur festgelegten Sicherheitsarchitektur passt? Ohne diese Antworten bleiben Schutzbehauptungen schwer prüfbar.
Fazit: Digitale Souveränität beginnt vor der Verschlüsselung
Shadow Certificates sind keine Randnotiz des IT-Betriebs. Sie offenbaren eine strukturelle Lücke zwischen der Verwaltung digitaler Zertifikate und der Herrschaft über digitale Vertrauensentscheidungen. In der Verteidigungsindustrie, wo Entwicklungswissen, industrielle Prozesse und staatliche Sicherheitsinteressen zusammentreffen, verdient diese Lücke besondere Aufmerksamkeit. Ein abgelaufenes Zertifikat verursacht möglicherweise einen Ausfall. Ein fremder, unkontrollierter Vertrauensanker kann die Glaubwürdigkeit einer ganzen Kommunikationsbeziehung infrage stellen.
Aus dokumentierten staatlichen TLS-Interception-Fällen folgt kein Generalverdacht gegen sämtliche staatlichen CAs. Wohl aber eine klare technische Konsequenz: Ein Unternehmen muss wissen und nachweisen können, welche Instanzen in seinen Systemen Identitäten beglaubigen dürfen – und wie es ihnen dieses Recht wieder entzieht. Wer das beherrscht, verwaltet nicht nur Zertifikate. Er schützt die Grundlagen digitaler Handlungsfähigkeit.
Fachliche Grundlagen und weiterführende Informationen
Auswahl überwiegend technischer Primärquellen. Die Links dokumentieren die jeweils genannten technischen Grundlagen oder historischen Vorgänge. Stand der redaktionellen Recherche: 22. Oktober 2026.
- NIST SP 1800-16: Securing Web Transactions – TLS Server Certificate Management.
- Mozilla Security Blog (2019): Protecting our Users in Kazakhstan.
- Google Online Security Blog (2019): Protecting Chrome users in Kazakhstan.
- Mozilla (2020): Continuing to Protect our Users in Kazakhstan.
- Google (2013): Further improving digital certificate security (ANSSI).
- Google (2014): Maintaining digital certificate security (India NIC).
- Chrome: Certificate Transparency for Enterprises.
- MITRE ATT&CK: T1553.004 – Install Root Certificate.
- CA/Browser Forum: Ballot SC-081v3 – Laufzeiten öffentlich vertrauenswürdiger TLS-Zertifikate.
- UK NCSC: Provisioning and managing certificates in the Web PKI.
- BSI: TR-02102-2 – Verwendung von Transport Layer Security.
- Mozilla Enterprise: Set up Certificate Authorities (CAs) in Firefox.
- IETF: RFC 9846 – TLS 1.3 und RFC 9162 – Certificate Transparency 2.0.
Weiterführend bei Artefaktum: Die vergessenen VS-NfD-Informationen – versteckte Kopien in Backups und IT-Systemen. Der Beitrag beleuchtet ein verwandtes Grundproblem: sicherheitsrelevante Bestände, die außerhalb der gewohnten Kontrollen fortbestehen.
Die dokumentierten Zertifikatsvorfälle werden im Artikel ausdrücklich von technisch möglichen Angriffsszenarien unterschieden. Die Beispiele sind keine Behauptung, bestimmte Rüstungsunternehmen seien kompromittiert.
