Am 17. Oktober 2026 wandte sich ein Sicherheitsforscher, der lediglich unter dem Pseudonym „Wayne“ bekannt ist, an die Root-Programm-Teams von Apple, Google, Microsoft und Mozilla. Die Nachricht war mit den privaten Schlüsseln von acht Intermediate-Zertifizierungsstellen (Intermediate-CAs) signiert, die von eMudhra – dem indischen Vertrauensdiensteanbieter hinter der Marke emSign – betrieben werden. Der Wortlaut der Nachricht: 

„Wir haben hier ein Problem – Wayne“ 

Dies erwies sich als erhebliche Untertreibung. Die privaten Schlüssel wurden weder durch einen Sicherheitsvorfall entwendet, noch wurde die Infrastruktur von eMudhra kompromittiert. Die Schlüssel waren schlichtweg schwach – generiert mit so unzureichender Entropie, dass sie jedermann anhand der öffentlichen Zertifikate in weniger als einer Sekunde berechnen konnte. Einer der acht Schlüssel entsprach laut unabhängigen Analysen schlicht dem Integer-Wert 4. 

Fünf Tage später gab eMudhra bekannt, sich vollständig aus dem weltweiten Markt für SSL/TLS-Zertifikate zurückzuziehen. 

Für CISOs und Sicherheitsarchitekten – insbesondere jene, die für Operational Technology (OT), SCADA- und Industrial-IoT-Umgebungen verantwortlich sind – erfordert dieser Vorfall weitaus mehr Aufmerksamkeit, als die Schlagzeilen vermuten lassen. Nachfolgend finden Sie das vollständige Lagebild, einschließlich der Entwicklungen der vergangenen 48 Stunden. 

Was tatsächlich geschah: Die Kurzfassung 

Zwischen April und Mai 2025 führte eMudhra eine Schlüsselzeremonie zur Generierung von 24 Sub-CA-Schlüsseln unterhalb der Hierarchie der „emSign Root TLS CA – G3“ durch. Während eines Wrap/Unwrap-Schritts auf dem Hardware-Sicherheitsmodul (HSM) führte ein Fehler im Script zur Schlüsselgenerierung zur Erstellung eines zweiten Satzes schwacher elliptischer Kurvenschlüssel (P-384). Infolge verwechselter Schlüsselbezeichnungen (Labels) und menschlichen Versagens wurden acht dieser kryptografisch unzureichenden Schlüssel für produktive Intermediate-CA-Zertifikate verwendet. 

Ordnungsgemäß erzeugte P-384-Schlüssel entstammen einem Wertebereich von rund 10¹¹⁵ Möglichkeiten. Die betroffenen Schlüssel wiesen jedoch lediglich eine effektive Entropie von 3 bis 8 Bit auf. Deren Wiederherstellung war keine kryptanalytische Meisterleistung – es handelte sich um einfache Arithmetik. 

Die acht kompromittierten Intermediate-CAs: 

Das kritische Detail, das in der Berichterstattung meist übersehen wird: Jede Intermediate-CA existiert zusätzlich als zweites Zertifikat, das von Sectigos Legacy-Root „AAA Certificate Services“ quellübergreifend signiert (Cross-Signing) wurde. Das Entfernen der eMudhra-eigenen Root-Zertifikate aus Ihrem Trust Store reicht folglich nicht aus – jedes System, das der Sectigo-Root weiterhin vertraut, stuft auch die quer-signierten Instanzen als valide ein. 

Zeitlicher Ablauf: 17 Monate Exposition, 100 Minuten bis zur Schadensminderung 

Die schwachen Schlüssel wurden am 30. April 2025 generiert und waren über einen Zeitraum von rund 17 Monaten öffentlich rekonstruierbar, bevor der Zustand bemerkt wurde. Die Maßnahmen nach der Entdeckung markieren jedoch eine der schnellsten koordinierten Reaktionen in der Geschichte der Public-Key-Infrastrukturen: 

• 30. April 2025 – Eine fehlerhafte Schlüsselzeremonie generiert die acht Intermediates. 

• 14. Mai 2025 – Sectigo signiert die Intermediates quer unter der CA „AAA Certificate Services“. 

• 23. Mai 2025 – Erste Nachweise ungültiger CRL-Signaturen derselben Intermediates treten auf – ein Warnsignal, das seinerzeit fehldiagnostiziert wurde. 

• 17. Oktober 2026, 18:05 Uhr UTC – Das Chrome Root Program erhält den Bericht von „Wayne“. 

• 17. Oktober 2026, 19:45 Uhr UTC – Chrome rollt ein CRLSet-Update aus, welches die kompromittierten Schlüssel anhand ihres SPKI-Hashwerts sperrt. Firefox folgt um 22:59 Uhr UTC. Gesamte Reaktionszeit: unter zwei Stunden. 

• 18. Oktober 2026 – eMudhra widerruft alle acht Intermediates. 

• 19. Oktober 2026 – Apple blockiert die Zertifikate; Sectigo widerruft die quer-signierten Kopien; Sicherheitsmaßnahmen für Android werden über Google Play Services verteilt. 

• 20. Oktober 2026 – Microsoft blockiert die Zertifikate; Mozilla entzieht emSign ECC Root CA – G3 vollständig das Vertrauen; Patches für Go, Firefox und Python werden bereitgestellt. 

• 22. Oktober 2026 – eMudhra kündigt den Rückzug aus dem globalen SSL/TLS-Zertifikatsgeschäft an. Chairman V. Srinivasan bestätigt, dass der Widerruf innerhalb von 14 Stunden nach Bekanntwerden erfolgte, keine End-Entity-Zertifikate von den betroffenen Intermediates ausgestellt wurden und kein Datendiebstahl vorlag. 

• 27. Oktober 2026 – Der Vertrauensentzug für emSign ECC Root CA – G3 in Chrome erreicht alle Endgeräte. Betreiber von Webdiensten, deren Zertifikatskette noch auf diese Root zurückgeht, müssen unverzüglich auf ein neues Zertifikat migrieren, um Dienstunterbrechungen zu vermeiden. 

Wurden die Schwachstellen aktiv ausgenutzt? 

Mit Stand vom 27. Oktober 2026 gibt es keine Bestätigung für einen böswilligen Missbrauch. Google berichtet, dass kein TLS-Zertifikat, das auf die betroffenen Intermediates zurückgeht, in Certificate Transparency (CT) protokolliert wurde. Dies schließt Angriffe gegen Clients mit zwingender CT-Prüfung weitgehend aus. 

Für Ihr Risikomanagement sind jedoch zwei Aspekte essenziell: 

1. Die Schlüssel waren 17 Monate lang für jeden Beobachter rekonstruierbar. Es existieren naturgemäß keine technischen Protokolle darüber, wer dies getan hat. 

2. Code-Signing-Zertifikate unterliegen keinem CT-Logging. Die beiden Schlüssel der EM OV CS CA hätten theoretisch genutzt werden können, um Binärdateien zu signieren, die auf Windows-Systemen ohne strikte Zertifikatsprüfung (Revocation Checks) als verifizierte Herausgeber eingestuft worden wären. Ob und welche Dateien signiert wurden, ist öffentlich nicht nachvollziehbar. 

Aus Sicht der Informationssicherheit sind alle acht Schlüssel als kompromittiert einzustufen. 

Warum sich dieser Vorfall von DigiNotar und Symantec unterscheidet 

Integritätsverluste bei CAs sind kein Novum – DigiNotar (2011) und Symantec (2017) endeten vergleichbar. Der Vorfall bei eMudhra basiert jedoch auf einem grundlegend anderen Fehlerszenario: 

• DigiNotar resultierte aus einem Netzwercheinbruch – Angreifer entwendeten Schlüssel aus der kompromittierten Infrastruktur. 

• Symantec scheiterte an Mängeln der operativen Governance – fehlerhaft ausgestellte Zertifikate wurden über CT-Logs identifiziert. 

• eMudhra stellt ein Versagen der Schlüsselzeremonie dar – das kryptografische Fundament war bereits zum Zeitpunkt der Erzeugung fehlerhaft, und zwar innerhalb des Prozesses, der der strengsten Kontrolle einer CA unterliegen muss. 

Diese Differenzierung ist entscheidend: Schlüsselzeremonien bilden den Vertrauensanker jeder Unternehmens-PKI, jedes HSM-gestützten Code-Signings und zunehmend jeder digitalen Identität im industriellen Umfeld. Generiert eine solche Zeremonie unbemerkt den Schlüsselwert „4“, verlieren alle darauf aufbauenden Sicherheitsannahmen ihre Gültigkeit. 

Die unterschätzte Dimension: Konsequenzen für industrielle PKI und OT 

Hieraus ergeben sich unmittelbare Handlungsbedarfe für Betreiber Kritischer Infrastrukturen (KRITIS). 

1. Ihre Webbrowser sind gepatcht. Ihre OT-Systeme höchstwahrscheinlich nicht. 

Nutzer von Chrome und Firefox waren binnen Stunden geschützt. Dieses Schutzkonzept basiert jedoch auf der automatisierten Verteilung von Sperrinformationen (CRLSet, OneCRL, CRLite) an kontinuierlich aktualisierte Clients. 

Betrachten Sie im Vergleich Ihre OT-Landschaft: 

• SCADA-Historians und HMI-Stationen auf Windows-Basis, deren Root Stores seit Jahren nicht aktualisiert wurden 

• RTUs, PLCs und Fernwirkeinheiten mit fest integrierten, über ein Jahrzehnt alten CA-Zertifikatsbündeln 

• Industrielle VPN-Gateways und Mobilfunk-/Funk-basierte Fernzugriffskomponenten, die Zertifikate anhand statischer Firmware-Trust-Stores validieren 

• Docker-Container, Build-Pipelines und Python-Automatisierungsskripte mit monatealten Certifi-Paketen 

• Embedded-Linux-Geräte in Umspannwerken und Pipeline-Stationen, die systembedingt keine Trust-Store-Updates erhalten 

Im Sicherheitshinweis von Fortinet werden Embedded- und IoT-Geräte, Legacy-Systeme, virtuelle Maschinen, Container sowie Laufzeitumgebungen mit eigenständigen SSL-Trust-Stores (wie Python) explizit als Hochrisikobereiche ausgewiesen. 

Red Hat bestätigte, dass sämtliche unterstützten RHEL-Versionen (6 bis 10) die kompromittierte Zertifikatskette im Paket „ca-certificates“ führten. RHEL-basierte TLS-Verbindungen vertrauen betrügerisch ausgestellten Zertifikaten potenziell so lange, bis dieses Paket aktualisiert wird. 

2. Das Man-in-the-Middle-Risiko in der OT ist strukturell real. 

In IT-Netzen setzt ein Man-in-the-Middle-Angriff voraus, Zugriff auf den Übertragungsweg zu erlangen. In der OT ist die Netzwerkinfrastruktur häufig die Schwachstelle, die Angreifern entgegenkommt: 

• Flache oder unzureichend segmentierte Netzwerke in Bestandsanlagen 

• Fernwartungstunnel von Drittanbietern, die auf Jump-Hosts terminieren und den systemweiten CA-Stores vertrauen 

• Out-of-Band-Managementschnittstellen an Altsystemen 

• Protokoll-Gateways und -Konverter, die TLS aufbrechen, terminieren und nachgelagert erneut verschlüsseln 

Ein Angreifer, der über den Schlüssel einer kompromittierten Intermediate-CA verfügt und Zugriff auf ein flaches OT-Netzwerk hat, könnte sich gegenüber einem Historian als Engineering-Station oder gegenüber einem HMI als Historian ausgeben. Datenverkehr – einschließlich Steuerungsbefehlen – ließe sich so abfangen oder manipulieren. Wo TLS zur Absicherung von Engineering-Sitzungen dient, stellt dies eine unmittelbare Gefährdung dar. 

3. Code-Signing betrifft Ihre Supply-Chain direkt. 

Die beiden betroffenen Code-Signing-Intermediates (EM OV CS CA – G3B/G3C) verweisen auf die emSign Root CS CA – G3, welcher Microsoft vertraut. Laut eMudhra erreichten diese CAs nie den Produktivbetrieb. Sofern in Ihrer Organisation signierte Firmware, herstellerspezifische Utilities oder SCADA-Patches auf Windows-Systemen ohne aktuelle Sperrprüfung validiert werden, verdeutlicht dieser Vorfall: Eine Vertrauensentscheidung ist stets nur so belastbar wie die schwächste CA in Ihrem Vertrauensspeicher – und die CA-Auswahl der Hersteller liegt außerhalb Ihres Einflusses. 

4. Das Warnsignal von 2025: Mangelnde Sensibilität bei Anomalien. 

Bereits im Juni 2025 registrierte Mozilla ungültige CRL-Signaturen exakt dieser sechs TLS-Intermediates. eMudhra führte dies auf einen manuellen Bedienfehler zurück, bei dem ein falscher Schlüssel referenziert worden sei, stellte korrigierte Zertifikatsperrlisten bereit und das Ticket wurde geschlossen. 

Dies war dieselbe Ursache, 16 Monate vor der Eskalation sichtbar und fehldiagnostiziert. Für Sicherheitsverantwortliche in der OT lautet die Konsequenz: Überwachen Sie die Integrität der CAs in Ihren Zertifikatsabhängigkeiten mit der gleichen Sorgfalt wie CVEs in Ihren Softwarekomponenten. Weist eine CA fehlerhafte CRLs auf, ist deren gesamte Schlüsselzeremonie zwingend zu hinterfragen. 

Maßnahmenkatalog für OT- und KRITIS-Verantwortliche 

Sofortmaßnahmen (laufende Woche): 

1. Inventarisierung aller Systeme in Ihrer OT-Umgebung, die TLS-Zertifikate oder Signaturen validieren – einschließlich Sicherheits-Appliances, Gateways, HSMs, Container-Images und Embedded Devices. Gehen Sie davon aus, dass Standard-Browser bereinigt sind; alle industriellen Komponenten unterliegen Ihrer manuellen Prüfpflicht. 

2. Aktualisierung von Trust Stores über das Betriebssystem hinaus: Sprachlaufzeiten (certifi, Gos crypto/x509 – behoben in Go 1.26.10 und 1.27.3 unter CVE-2026-111943), JVM-Trust-Stores, Firmware von Industrie-Appliances und herstellereigene Zertifikatslisten. 

3. Prüfung auf Quersignierungen durch Sectigo. Durchsuchen Sie Trust Stores nach der veralteten Stammzertifizierungsstelle „AAA Certificate Services“ – FortiOS-Administratoren sollten ihre CA-Listen gezielt nach „AAA“ filtern, um manuell importierte Zertifikate zu identifizieren. 

4. Prüfung auf emSign-Zertifikate im Anlagenbestand. Da Google Chrome emSign ECC Root CA – G3 zum 27. Oktober 2026 vollständig blockiert, führen bestehende Zertifikatsketten zu dieser Root ab dieser Woche unweigerlich zu Systemausfällen. 

Kurzfristige Maßnahmen (30 Tage): 

1. Auditierung von Certificate-Pinning und Zertifikatsprüfung in OT-Anwendungen. Systeme ohne Implementierung von Sperrprüfungen oder CT-Validierung stellen das primäre Risiko dar. 

2. Überprüfung von Fernwartungszugängen. Stellen Sie sicher, dass Jump-Hosts, VPN-Gateways und TLS-Terminierungs-Proxies mit aktuellen Trust-Stores betrieben werden und keine veralteten CA-Listen auf Firmware-Basis nutzen. 

3. Sperrung beider Root-Zertifikate (Blocklisting) im Sinne des Defense-in-Depth-Prinzips: emSign Root TLS CA – G3 sowie Sectigos AAA Certificate Services (gemäß Red Hat-Empfehlung). 

Strategische Maßnahmen: 

1. Konsolidierung von Vertrauensankern. Jede vertrauenswürdige Root vergrößert die Angriffsfläche. Reduzieren Sie Zertifikatsausstellungen auf CAs mit nachgewiesener betrieblicher Exzellenz und fordern Sie von Lieferanten Transparenz über genutzte CAs ein. 

2. Integration von CA-Monitoring in die Threat Intelligence. CRL-Anomalien, unerwartete Cross-Signings und Beschlüsse der Root-Programme (Common CA Database, mozilla.dev.security.policy) dienen als verlässliche Frühwarnindikatoren. 

3. Auditierung interner Schlüsselzeremonien. Sofern Ihre Organisation eine interne PKI betreibt – im OT-Sektor für Geräteidentitäten und Engineering-Zugriffe der Regelfall –, überprüfen Sie HSM-Skripte, Schlüsselbezeichnungen und das Vier-Augen-Prinzip (Dual Control). Das eMudhra-Debakel entstand durch ein fehlerhaftes Skript, menschliches Versagen und ignorierte Warnzeichen – ein Fehlermuster, das auch in Enterprise-PKI-Umgebungen nicht unüblich ist. 

Fazit 

Der Fall eMudhra wird weniger wegen seines operativen Schadens in Erinnerung bleiben – dieser blieb dank der schnellen Intervention von Chrome und Mozilla gering –, sondern wegen der offengelegten strukturellen Defizite. Eine Zertifizierungsstelle mit über 60 Millionen ausgestellten Zertifikaten, der alle führenden Root-Programme vertrauten, generierte Signaturschlüssel ohne kryptografische Entropie, beließ sie 17 Monate unerkannt im Feld, ignorierte eigene Fehlermeldungen und musste ihren Betrieb innerhalb von fünf Tagen nach Offenlegung einstellen. 

Für Betreiber von Industrieanlagen gilt die ernüchternde Erkenntnis: Zertifikatsperrungen in Browser-Geschwindigkeit existieren in der OT nicht. Ihr Schutzniveau hängt vollständig davon ab, ob Historians, Gateways, Embedded-Systeme und Fernwartungspfade über aktualisierte Vertrauensspeicher verfügen – und in den meisten Anlagen wurde dies bislang nicht überprüft. 

In der OT-Sicherheit investieren wir beträchtliche Ressourcen in Systemhärtung und Netzwerksegmentierung. Dieser Sicherheitsvorfall mahnt an, dass die zugrunde liegende Vertrauenskette – Zertifikate, CAs und Schlüsselzeremonien – dieselbe Sorgfalt verlangt. Ist das Fundament fehlerhaft, verliert die Stärke der Schutzmauern ihre Wirkung. 

Shieldworkz ist ein spezialisierter IT/OT-Sicherheitsdienstleister für SCADA-, OT- und IoT-Umgebungen in Kritischen Infrastrukturen. Wenn Sie analysieren möchten, ob Ihre OT-Infrastruktur kompromittierten Zertifikatsketten vertraut – einschließlich quer-signierter Altzertifikate unter Sectigo-Roots –, [kontaktieren Sie unser Team] für ein PKI- und Zertifikats-Sicherheitsaudit.