Acht CA-Schlüssel von eMudhra wurden kompromittiert. Das bedeutet es für Sie

Acht Zwischen-CAs von eMudhra wurden mit privaten Schlüsseln erstellt, die jeder aus dem öffentlichen Zertifikat wiederherstellen kann. Browser haben sie wenige Stunden nach der Meldung vom 17. Oktober blockiert, und die Zertifikate sind inzwischen widerrufen. Wir haben jedes Inventar in Red Sift Certificates und Hardenize geprüft und die betroffenen Konten kontaktiert: Konten mit Zertifikaten unter den acht CAs und Konten mit Zertifikaten unter der emSign ECC Root CA - G3, die Firefox und Chrome gerade entfernen. Wenn Sie irgendetwas betreiben, das TLS ohne vorgeschalteten Browser spricht, aktualisieren Sie Ihre Trust Stores.

eMudhra, die indische CA hinter der Marke emSign, hat am 30. April 2025 acht neue Zwischen-CAs eingerichtet: sechs für TLS-Zertifikate und zwei für Code Signing. Einen Monat später hat Sectigo alle acht unter seinem Root AAA Certificate Services cross-signiert. Jeder Schlüssel steckt also in zwei Zertifikaten mit demselben Subject Key Identifier.

Niemand musste diese Schlüssel stehlen. Jeder ist ein P-384-Schlüssel auf Basis elliptischer Kurven, dessen geheimer Wert kleiner als 256 ist, und bei einem davon ist er die Zahl 4. Mit dem Zertifikat in der Hand lässt sich der private Schlüssel auf einem Laptop in deutlich weniger als einer Sekunde wiederherstellen, indem man jeden Wert der Reihe nach ausprobiert. eMudhra hat die eigentliche Ursache noch nicht bestätigt. Laut der vorläufigen Erklärung hat ein Fehler im Skript der Key Ceremony neben dem starken ein zweites, schwaches Schlüsselpaar erzeugt, und das schwache Paar landete in den Zertifikatsanträgen, weil sich die Bezeichnungen ähnelten.

Ein Forscher hat das Problem am 17. Oktober 2026 den Root-Programmen der Browser gemeldet, mit einer von allen acht Schlüsseln signierten Nachricht als Beweis. Dies sind die betroffenen Zwischen-CAs. Jeder Hash verlinkt auf seinen Eintrag bei crt.sh.

• 17. Oktober. Ein Forscher hat die Schlüssel den Root-Programmen der Browser gemeldet. Innerhalb weniger Stunden haben Chrome und Firefox Updates verteilt, die jeden installierten Browser anweisen, sie abzulehnen, ohne neue Browserversion oder Neustart.
• 18. und 19. Oktober. Erst eMudhra, dann Sectigo haben die Zertifikate widerrufen. Apple hat dieselbe Sperre auf iOS und macOS ausgerollt.
• 20. Oktober. Windows folgte. Mozilla hat die Details veröffentlicht und die emSign ECC Root CA - G3 aus Firefox entfernt; Chrome hat angekündigt, nachzuziehen. Mozilla behält den RSA-Root emSign Root CA - G1, den Chrome noch prüft.

Die gute Nachricht: Vor der Sperre wurde nichts unter diesen CAs ausgestellt. Google hat bestätigt, dass nie ein Zertifikat mit einer Kette zu diesen CAs in Certificate Transparency protokolliert wurde, und eMudhra gibt an, überhaupt keine Kundenzertifikate ausgestellt zu haben.

Chrome, Safari, Firefox und Edge auf dem Desktop lehnen TLS-Zertifikate ohne CT-Nachweis ab, eine Fälschung hätte also keiner von ihnen akzeptiert. Dieser Schutz gilt aber nicht überall. Mozilla arbeitet noch an einem Problem mit Firefox für Android 158.0.1, und Clients, die CT nicht durchsetzen, profitieren überhaupt nicht davon. Seit der Offenlegung haben Forscher mehr als 100.000 Demonstrationszertifikate unter diesen Schlüsseln protokolliert, darunter Fälschungen für google.com. So wenig Aufwand ist dafür nötig.

• Sie haben ein Zertifikat von einer der acht CAs. Die ausstellende Zwischen-CA ist widerrufen, die Kette ist also nicht mehr vertrauenswürdig, und Browser lehnen sie ab. Ersetzen Sie das Zertifikat. Laut eMudhra ist diese Gruppe leer; prüfen Sie Ihr Inventar, statt sich darauf zu verlassen.
• Sie haben ein Zertifikat mit einer Kette zur emSign ECC Root CA - G3. Es ist nicht kompromittiert, aber Firefox vertraut diesem Root nicht mehr, und Chrome folgt bald. Nach der ersten Schätzung von eMudhra müssen rund 30.000 Zertifikate auf den RSA-Root emSign Root CA - G1 umziehen, den Mozilla behält. Lassen Sie Ihr Zertifikat neu ausstellen, bevor die Änderung in Chrome Ihre Nutzer erreicht.
• Ihre Software verbindet sich per TLS mit anderen Servern. Das betrifft alle. curl, Python, Node.js, Go, Java, CI-Runner, API-Clients, Mutual TLS und Embedded-Geräte vertrauen einem Zertifikats-Bundle auf der Festplatte und prüfen meist weder Widerruf noch CT. Ein Forscher hat ein Zertifikat für eine bekannte Zahlungs-API gefälscht, und curl, Python und Node.js haben es alle mit Standardeinstellungen akzeptiert. Solange Ihre Bundles nicht aktualisiert sind, tun Ihre Clients das auch.
• Sie prüfen signierte Windows-Software. Code-Signing-Zertifikate werden nicht in CT protokolliert, daher kann niemand auflisten, was unter den beiden Code-Signing-CAs signiert wurde. Laut eMudhra war es nichts, aber die Schlüssel sind seit dem 30. April 2025 schwach, ein Zeitstempel beweist also nichts. Behandeln Sie alles, was darunter signiert wurde, als nicht vertrauenswürdig.

Am 21. Oktober haben wir jedes Inventar in Red Sift Certificates und Hardenize nach Zertifikaten unter den acht Schlüsseln durchsucht und dabei den Schlüsselbezeichner des Ausstellers und die Ketten-Hashes aller sechzehn Zertifikate abgeglichen. Wir haben eine Handvoll gefunden, keines auf einem Live-Dienst, alle nach der Offenlegung von Forschern protokolliert, die die wiederhergestellten Schlüssel testeten. Außerdem haben wir nach Zertifikaten unter dem ECC-G3-Root gesucht. Wir haben jedes Konto aus beiden Gruppen kontaktiert.

Sie können das selbst prüfen. Das Certificate-Authorities-Widget in Ihrem Dashboard (siehe unten) listet die CAs hinter Ihren Zertifikaten auf. Wenn eMudhra auftaucht, öffnen Sie diese Zertifikate, vergleichen Sie den SHA-256 der ausstellenden CA mit der Tabelle oben und prüfen Sie, in welchem Root die Kette endet. Kompromittiert sind nur Zertifikate unter den acht Zwischen-CAs. Zertifikate unter dem ECC-G3-Root sind es nicht; sie müssen aber neu ausgestellt werden. InCommon-Zertifikate, die seit April 2026 ausgestellt wurden, erscheinen ebenfalls als eMudhra, weil ihre Zwischen-CAs unter dem G1-Root von eMudhra ausgestellt sind; für sie ist nichts zu tun.

• Aktualisieren Sie Trust Stores überall. Aktualisieren Sie die CA-Pakete des Betriebssystems, Python certifi, Node.js, Java cacerts, Homebrew und mitgelieferte Trust Stores. Bauen Sie Go-Binaries mit einer gepatchten Toolchain und Container mit aktualisierten Basis-Images und Abhängigkeiten neu, und deployen Sie sie dann erneut.
• Blockieren Sie die kompromittierten CAs. Prüfen Sie mTLS, VPNs, API-Gateways und Zertifikats-Pins. Lehnen Sie die betroffenen Schlüssel sowohl über die eMudhra-Ketten als auch über die von Sectigo cross-signierten Ketten ab; eine zwischengespeicherte Zwischen-CA zu löschen, reicht allein nicht aus.
• Lassen Sie Zertifikate mit einer Kette zur emSign ECC Root CA - G3 neu ausstellen. Ersetzen Sie sie durch Zertifikate mit einer Kette zu einem vertrauenswürdigen Root, bevor die Änderung in Chrome Ihre Nutzer erreicht.
• Lassen Sie die Prüfung aktiviert. Gehen Sie Zertifikatsfehlern nach Updates nach, statt die Prüfungen abzuschalten.
• Testen Sie den echten Pfad. Stellen Sie sicher, dass die tatsächliche Anwendung kompromittierte Ketten ablehnt. Ein Test im Browser oder mit curl auf dem Laptop beweist nicht, dass ein Produktivdienst geschützt ist.
• Erfassen Sie Geräte, die Sie nicht aktualisieren können. Schränken Sie ihren Netzwerkzugang ein. Setzen Sie, wo möglich, ein aktuelles Gateway ein, das TLS terminiert und Upstream-Zertifikate validiert. Eine Firewall allein reicht nicht aus.

Red Sift Certificates führt ein Live-Inventar aller Zertifikate in Ihrer Umgebung, einschließlich der Kette, die jeder Server tatsächlich sendet. So wird ein CA-Vorfall zu einer Suche statt zu einem Wettlauf. Das Certificate-Authorities-Widget zeigt, von welchen CAs Sie abhängen, und das Certificate-Transparency-Monitoring meldet Ihnen, wenn ein neues Zertifikat für Ihre Domains ausgestellt wird und von wem.

Wenn Sie noch kein Kunde von Red Sift Certificates sind und wissen möchten, ob ein Zertifikat Ihrer Domains eine Kette zu diesen CAs hat, fordern Sie eine kostenlose Demo an.

• eMudhra Intermediate CA Compromise: Offenlegungsseite und Testseite
• Mozilla Security Blog: Protecting Firefox users following the compromise of eMudhra intermediate certificates
• Mozilla dev-security-policy: Compromised eMudhra Intermediate Certificates (mit der Stellungnahme des Chrome Root Program)
• Bugzilla 2083449: Private key compromise of eMudhra Intermediate Certificates
• Cloudflare: 8 eMudhra certificates are compromised. Here's what you need to know
• Scott Helme: Eight bits of trust, eMudhra's CA keys cracked in milliseconds