eMudhra-Zertifikate und der Schlüssel mit dem Wert 4

Lesezeit ca. 7 Minuten | Stand 22. Oktober 2026

Ein privater Schlüssel ist das Geheimnis, auf dem das Schloss in Deiner Browserzeile beruht. Bei einem Verfahren wie P-384 ist er normalerweise eine Zahl mit über hundert Stellen. So gross, dass niemand sie erraten kann.

Bei der indischen Zertifizierungsstelle eMudhra lagen die Schlüssel von acht Zwischenzertifikaten alle unter 256. Einer davon war schlicht die Zahl 4.

Wer diese Schlüssel kannte, hätte gültige HTTPS-Zertifikate für jede beliebige Domain ausstellen können. Auch für Deine. Browser und Betriebssysteme haben die Zertifikate inzwischen gesperrt. Für Websites und Server ist das Thema aber noch nicht überall erledigt.

‍

Das Wichtigste in Kürze

Was: acht Zwischenzertifikate von eMudhra mit erratbaren privaten Schlüsseln, einer davon mit dem Wert 4
Risiko: gefälschte Zertifikate für fremde Domains, damit mitlesen oder Daten verändern
Browser: Chrome, Firefox, Safari und Windows blockieren die Zertifikate bereits
Offen: Server, Apps und Skripte mit eigenem Zertifikatsspeicher brauchen Updates
Bisher: keine Hinweise auf Missbrauch

‍

Was bei eMudhra passiert ist

eMudhra ist eine Zertifizierungsstelle aus Indien. Ihre Wurzelzertifikate sind in den Vertrauensspeichern der grossen Browser und Betriebssysteme hinterlegt. Was eMudhra unterschreibt, gilt dort als echt.

Entstanden sind die Schlüssel im April 2025. Laut eMudhras vorläufiger Erklärung erzeugte ein fehlerhafter Schritt bei der Schlüsselerzeugung einen zweiten Satz extrem schwacher Schlüssel, der versehentlich zum Signieren verwendet wurde. Die genaue Ursache ist laut eMudhra noch nicht abschliessend bestätigt. Betroffen sind sechs Zwischenzertifikate für TLS und zwei für Code-Signaturen.

Am 17. Oktober 2026 meldete ein Forscher den Fund an die Browserhersteller. Der Sicherheitsexperte Scott Helme konnte alle acht Schlüssel in unter einer Sekunde aus den öffentlichen Zertifikaten berechnen. Ein weiterer Forscher veröffentlichte den Schlüssel mit dem Wert 4 als Beweis auf GitHub.

So schnell haben die Hersteller reagiert

17. Oktober: Google Chrome und Mozilla Firefox sperren die Zertifikate über ihre Sperrlisten, ohne dass ein Browser-Update nötig ist
19. Oktober: Apple sperrt, Android erhält die Sperre über die Google Play Services
20. Oktober: Microsoft sperrt, Mozilla entfernt das zugehörige Wurzelzertifikat emSign ECC Root CA G3, viele Linux-Distributionen liefern Updates
21. Oktober: eMudhra nennt eine vorläufige Ursache, Node.js veröffentlicht Fixes

Laut eMudhra waren sieben der acht Zwischenzertifikate nie im Einsatz, und keines hat Zertifikate für Kunden ausgestellt. Hinweise auf Missbrauch gibt es bisher keine. Ausschliessen lässt er sich nicht, denn die schwachen Schlüssel existierten seit April 2025.

‍

Warum eine einzige Zahl so viel ausrichten kann

HTTPS funktioniert über eine Vertrauenskette. Dein Browser kennt eine Liste vertrauenswürdiger Wurzelzertifikate. Diese unterschreiben Zwischenzertifikate, und die unterschreiben wiederum die Zertifikate einzelner Websites.

Wer den privaten Schlüssel eines Zwischenzertifikats besitzt, kann selbst unterschreiben. Er stellt dann ein Zertifikat für deine-firma.ch aus, und jedes Programm, das der Kette vertraut, hält es für echt. Damit lässt sich eine Verbindung abfangen, mitlesen und verändern, ohne dass eine Warnung erscheint.

Die Verschlüsselung selbst ist dabei nicht gebrochen. Gebrochen ist die Frage, ob Du wirklich mit dem richtigen Server sprichst.

Moderne Browser hatten einen zusätzlichen Schutz. Sie verlangen, dass jedes Zertifikat in öffentlichen Protokollen der Certificate Transparency eingetragen ist. In diesen Protokollen tauchte nie ein Zertifikat auf, das von den betroffenen Zwischenzertifikaten ausgestellt wurde. Viele andere Programme prüfen das aber nicht. Genau dort liegt das Restrisiko.

‍

Betrifft das Deine Website?

Für die meisten KMU lautet die Antwort beruhigend. Es lohnt sich trotzdem, drei Ebenen kurz durchzugehen.

Deine Besucher im Browser

Wer einen aktuellen Browser nutzt, ist geschützt. Die Sperren kamen automatisch. Firefox braucht nur dann ein Update, wenn die automatische Aktualisierung der Sperrlisten abgeschaltet ist.

Das Zertifikat Deiner eigenen Website

Das betrifft Dich nur, wenn in der Zertifikatskette Deiner Website eMudhra oder emSign auftaucht. Klick dazu in Deinem Browser auf das Symbol links neben der Adresse, öffne die Zertifikatsdetails und sieh Dir die ganze Kette bis zum Wurzelzertifikat an.

Achtung, auch Zertifikate mit dem Aussteller InCommon können zu dieser Kette gehören. Endet die Kette bei einem anderen Wurzelzertifikat, etwa von Let's Encrypt, DigiCert oder Google Trust Services, musst Du nichts tun.

Stammt Dein Zertifikat aus der betroffenen Kette, brauchst Du zeitnah ein neues aus einer anderen Hierarchie. Chrome entfernt das Wurzelzertifikat emSign ECC Root CA G3 voraussichtlich ab dem 27. Oktober. Danach können solche Seiten für viele Besucher als unsicher erscheinen. Google prüft zudem, ob es auch dem zweiten eMudhra-Wurzelzertifikat das Vertrauen entzieht.

Dein Server als Client

Diese Ebene wird am häufigsten übersehen. Deine Website ruft selbst andere Dienste auf, etwa Zahlungsanbieter, Newsletter-Tools, Versandschnittstellen oder Dein CRM. Dabei prüft Dein Server deren Zertifikate, und zwar mit seinem eigenen Zertifikatsspeicher.

Ist dieser Speicher veraltet, vertraut Dein Server den gesperrten Zertifikaten weiterhin. Bei PHP-Websites hängt das am Paket ca-certificates des Servers und je nach Projekt an der Composer-Bibliothek ca-bundle. Diese wurde am 20. Oktober in den Versionen 1.4.16 und 1.6.0 aktualisiert.

Wer seinen Server gerade wegen der Lücke PHP2Shell aktualisiert, erledigt das am besten im gleichen Schritt.

‍

In fünf Minuten prüfen

Kette prüfen: Zertifikat Deiner Website im Browser öffnen und die ganze Kette bis zum Wurzelzertifikat ansehen
Hoster fragen: Ist das Paket ca-certificates auf dem Server aktuell, und wurden Dienste danach neu gestartet?
Selbst testen: Sicherheitsforscher Dennis Jackson stellt Testadressen bereit. Ruft Dein Server diese ohne Zertifikatsfehler ab, vertraut er den gesperrten Zertifikaten noch
Container neu bauen: Docker-Images enthalten eigene Zertifikatsspeicher und übernehmen Updates erst nach einem Neubau
Nie die Prüfung abschalten: Zertifikatsfehler niemals mit dem Deaktivieren der Prüfung lösen, darauf weist auch Cloudflare ausdrücklich hin

‍

Was der Fall über Website-Infrastruktur zeigt

Das Schloss im Browser wirkt wie ein einfaches Ja oder Nein. Dahinter stehen Zertifizierungsstellen, Sperrlisten, Zertifikatsspeicher auf Servern und Bibliotheken in jedem Projekt. Jede dieser Schichten braucht Pflege.

Bei gehosteten Plattformen übernimmt der Anbieter diese Arbeit. In Webflow etwa wird das SSL-Zertifikat für jede Domain automatisch ausgestellt und erneuert. Bei selbst gehosteten Systemen liegt die Verantwortung bei Dir oder Deinem Dienstleister.

Beides kann gut funktionieren. Entscheidend ist, dass jemand zuständig ist und bei Vorfällen wie diesem schnell handelt. Wie sich die Systeme dabei unterscheiden, zeigt unser Vergleich Webflow vs. WordPress.

‍

Unverbindliche Beratung zu Deiner Website

Du willst wissen, wie sicher Deine Website und ihre Infrastruktur aufgestellt sind? Wir schauen uns Hosting, System und Zertifikate gemeinsam mit Dir an und zeigen Dir, welche Möglichkeiten Du hast. Kostenlos und ohne Verkaufsdruck.

Buch Dir hier einen Termin, wir melden uns innerhalb von 24 Stunden.

‍

Quellen

‍

eMudhra-Zertifikate kompromittiert, der Schlüssel mit dem Wert 4

Das Wichtigste in Kürze