eMudhra: Acht CA-Schlüssel berechenbar, was Ihre Domains jetzt schützt

Was passiert ist

Ein öffentlich vertrauenswürdiges TLS-Zertifikat hängt an einer Kette: Ein Wurzelzertifikat liegt im Vertrauensspeicher von Browsern und Betriebssystemen, es signiert ein oder mehrere Zwischenzertifikate, und erst diese stellen die Zertifikate für Websites aus. Der private Schlüssel eines Zwischenzertifikats ist darum einer der wertvollsten Schlüssel im Web: Wer ihn besitzt, signiert selbst Zertifikate für beliebige Namen, und jeder Client, der die Kette bis zur Wurzel kennt, nimmt sie an. Eine Zertifizierungsstelle erzeugt solche Schlüssel in einer dokumentierten Zeremonie und bewahrt sie in Hardware auf, die sie nie verlässt.

Bei eMudhra, einer Zertifizierungsstelle aus Indien, waren acht dieser Schlüssel nicht geheim. Google beschreibt die Ursache so: Die privaten Schlüssel wurden „generated with insufficient randomness (i.e., weak cryptographic entropy)“. Ein Schlüssel, der aus zu wenig Zufall entsteht, lässt sich aus dem öffentlichen Zertifikat zurückrechnen. Jeder, der das tut, kann gültig signierte Zertifikate für fremde Websites erzeugen, solange ein Client der Kette vertraut. Nach Angaben von eMudhra, wie von der Presse berichtet, stammen die Schlüssel aus einer Zeremonie im April 2025, bei der ein fehlerhaftes Skript einen zweiten, schwächeren Schlüsselsatz erzeugte, den Mitarbeitende verwechselten. Sieben der acht Zwischenzertifikate seien nie im Betrieb gewesen, das achte habe kein einziges Website-Zertifikat ausgestellt; die Wurzelschlüssel seien nicht betroffen.

Zwischen dem Hinweis und der Sperre in Chrome lagen eine Stunde und vierzig Minuten. Firefox sperrte über denselben Mechanismus, den es für solche Fälle vorhält.

Warum der Schaden begrenzt blieb

Drei Mechanismen haben diesen Fall abgefangen, und keiner davon war ein Browser-Update. Der erste sind die Sperrlisten der Browser: Chrome verteilt mit dem CRLSet eine kleine Datenliste gesperrter Zertifikate und Schlüssel, Firefox mit OneCRL. Beide erreichen die Installationen innerhalb von Stunden, ohne dass jemand eine neue Version einspielt. Chrome sperrte dabei nicht einzelne Zertifikate, sondern die Schlüssel der Zwischenzertifikate selbst. Damit fällt jedes Zertifikat, das jemand mit einem berechneten Schlüssel signiert, auch wenn es nie jemand gesehen hat.

Der zweite ist Certificate Transparency. Chrome nimmt ein öffentlich vertrauenswürdiges Zertifikat nur an, wenn es in öffentlichen, nur anhängbaren Protokollen eingetragen ist. Ein gefälschtes Zertifikat müsste also protokolliert werden, um in Chrome zu wirken, und wäre dort für jeden sichtbar. Google hat die Protokolle geprüft: Vor der Sperre war kein einziges TLS-Zertifikat eingetragen, das zu den sechs für Websites vorgesehenen Zwischenzertifikaten gehörte. Googles Schluss daraus: „no fraudulent certificates issued by these CAs could have been used against CT-enforcing clients“. Zusätzlich hat Google darauf hingewirkt, dass die Protokolle Zertifikate aus diesen Ketten künftig abweisen.

Der dritte sind die Laufzeiten. Je kürzer ein Zertifikat gilt, desto weniger hängt davon ab, ob ein Widerruf jeden Client erreicht. Der Weg zu 47 Tagen, den der Beitrag zur Zertifikatslaufzeit beschreibt, verfolgt genau dieses Ziel. Für diesen Fall half er noch nicht: Ein gefälschtes Zertifikat mit der heute erlaubten Laufzeit von 200 Tagen wäre monatelang gültig geblieben, und seit Let's Encrypt seinen OCSP-Dienst eingestellt hat, prüfen viele Clients den Widerruf einzelner Zertifikate gar nicht mehr. Die Sperre der Schlüssel in den Listen der Browser hat das für Browser ersetzt. Für alles andere nicht.

Wo das Risiko bleibt

CRLSet und OneCRL erreichen Browser. Ein großer Teil des TLS-Verkehrs läuft aber zwischen Programmen: Ihre API ruft einen Zahlungsdienst, ein Cronjob holt Daten bei einem Partner, eine Build-Pipeline lädt Pakete, ein Gerät im Kundennetz meldet sich bei seiner Cloud. Diese Clients bringen oft einen eigenen Vertrauensspeicher mit: Go prüft Ketten mit eigenem Code, Python nutzt häufig das Paket certifi, Node.js liefert seine Wurzeln selbst mit, Java hält sie in seiner cacerts-Datei, und ein Container trägt den Speicher seines Basis-Images, so alt wie das Image. Appliances und Geräte im Internet der Dinge haben einen Speicher, den oft niemand mehr pflegt.

Diese Clients prüfen in der Regel keinen Widerruf und erzwingen keine Certificate Transparency. Sie vertrauen den berechneten Schlüsseln, bis ihr Speicher aktualisiert oder die Kette ausdrücklich ausgeschlossen wird. Das Go-Projekt hat das getan: Go 1.27.3 weist Ketten mit den kompromittierten Schlüsseln ab, geführt als CVE-2026-111943. Programme, die mit einer älteren Go-Version gebaut wurden, tun das erst nach einem neuen Build. Für Python, Node.js, Java und jedes Basis-Image gilt dasselbe: Der Schutz kommt mit dem Update, das jemand einspielt.

Für Betreiber einer Website bleibt eine zweite Frist. Chrome entfernt am 27. Oktober die Wurzel emSign ECC Root CA - G3, unter der die betroffenen Zwischenzertifikate hingen. Wer ein gültiges Zertifikat aus dieser Kette einsetzt, sieht in Chrome von da an eine Warnung. Google formuliert es ohne Umweg: Solche Betreiber „must immediately acquire and install a new TLS certificate from another PKI hierarchy“. Google hat zugleich geprüft, dass keine andere Wurzel im Chrome Root Store denselben Fehler trägt.

Was Sie jetzt prüfen

Für eine Agentur, die Websites und Anwendungen für Kunden betreibt, ist der Fall weniger eine Frage nach eMudhra als eine Übung für den nächsten Fall. Diese sieben Punkte lassen sich an einem Nachmittag durchgehen.

1. Inventar. Welche Zertifizierungsstelle stellt für welche Kundendomain aus, und über welche Wurzel läuft die Kette? Der Zertifikatsdialog des Browsers oder openssl s_client -showcerts zeigen Aussteller und Wurzel. Taucht emSign ECC Root CA - G3 auf, ist vor dem 27. Oktober ein neues Zertifikat aus einer anderen Kette fällig.
2. CAA-Einträge. Ein CAA-Eintrag in der Zone nennt die Stellen, die für die Domain ausstellen dürfen; jede Stelle muss ihn vor der Ausstellung prüfen (RFC 8659). Er verhindert Fehlausstellungen durch Stellen, mit denen Sie nie gearbeitet haben, und hält die Zahl der Ketten klein, die Sie im Blick behalten müssen.
3. Certificate Transparency beobachten. Die Protokolle sind öffentlich und durchsuchbar. Wer die Namen seiner Kunden dort überwacht, erfährt von jedem Zertifikat, das jemand für diese Namen erhält, auch von einem, das niemand bestellt hat.
4. Vertrauensspeicher jenseits des Browsers. Laufzeiten, Pakete wie certifi, Java-Installationen und Appliances brauchen ihr Update einzeln. Eine Liste, wo überall TLS-Clients laufen, ist dafür die Voraussetzung.
5. Container neu bauen. Ein Image trägt den Vertrauensspeicher seines Basis-Images. Erst ein neuer Build mit aktualisierter Basis übernimmt die Sperre; ein laufender Container ändert sich nicht von selbst.
6. Geräte ohne Update. Was keinen aktuellen Speicher mehr bekommt, gehört hinter eine Stelle, die ihn hat: ein Reverse Proxy, der die Verbindung nach außen aufbaut, oder ein Netz, aus dem das Gerät nicht selbst ins Internet spricht.
7. Ausstellung automatisieren. Mit ACME ist ein erzwungener Tausch kein Projekt, sondern eine Bestellung, die der Server selbst aufgibt. Wer heute noch von Hand erneuert, bekommt das bis 2029 ohnehin auf den Tisch.

Was das für Kunden von obhut heißt

obhut bestellt Zertifikate ausschließlich bei Let's Encrypt: für voll eingerichtete Zonen per DNS-01 als Wildcard, für Hostnamen, die per CNAME auf obhut zeigen, einzeln per HTTP-01. Kein Zertifikat, das obhut für eine Kundendomain ausliefert, läuft über eine Kette von eMudhra. Die CAA-Einträge von obhut.io erlauben nur letsencrypt.org die Ausstellung, und die Qualifikation jedes Releases prüft genau das. Das DNS von obhut unterstützt CAA-Einträge, sodass Agenturen die erlaubten Stellen auch für die Zonen ihrer Kunden festlegen können.

Der Edge von obhut und mehrere seiner Dienste sind in Go geschrieben. Die Go-Werkzeugkette wurde am 20. Oktober 2026 auf Go 1.27.3 gehoben, die Version, die Ketten mit den kompromittierten Schlüsseln als CVE-2026-111943 abweist; dieser Build läuft seit dem Release vom 22. Oktober in Produktion. Eine Überwachung der Certificate-Transparency-Protokolle für Kundendomains bietet obhut heute nicht; dafür eignen sich die öffentlichen Suchdienste über die Protokolle. Wie obhut private Schlüssel vor der Weitergabe versiegelt, beschreibt der Beitrag zu den versiegelten Schlüsseln.

Häufige Fragen

Muss ich mein Zertifikat tauschen?

Nur, wenn seine Kette über emSign ECC Root CA - G3 oder eines der acht gesperrten Zwischenzertifikate läuft. Dann vor dem 27. Oktober, mit einem Zertifikat aus einer anderen Kette. Ein Zertifikat von Let's Encrypt oder einer anderen, unbeteiligten Stelle bleibt gültig und braucht keinen Eingriff.

Schützt ein CAA-Eintrag gegen so einen Fall?

Nur zum Teil. CAA bindet Zertifizierungsstellen, die sich an die Regeln halten: Sie prüfen den Eintrag und stellen nicht aus. Wer mit einem berechneten Schlüssel selbst signiert, durchläuft keinen Ausstellungsprozess und fragt keine Zone. Gegen die Fälschung helfen Certificate Transparency und die Sperrlisten der Browser; CAA hält die Zahl legitimer Ketten klein und verhindert Ausstellungen, die niemand bestellt hat.

Warum reicht die Browser-Sperre nicht für meine API-Clients?

Weil sie die Clients nicht erreicht. CRLSet und OneCRL sind Datenlisten der Browser. Ein Programm mit eigenem Vertrauensspeicher kennt sie nicht, prüft meist keinen Widerruf und erzwingt keine Certificate Transparency. Es vertraut der Kette, bis sein Speicher aktualisiert oder sein Code neu gebaut ist, bei Go mit Version 1.27.3.

Woran erkenne ich, ob meine Kette über emSign läuft?

Am Namen der Wurzel. Der Zertifikatsdialog des Browsers zeigt die Kette bis zur Wurzel; auf der Kommandozeile tut das openssl s_client -connect example.de:443 -showcerts. Steht dort emSign ECC Root CA - G3 oder ein Aussteller von eMudhra, ist die Kette betroffen.