Einige Links auf dieser Seite sind Affiliate-Links: bei einer Anmeldung darüber erhält diese Seite eine Provision, für Sie ohne Mehrkosten. Preise und Empfehlungen bleiben davon unberührt.

Am 17. Oktober 2026 teilte ein Forscher den Root-Programmen mit, dass die privaten Schlüssel von acht eMudhra-Zwischenzertifizierungsstellen kompromittiert sind, und er bewies es auf die harte Tour: Er signierte mit jedem der acht Schlüssel eine kurze Nachricht und legte die Signaturen bei. Jeder kann sie mit OpenSSL prüfen. Die Schlüssel waren seit April 2025 berechenbar.

Die Browser waren innerhalb weniger Tage repariert. Firefox und Chrome sperrten die Zwischenzertifikate am 17., Microsoft-Plattformen am 20., Apple-Produkte am 22. Womit du surfst, ist inzwischen in Ordnung.

Mit den Maschinen, die du betreust, sieht es anders aus. Das hier ist die Checkliste dafür, plus die Teile der Geschichte, die bestimmen, was du prüfen solltest. Alles zum Vorfall stammt von der Vorfallsseite, die wir am Tag der Veröffentlichung noch einmal gelesen haben. Die vier Test-Endpunkte aus Schritt 1 haben wir auf einer unserer Ubuntu-26.04-Maschinen ausgeführt, und alle vier endeten mit einem Zertifikatsfehler, also mit dem gewünschten Ergebnis. Jede Laufzeitumgebung darauf haben wir nicht geprüft, und die Schritte unten sind kein Protokoll davon.

Was tatsächlich kaputtging

Die acht Zwischenzertifikate führen zu Roots, denen die Root-Programme von Mozilla, Microsoft, Apple und Chrome vertrauen. Wer einen der privaten Schlüssel besitzt, kann ein Zertifikat für jede beliebige Domain ausstellen, und ein Client, der dem Zwischenzertifikat noch vertraut, akzeptiert es.

Die Ursache sollte man sich merken. Die CA hat die Schlüssel fehlerhaft erzeugt, daher lassen sie sich aus den Zertifikaten selbst berechnen. Das galt ab dem Tag, an dem die Zertifikate erstellt wurden, April 2025. Die Certificate-Transparency-Logs enthalten für diese Zwischenzertifikate in dem Zeitraum keine Einträge, deshalb konnten Clients, die CT durchsetzen, also die großen Browser, darüber nicht angegriffen werden. Bei Clients ohne CT-Prüfung sieht es anders aus, und die Vorfallsseite sagt offen, dass niemand weiß, ob Angreifer den Fehler gegen sie genutzt haben.

Die CA hat die Zwischenzertifikate zurückgerufen, und die Root-Programme haben das über ihre eigenen Kanäle verteilt: OneCRL und CRLite bei Mozilla, CRLSets bei Chrome. So bleibt ein Browser ohne neuen Build geschützt. Sehr viele Clients schauen in keinen dieser Kanäle.

Zwei Vertrauensebenen, und nur eine wurde getroffen

Die meisten Self-Hosting-Anleitungen werfen beides zusammen, deshalb lohnt es sich, es zu trennen.

Deine Zertifikate sind in Ordnung. Wenn Caddy, Traefik, acme.sh oder certbot deine Zertifikate bei Let’s Encrypt holt, hat sich daran nichts geändert. Die eMudhra-Zwischenzertifikate liegen nicht in dieser Kette, und weder das ACME-Protokoll noch deine Account-Schlüssel waren beteiligt. Die Verlängerung läuft weiter.

Was deine Werkzeuge als vertrauenswürdig ansehen, ist der offene Teil. Jede ausgehende HTTPS-Anfrage deines Servers (git pull, curl an eine API, eine Paketinstallation, ein Container-Pull, ein Webhook) ist nur so vertrauenswürdig wie der Zertifikatsspeicher auf dieser Maschine. Enthält er die schlechten Zwischenzertifikate noch, kann jemand auf dem Netzwerkpfad GitHub, deinen Paketspiegel oder jede API vortäuschen, und der Client nimmt es kommentarlos hin.

Das ist das ganze Risiko, und der größte Teil davon steckt in Software, die kein Browser ist.

Warum “OS aktualisieren” nicht die ganze Lösung ist

Zwei Dinge unterscheiden Browser von allem anderen hier.

Erstens die Sperrung. Browser bekommen diese Zwischenzertifikate über OneCRL, CRLite und CRLSets gesperrt. curl, git, Go-Binaries und die meisten Laufzeitumgebungen nutzen nichts davon, für sie hilft nur ein Trust Store, der die Zwischenzertifikate nicht mehr enthält.

Zweitens Certificate Transparency. Browser lehnen Zertifikate ab, die nie geloggt wurden. Den meisten Nicht-Browser-Clients ist das egal. Die Vorfallsseite betreibt dafür zwei zusätzliche Testhosts: Deren Zertifikate wurden nie in CT geloggt, ein Client, der sich dorthin verbindet, vertraut also den schlechten Zwischenzertifikaten und setzt auch CT nicht durch. Genau diese Kombination kann ein Angreifer nutzen, ohne dass es jemand bemerkt.

Die Aufgabe ist also nicht ein Update, sondern eines pro Programm, das einen eigenen Trust Store mitbringt oder erbt.

Das 30-Minuten-Audit

Auf jedem Server, CI-Runner und Entwicklungsrechner ausführen, den du anfasst. Jeder Schritt ist ein oder zwei Befehle.

1. System-CA-Bundle aktualisieren

Debian und Ubuntu:

sudo apt update && sudo apt upgrade -y ca-certificates

RHEL, Fedora, Alma, Rocky:

sudo dnf upgrade -y ca-certificates

Alpine:

sudo apk upgrade ca-certificates

Die korrigierten Paketversionen stehen auf der Vorfallsseite. Für Debian 12 ist es 20250419~deb12u2, für Ubuntu 24.04 20260816ubuntu0.24.04.1, für Alpine 20261020-r0. Vergleiche mit dpkg -l ca-certificates oder apk info ca-certificates und mach dann den echten Test. Ein Zertifikatsfehler heißt, dass dieser Client den kompromittierten Zwischenzertifikaten nicht vertraut. Eine erfolgreiche Antwort heißt, dass du noch offen bist:

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
curl https://dv-g3b-noct-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/

Wenn du Java aus Debian- oder Ubuntu-Paketen betreibst, kommt noch etwas dazu: Das System-Update erneuert den Java-Keystore nicht, wegen eines alten Fehlers in ca-certificates-java. Die Vorfallsseite empfiehlt, ihn als root neu zu erzeugen:

rm -f /etc/ssl/certs/java/cacerts && update-ca-certificates --fresh

2. Die Bundles reparieren, die das System-Update nie berührt hat

Mehrere Laufzeitumgebungen tragen eine eigene Kopie und merken dein ca-certificates-Upgrade nicht.

Pythons requests liest das certifi-Bundle, nicht den System-Store. Die korrigierte Version ist certifi 2026.10.19, und pip selbst ist ab 26.2.2 korrigiert:

pip install --upgrade certifi pip

Node.js bringt einen eigenen Root Store mit und liest standardmäßig nicht den des Systems. Die gepatchten Versionen sind 26.12.1, 24.22.1 und 22.23.4, ein lang laufender Node-Dienst braucht also ein neueres Node, nicht ein neueres ca-certificates. Go liest unter Linux den System-Store, trotzdem hat das Projekt Korrekturen in 1.27.3 und 1.26.10 veröffentlicht, und Rust-Programme, die webpki-roots einbinden, müssen gegen ein gepatchtes Crate neu gebaut werden.

Als wir nachsahen, standen certbot und containerd auf der Vorfallsseite noch als ausstehend. Schau dort noch einmal nach, bevor du annimmst, dass deine Version abgedeckt ist.

Alles, was den System-Store liest, muss trotzdem neu gestartet werden. Ein Dienst, der vor dem Update gestartet ist, behält den alten Store im Speicher, bis du ihn neu startest.

3. Container-Images neu ziehen oder neu bauen

Ein Image friert sein CA-Bundle zum Build-Zeitpunkt ein. Wurde es gebaut, bevor die Distribution die Entfernung ausgeliefert hat, vertraut es den Zwischenzertifikaten, egal wie gut der Host gepatcht ist.

docker pull debian:bookworm   # oder dein Basis-Image
docker compose build --pull   # wenn du selbst baust

Der Haken: Ein altes Tag wird nie neu gebaut. Steht in deinem Dockerfile noch node:20, golang:1.23 oder alpine:3.19, haben diese Zeilen ihr Lebensende erreicht, und ein erneutes Pull liefert dasselbe veraltete Bundle. Wechsle auf ein unterstütztes Tag. Bei Images, die du nicht selbst baust, prüfe, ob der Herausgeber nach dem 20. Oktober ein neues Tag veröffentlicht hat. Diesen Schritt überspringen die meisten, und er schützt die Container.

4. Electron-Apps überall aktualisieren, wo du entwickelst

Electron-Apps bekommen die Korrektur nur, wenn sie auf einem gepatchten Electron-Release neu gebaut wurden (44.9.1, 43.8.1 und 42.11.16 sind die korrigierten Linien). Ein Update des Betriebssystems oder des Browsers bringt ihnen nichts. Slack, Discord und alles andere auf dieser Laufzeit braucht ein eigenes Update, auf dem Desktop wie auf CI-Runnern.

Apples Entwicklerwerkzeuge waren ein Sonderfall: git, curl und python3, die mit macOS kommen, vertrauten den kompromittierten Zertifikaten am 28. Oktober noch, und macOS 27.2 machte die Korrekturen rückgängig, die manche von Hand angewendet hatten. Teste auf einem Mac die Werkzeuge direkt mit den curl-Befehlen oben, statt der OS-Version zu glauben.

5. Die Runner ansehen, die dein CI wirklich benutzt

Ein gehosteter Runner, ein selbst betriebener Agent oder ein Build-Container ist hier ein Ziel für Lieferkettenangriffe. Kann ein Angreifer die Paketregistry vortäuschen, kann er verändern, was dieser Runner baut. Prüfe, ob das Runner-Image aktuell ist und ob das angepinnte Basis-Image aus Schritt 3 erneuert wurde. GitLab Runner 19.5.1 ist die korrigierte Version, falls das dein Runner ist.

Was das nicht berührt

Das Thema lief wegen der Multi-Perspective Validation von Let’s Encrypt, bei der die Kontrolle über eine Domain von mehreren Netzwerkstandpunkten aus geprüft wird, damit ein BGP-Hijack auf einem Pfad die CA nicht dazu bringt, für eine Domain auszustellen, für die sie es nicht sollte. Das ist ein echter Schutz, und er liegt auf der Ausstellungsebene: Er schützt den Moment, in dem ein Zertifikat angefordert wird.

Das eMudhra-Problem liegt auf der Vertrauensebene. Die Schlüssel einer CA wurden kompromittiert, und das hat nichts damit zu tun, wie Domains validiert wurden, also hätte Multi-Perspective Validation es nicht gefangen. Die beiden verwechselt man leicht. “Let’s Encrypt validiert von mehreren Orten” ist kein Grund, das Audit oben zu überspringen.

Für den eigenen ACME-Stack läuft es auf drei Dinge hinaus. Deine Zertifikate sind unberührt, und Verlängerungen laufen weiter. Deine Clients sind das Risiko, und nur ein Trust-Store-Update behebt es. Und Caddy oder Traefik, die TLS mit deinem eigenen Zertifikat terminieren, sind in Ordnung, während git, curl, docker und die Laufzeitumgebungen auf demselben Server die Angriffsfläche sind.

Wo du das Audit durchführst

Der Stack, den du prüfst, ist höchstwahrscheinlich ein kleiner VPS oder ein Container-Host, und die Schritte oben setzen eine Shell darauf voraus. Wenn du die Maschine noch aussuchst: Die Budget-Klasse haben wir gebenchmarkt und im VPS-Vergleich beschrieben. Das ACME-Setup, das diese Seite ausliefert, Caddy und Docker hinter einem einzigen Hostnamen, steht im Caddy-Produktivleitfaden. Der Fall der Altmaschine, auf der sich certbot nicht installieren lässt und du die Verlängerung mit acme.sh selbst übernimmst, ist der, den die meisten Self-Hoster früher oder später erben.