eMudhra-Vorfall: Acht CA-Schlüssel waren trivial erratbar – was TLS-Zertifikatsinhaber jetzt prüfen müssen

6. November 2026  |  Zertifikate  |  IT-Sicherheit

Im Oktober 2026 wurde bekannt, dass die indische Zertifizierungsstelle eMudhra acht Zwischenzertifikate (Intermediate CAs) mit praktisch wertlosen privaten Schlüsseln ausgestellt hatte. Die privaten Schlüssel waren ganze Zahlen kleiner als 256, einer davon war buchstäblich die Zahl 4. Wer so einen Schlüssel kennt, kann im Namen der Zertifizierungsstelle Zertifikate für beliebige Domains unterschreiben. Browser-Hersteller haben deshalb binnen Stunden reagiert, die Zwischenzertifikate gesperrt und die zugehörige Root-CA emSign ECC Root CA – G3 aus ihren Vertrauenslisten entfernt.

Dieser Beitrag erklärt was genau passiert ist, warum ein Schlüssel „4“ ein Totalschaden ist, wer betroffen ist – und wer nicht – und was Betreiber von Webseiten, Mailservern und Firewalls jetzt prüfen sollten. Wir halten uns dabei streng an das, was die Primärquellen belegen. In der ersten Berichterstattung und in sozialen Netzwerken kursieren auch Darstellungen, die so nicht stimmen. Dazu gleich mehr.

Kurzfassung: Was stimmt, was nicht

Der zeitliche Ablauf

• 17. Oktober 2026: Der Vorfall wird an Mozilla gemeldet (Eingang 18:05 UTC laut Bugzilla). Bereits um 22:59 UTC ist die Sperre der Zwischenzertifikate über Mozillas OneCRL verteilt, also in weniger als drei Stunden nach Eingang der Meldung bei Mozilla.
• 18. Oktober 2026: eMudhra widerruft die acht Zwischenzertifikate.
• 19. Oktober 2026: Sectigo widerruft die Cross-Zertifikate, mit denen es die acht Zwischen-CAs gegengezeichnet hatte.
• 20. Oktober 2026: Mozilla veröffentlicht Firefox 158.0.1, ESR 115.43.1 und ESR 153.5.1 sowie NSS 3.131.1. Damit wird die Root emSign ECC Root CA – G3 entfernt. Zwischen dem 20. und 21. Oktober tauchen in den Certificate-Transparency-Logs zudem 107.107 Zertifikate auf, die mit sechs der acht schwachen Schlüssel signiert wurden (siehe unten).
• 22. Oktober 2026: eMudhra kündigt an, sich aus dem Geschäft mit öffentlichen TLS-Zertifikaten zurückzuziehen. Code-Signing und S/MIME laufen unter eigenen Roots weiter.
• 27. Oktober 2026: Chrome entfernt die Root-CA ebenfalls.
• 16. und 30. November 2026: Fristen für die älteren G1-Zertifikate (Chrome/Mozilla bzw. Apple), laut eMudhra relevant für den Übergang des betroffenen US-Kundenverbunds.

Warum ein privater Schlüssel „4“ ein Totalschaden ist

Eine Zertifizierungsstelle (CA) bestätigt mit ihrer digitalen Signatur, dass ein Zertifikat zu einer Domain gehört. Browser vertrauen dieser Signatur, solange die CA in ihrer Vertrauensliste steht. Die Sicherheit beruht darauf, dass nur die CA den privaten Schlüssel kennt.

Bei Zertifikaten mit elliptischen Kurven (ECDSA) ist der private Schlüssel eine sehr große Zahl d. Der öffentliche Schlüssel ist ein Punkt Q = d · G auf der Kurve (G ist der festgelegte Basispunkt). Aus Q die Zahl d zurückzurechnen, ist bei einer zufällig gewählten, 384 Bit langen Zahl praktisch unmöglich. Ist d aber klein, etwa 4, dann reicht es, nacheinander 1·G, 2·G, 3·G, 4·G … zu berechnen und mit dem öffentlichen Punkt zu vergleichen. Das dauert Sekunden und braucht keinerlei Spezialwissen.

Der öffentliche Schlüssel steht in jedem Zertifikat, also für jeden einsehbar. Damit kann jeder, der das nachrechnet, gültig aussehende Zertifikate im Namen der CA erzeugen – für beliebige Domains, solange ein Browser der CA noch vertraut. Genau deshalb haben Mozilla und andere sofort gesperrt.

Wir haben die acht in Bugzilla genannten Zwischenzertifikate über die öffentlichen Transparenz-Logs (crt.sh) per SHA-256-Fingerabdruck geladen und für jedes k · G für k = 1 bis 1000 mit dem öffentlichen Punkt verglichen. Alle acht Zertifikate haben einen P-384-Schlüssel und alle acht lieferten einen Treffer:

Die Werte decken sich mit den Angaben in Bugzilla und in der Berichterstattung (u. a. The Register: einer der Schlüssel sei „literally 4“). Wir haben mit diesen Werten nichts signiert und nichts ausgestellt; die Rechnung ist ausschließlich eine Prüfung öffentlicher Zertifikate.

Die Ursache laut eMudhra

Nach der Darstellung von eMudhra in Bugzilla entstanden die schwachen Schlüssel bei einer Schlüsselzeremonie am 30. April 2025. Dort wurde im Rahmen einer genehmigten Abweichung vom üblichen Ablauf ein Wrap/Unwrap-Test durchgeführt. Ein Fehler im Code habe dazu geführt, dass ein zweites Schlüsselpaar mit schwachen Schlüsseln im Gerät erzeugt wurde. Dieses sei dann versehentlich zur Erstellung der Zertifikatsanforderung verwendet worden, weil die Schlüsselbezeichnungen ähnlich waren. Die Zertifikate wurden daraufhin ausgestellt, in Vertrauenslisten aufgenommen und lagen dort über ein Jahr, bis der Fehler öffentlich auffiel.

Laut The Register hat der Sicherheitsforscher Scott Helme den Schlüssel „4“ entdeckt. Mit welcher Methode der Fehler aufgefallen ist, beschreiben die von uns geprüften Primärquellen nicht; die Prüfung auf kleine Schlüsselwerte ist jedoch anhand öffentlicher Zertifikate für jeden möglich.

Wer ist betroffen – und wer nicht?

Die Kette besteht aus drei Ebenen: Root-CA, Zwischen-CA und das Endzertifikat der Webseite oder des Servers. Betroffen war die mittlere Ebene. Daraus folgt:

• Die Schlüssel der Zertifikatsinhaber (Ihr Server-Schlüssel) sind nach allen uns vorliegenden Quellen nicht betroffen. Sie müssen nicht deshalb getauscht werden, weil sie „bekannt“ wären.
• Zertifikate, die unter der entfernten Root laufen, werden von Browsern nicht mehr akzeptiert. Sie müssen ersetzt werden, weil die Vertrauenskette weg ist, nicht weil der Server-Schlüssel schwach ist. Laut der Analyse des Chrome-Root-Programms (Stand 21.10.2026) betrifft das rund 30.800 noch gültige Zertifikate. 30.791 davon wurden von Unter-CAs von Internet2/InCommon ausgestellt, einem US-Verbund, der vor allem Hochschulen und Forschungseinrichtungen bedient. eMudhra spricht von einem einzigen Kundenverbund in den USA.
• Alle anderen eMudhra-Kunden sind laut eMudhra nicht betroffen. Digitale Signaturen, eSign, emSigner, CertiNext, SecurePass, PrivaTrust und emCA laufen auf getrennter Infrastruktur weiter.

Für Kunden in Deutschland, Österreich und der Schweiz ist die Wahrscheinlichkeit, ein Zertifikat unter dieser Root zu betreiben, daher gering. Sicher wissen Sie es nur, wenn Sie nachsehen. Das ist in wenigen Minuten erledigt, siehe Checkliste.

Die 107.107 Zertifikate in den Transparenz-Logs

Nach dem Widerruf tauchten laut Bugzilla zwischen dem 20. und 21. Oktober 2026 107.107 Zertifikate in den Certificate-Transparency-Logs auf, die mit sechs der acht schwachen Schlüssel signiert wurden. Darunter sind nachweislich Proof-of-Concept-Zertifikate, etwa mit google.com als Namen. Die meisten davon laufen über die inzwischen widerrufenen Cross-Zertifikate von Sectigo.

Das zeigt zweierlei: Erstens war der Fehler für jeden mit Grundkenntnissen in Kryptografie sofort ausnutzbar, zweitens zeigt es den Wert der Transparenz-Logs, in denen solche Ausstellungen für jeden sichtbar werden. Ob davon etwas außerhalb von Tests missbräuchlich genutzt wurde, geht aus den uns vorliegenden Quellen nicht hervor, und wir behaupten es nicht.

Was Browser-Hersteller und CAs unternommen haben

Mozilla geht nach eigener Aussage in der Diskussion auf dev-security-policy nicht davon aus, dass andere Zertifizierungsstellen betroffen sind.

Checkliste: Was Sie jetzt prüfen sollten

1. Aussteller Ihrer Zertifikate feststellen. Auf einem beliebigen Rechner mit OpenSSL:

   openssl s_client -connect ihre-domain.example:443 -servername ihre-domain.example </dev/null 2>/dev/null | openssl x509 -noout -issuer -dates

   Steht beim Aussteller eMudhra oder emSign (z. B. „EM DV TLS CA – G3B“ oder „G3C“), prüfen Sie mit -showcerts die gesamte Kette und die Root. Läuft sie über emSign ECC Root CA – G3, ist ein Austausch nötig.
2. Alle Dienste durchgehen, nicht nur die Webseite. Mailserver (SMTPS, IMAPS), VPN-Gateways, Firewall-Oberflächen, Load Balancer, interne Dienste, Geräte und Appliances mit eigenen Zertifikaten.
3. Öffentliche Zertifikate zu Ihrer Domain ansehen. Über crt.sh (Suche nach %.ihre-domain.example) sehen Sie alle für Ihre Domain ausgestellten Zertifikate, auch solche, von denen Sie nichts wissen. Das ist eine gute Gelegenheit, ungewollte Ausstellungen zu entdecken.
4. Betroffene Zertifikate ersetzen. Bei einer anderen, etablierten CA oder per ACME (z. B. Let’s Encrypt). Den Server-Schlüssel beim Austausch gleich neu erzeugen. Das ist keine Pflicht aus diesem Vorfall, aber bei einem Wechsel der CA ohnehin der saubere Weg.
5. Trust-Stores eigener Geräte prüfen. Wer die eMudhra-Root in eigenen Geräten, Java-Keystores, Containern oder Zertifikats-Bundles fest eingetragen hat, sollte sie dort entfernen. Browser aktualisieren das selbst, solche Bestände nicht.
6. Firefox aktualisieren. Ab Version 158.0.1 bzw. ESR 115.43.1 / 153.5.1 sind die Sperren enthalten. Auf verwalteten Arbeitsplätzen prüfen, ob Updates ankommen.
7. Automatisieren. Wer Zertifikate manuell verwaltet, sollte auf automatische Erneuerung (ACME) umstellen. Dann ist ein Wechsel der CA ein Konfigurationswechsel und keine Notfallaktion.

Was wir daraus lernen

• Die Wahl der CA ist eine Risikoentscheidung. Entscheidend sind Transparenz, Prozessqualität und die Mitgliedschaft in den Root-Programmen. Ein Preisschild sagt darüber nichts. Der Vorfall zeigt einen Prozessfehler bei einer Schlüsselzeremonie, der in jeder CA vorkommen könnte.
• Certificate Transparency funktioniert. Die öffentlich einsehbaren Logs haben es ermöglicht, den Vorfall schnell einzugrenzen und die 107.107 Zertifikate zu erkennen.
• Crypto-Agilität lohnt sich. Wer Zertifikate automatisch erneuert und die CA wechseln kann, ohne Dutzende Systeme von Hand anzufassen, kommt aus solchen Vorfällen mit einem Tag Arbeit heraus statt mit einer Woche.
• Überwachen Sie Ihre Domains. Ein Monitoring der Transparenz-Logs (z. B. über crt.sh oder Dienste mit E-Mail-Benachrichtigung) zeigt, wenn jemand Zertifikate für Ihre Domain ausstellt.
• Mehrere Schutzschichten. TLS-Zertifikate sind nur eine Schicht. Zusätzlich helfen CAA-Einträge im DNS (sie legen fest, welche CA für Ihre Domain ausstellen darf) und Zwei-Faktor-Anmeldung. Mehr dazu in unserem Beitrag Odoo 19 absichern: Firewall, 2FA & Web RBL.

Häufige Fragen

Was ist bei eMudhra genau passiert?

Acht Zwischenzertifikate der Zertifizierungsstelle eMudhra hatten private Schlüssel, die ganze Zahlen kleiner als 256 waren (einer: die Zahl 4). Dadurch konnte jeder aus dem öffentlichen Zertifikat den privaten Schlüssel berechnen und gültig aussehende Zertifikate unterschreiben. Die Zwischen-CAs wurden widerrufen, die Root emSign ECC Root CA – G3 wurde aus Firefox (20.10.2026) und Chrome (27.10.2026) entfernt.

Hat eMudhra den privaten Schlüssel „4“ an Kunden ausgegeben?

Nein. Die schwachen Schlüssel gehörten den Zwischenzertifikaten der CA selbst. Sie waren keine Schlüssel von Kunden und wurden nicht an Kunden ausgegeben. Dass in sozialen Netzwerken etwas anderes behauptet wurde, ändert daran nichts.

Muss ich als eMudhra-Kunde sofort mein Zertifikat tauschen?

Nur, wenn Ihr TLS-Zertifikat über die Root emSign ECC Root CA – G3 läuft. Das betrifft nach Angaben von eMudhra einen einzelnen US-Kundenverbund mit rund 30.800 Zertifikaten. Für alle anderen Kunden ist laut eMudhra keine Maßnahme nötig. Prüfen Sie den Aussteller Ihres Zertifikats, bevor Sie handeln.

Woran erkenne ich, ob mein Zertifikat betroffen ist?

Am Aussteller und an der Kette: Sehen Sie sich das Zertifikat im Browser an oder verwenden Sie den OpenSSL-Befehl aus der Checkliste. Namen wie „EM DV TLS CA – G3B“, „EM OV TLS CA – G3C“ oder „emSign ECC Root CA – G3“ weisen auf die betroffene Kette hin.

Muss ich meinen privaten Server-Schlüssel tauschen?

Nicht wegen dieses Vorfalls. Der Server-Schlüssel ist nach den Quellen nicht betroffen. Beim notwendigen Austausch des Zertifikats empfiehlt sich trotzdem ein neuer Schlüssel.

Können Angreifer gefälschte Zertifikate für meine Domain erzeugen?

Mit den acht Schlüsseln konnte man technisch Zertifikate für beliebige Domains unterschreiben. Das war nur so lange wirksam, wie Browser der Kette vertrauten. Nach den Sperren von Mozilla und Chrome ist das für aktuelle Browser nicht mehr möglich. Bei Geräten, die nicht aktualisiert werden oder die Root fest eingetragen haben, kann das Risiko länger bestehen. Monitoren Sie deshalb die Zertifikate für Ihre Domain.

Sind Zertifikate von Let’s Encrypt oder anderen CAs betroffen?

Nach den veröffentlichten Quellen nicht. Mozilla geht nicht davon aus, dass andere CAs betroffen sind.

Was bedeutet der Ausstieg von eMudhra aus dem TLS-Geschäft?

eMudhra stellt keine neuen öffentlichen TLS-Zertifikate mehr aus. Code-Signing, S/MIME, digitale Signaturen und eSign laufen weiter. Wer bisher TLS-Zertifikate von eMudhra bezog, braucht einen neuen Anbieter.

Ist Odoo betroffen?

Odoo selbst nicht. Es gilt aber wie bei jeder Webanwendung: Das TLS-Zertifikat Ihrer Odoo-Domain sollte von einer vertrauenswürdigen CA stammen. Prüfen Sie den Aussteller, besonders wenn Zertifikate nicht automatisch erneuert werden.

Quellen

Abgerufen am 6. November 2026:

• Mozilla Bugzilla, Fehler 2083449 (Vorfallsbericht, Zeitlinie, Zertifikats-Fingerabdrücke): bugzilla.mozilla.org/show_bug.cgi?id=2083449
• Mozilla Security Blog, 20.10.2026: Protecting Firefox users following the compromise of eMudhra intermediate certificates
• eMudhra, Stellungnahme: emudhra.com/en/post/certificate-security-incident
• The Register, 20.10.2026: Indian certification authority eMudhra’s private keys compromised, one of them was the number 4
• Mozilla dev-security-policy: Diskussionsstrang zum Vorfall
• Certificate Transparency Suche: crt.sh

Die Messung der acht Schlüsselwerte ist unsere eigene Nachrechnung anhand öffentlicher Zertifikate. Aussagen zur Ursache, zur Nichtausstellung von Endzertifikaten und zur Zahl der betroffenen Kunden stammen von eMudhra bzw. aus Bugzilla und sind von uns nicht unabhängig überprüft worden.

Unterstützung durch Biricon IT Services

Wenn Sie nicht sicher sind, wer Ihre TLS-Zertifikate ausgestellt hat, unterstützen wir Sie gerne: bei der Bestandsaufnahme aller Zertifikate auf Webservern, Mailservern, Firewalls und Appliances, beim Wechsel zu einer anderen CA, bei der Umstellung auf automatische Erneuerung (ACME) und beim Monitoring Ihrer Domains. Als IT-Dienstleister betreuen wir Server, Firewalls und Webanwendungen für kleine und mittlere Unternehmen.

Jetzt Kontakt aufnehmen

Stand: 6. November 2026. Die Lage kann sich ändern; maßgeblich sind die Veröffentlichungen von Mozilla, Google, Apple und eMudhra.