Acht Zwischenzertifikate der indischen Zertifizierungsstelle eMudhra hatten extrem schwache Schlüssel. Damit hätte jeder Webzertifikate für beliebige Server ausstellen können. Browser und einige Programmiersprachen haben die Zertifikate gesperrt, und es gibt keine Berichte über Missbrauch. Die Bereinigung bei Linux, Containern und IoT-Geräten dauert aber lange.
Acht Zwischenzertifikate mit Schlüsseln von nur 3 bis 8 Bit lassen Angreifer Webzertifikate für jede Seite fälschen. Browser haben sie gesperrt. Für Server, Container und Geräte beginnt die Arbeit erst.
Das Wichtigste in Kürze
- Acht Zwischenzertifikate der Firma eMudhra sind unsicher. Die Zertifizierungsstelle sitzt in Indien, und ihre privaten Schlüssel sind extrem schwach.
- Browser, einige Apps und Programmiersprachen haben alle acht blockiert. Berichte über Missbrauch gibt es laut Quelle bisher nicht.
- Die Bereinigung dauert lange. Linux-Distributionen, eingebettete Geräte, IoT und Container hinken hinterher.
- Ein Experte erwartet mehr Aufwand als bei Heartbleed. Die Vielfalt der betroffenen Systeme macht den Patch zäh.
Was passiert ist
Ars Technica hat den Fall am Dienstag, 20. Oktober 2026, veröffentlicht. Eine spätere Aktualisierung der Quelle ist im vorliegenden Text nicht erkennbar. Dieser Beitrag hat den Stand vom 21. Oktober 2026. Das Datum der Quelle ergibt sich aus Wochentag, Monat und Adresse des Artikels.
Zwischenzertifikate gehören zur Vertrauenskette im Web. Wer den privaten Schlüssel eines solchen Glieds besitzt, kann Webzertifikate für beliebige Server ausstellen. Browser und Apps würden diese als echt anerkennen.
Eine inoffizielle Warnseite machte den Fall öffentlich. Dort stand die Nachricht „We have a problem here – Wayne“. Der private Schlüssel eines der eMudhra-Zertifikate hatte sie signiert. Das belegt, dass der Absender diesen Schlüssel kontrolliert. Deshalb schlug die Abwehr sofort Alarm.
Damit reagierten die Hersteller schnell. Bis Dienstagvormittag hatten Browserhersteller und einige grosse Apps und Programmiersprachen alle acht Zertifikate gesperrt. Auch die Certificate-Transparency-Logs zeigen laut Bericht keinen missbräuchlichen Einsatz. Diese Logs protokollieren jede Ausstellung browserbekannter Zertifikate.
Wie schwach die Schlüssel waren
Ein üblicher privater Schlüssel auf der Kurve NIST P-384 bietet rund 384 Bit Entropie. Das ergibt etwa 2 hoch 384 Möglichkeiten, eine Zahl mit 116 Stellen. Die betroffenen Schlüssel lagen laut Bericht bei nur 3 bis 8 Bit. Viele Fachleute können sich einen solchen Fehler kaum erklären.
| Kennzahl | Wert | Bedeutung |
|---|---|---|
| Betroffene Zertifikate | 8 | Alle gehören zu eMudhra Limited. |
| Normale Schlüsselstärke | rund 384 Bit | So viel bietet ein P-384-Schlüssel. |
| Gefundene Schlüsselstärke | 3 bis 8 Bit | Jeder kann solche Werte erraten. |
| Missbrauch in den Logs | keine Berichte | Stand laut Quelle am Dienstagvormittag. |
Zudem nennt die Quelle keine Ursache für die Panne. Auch zur Rolle von eMudhra bei der Entdeckung macht sie keine Angaben.
Warum die Bereinigung der TLS-Zertifikate so lange dauert
Filippo Valsorda ist Kryptografie-Entwickler und Maintainer der Programmiersprache Go. Er erwartet laut Ars Technica einen Aufwand, der grösser ausfällt als bei Heartbleed. Diese Lücke in OpenSSL wurde 2014 massenhaft ausgenutzt. Die Erholung zog sich über Jahre.
Dabei nennt Valsorda mehrere Problemfelder:
- IoT-Geräte und eingebettete Systeme
- Docker-Container
- vergessene Linux-Maschinen
- Kommandozeilen-Tools ohne Pflege, die eine eigene Kopie der Root-Zertifikate mitbringen
Solche eigenen Kopien sind laut Valsorda in manchen Ökosystemen üblich, etwa bei Python. Zudem rollen Linux-Distributionen ihre Korrekturen noch aus. Einige sind noch nicht bereit. Danach müssen Administratoren die neuen Pakete auf viele Maschinen bringen.
So fasst Valsorda die Lage zusammen: Wenn viele Menschen in verschiedenen Umgebungen handeln müssen, dauert es lange. Diesmal gibt es mehr Umgebungen, mehr Beteiligte und mehr Vielfalt.
Weitere Details stehen auf der inoffiziellen Warnseite und in einem Diskussionsthread zu den Zwischenzertifikaten. Den Hintergrund liefert der Bericht von Ars Technica.
Einordnung: Was das für Admins in der Schweiz heisst
Deshalb sollten Admins, die Server, Container oder Geräte betreiben, jetzt Aktualisierungen für Betriebssystem, Browser und Laufzeitumgebungen einspielen. Besonders betroffen sind Systeme mit eigenem Zertifikatsspeicher, zum Beispiel Python-Umgebungen und alte Container-Images. Die Quelle nennt keine feste Frist. Weil sich Webseiten fälschen liessen, ist Eile sinnvoll. Zu Kosten macht die Quelle keine Angaben. Der Aufwand hängt von der Zahl der Maschinen ab, die geprüft werden müssen.
Fazit
Die Hauptgefahr ist vorerst gebannt, weil Browser und viele Programme die acht Zwischenzertifikate sperren. Offen bleibt die Lücke bei vergessenen und selten gepflegten Systemen. Prüfe als nächsten Schritt, welche deiner Maschinen und Images eigene Zertifikatslisten tragen. Spiele die Pakete deiner Linux-Distribution ein, sobald sie bereitstehen.
Quellen: Ars Technica. Foto: WFranz / Pixabay. Stand: 21. Oktober 2026.
Recherche und Entwurf KI-gestützt, geprüft und freigegeben von Andreas Brauckmann · So arbeitet die Redaktion
Änderungshistorie
- — Artikel veröffentlicht.