Alle Beiträge

Eine CA hat das Vertrauen verloren. Weiß deine Node-App davon?

Sicherheit · 4 Min. Lesezeit ·

In der Woche ab dem 18. Oktober 2026 hat eine Zertifizierungsstelle das Vertrauen des Webs verloren. Laut dem Incident-Tracker pwn.watch meldete ein Forscher, dass die privaten Schlüssel von acht Zwischen-CAs der eMudhra Global TLS kryptografisch schwach waren und sich rekonstruieren ließen; Mozilla, Chrome, Apple und Microsoft blockierten diese Zwischenzertifikate, und eMudhra widerrief sie am 19. Oktober. Am 22. Oktober kündigte das Unternehmen an, sich aus dem globalen SSL/TLS-Zertifikatsgeschäft zurückzuziehen. Wenn du PHP oder Node.js schreibst: Deinen Browser hat sein Hersteller geschützt. Deine Backend-Dienste waren nur geschützt, wenn jemand sie aktualisiert hat.

Was passiert ist, laut Unternehmen und laut Tracker

In der Pressemitteilung von eMudhra heißt es, die betroffenen CAs seien "within 14 hours of discovery" widerrufen und der Vorfall zügig offengelegt worden. Diese Zahl stammt vom Unternehmen selbst. Außerdem steht dort, dass aus den betroffenen CAs keine Endnutzer-Zertifikate ausgestellt wurden, dass die eigene Infrastruktur nicht kompromittiert wurde und keine Daten abgeflossen sind, und dass globales SSL/TLS rund 1 % des Umsatzes ausmacht. Die G1-RSA-Roots bedienen Kunden während des Übergangs weiter, betroffene Kunden bekommen über Partner kostenlos Ersatzzertifikate, und Widerrufs- und Statusdienste laufen weiter, bis jedes ausgestellte Zertifikat abgelaufen oder ersetzt ist.

Der Tracker pwn.watch ergänzt, dass der ECC-Root vorsorglich nicht mehr vertrauenswürdig ist und dass Runtimes mit eigenem Trust Store, genannt werden unter anderem Go, Node.js, Electron, certifi für Python und curl, ein Notfall-Update ihres CA-Bundles brauchten. Das Node.js-Projekt bestätigt seinen Teil in den Security-Releases vom Oktober 2026: Dort steht ein ca-cert-Update wegen der "eMudhra Intermediate CA Compromise" für die Linien 26.x, 24.x und 22.x.

Root-CA im Trust Store signiert Zwischen-CA schwacher Schlüssel signiert Leaf-Zertifikat api.example Entzogen oder widerrufen: alles darunter scheitert
Ein Client vertraut einem Leaf-Zertifikat wegen der Kette darüber. Fällt die Zwischen-CA weg, endet die Kette am Bruch.

Die Liste deines Browsers ist nicht die deines Servers

Dieser Teil ist allgemeines Wissen darüber, wie TLS-Clients arbeiten, kein Detail dieses Vorfalls. Ein TLS-Client entscheidet anhand einer Liste von Root-Zertifikaten, seinem Trust Store, wem er vertraut. Browser und Betriebssysteme liefern ihre eigene Liste aus und aktualisieren sie selbst. Viele Runtimes und Bibliotheken bringen stattdessen eine eigene Kopie mit: Node.js bündelt die Mozilla-Liste in jedem Release, und Python-Code mit certifi vertraut der Datei von certifi. Andere Runtimes lesen den Store des Betriebssystems, sofern man nichts anderes einstellt. Schau also in die Doku deiner Runtime, statt es anzunehmen.

Deshalb kommt ein Vertrauensentzug unterschiedlich schnell bei den Leuten an. Chrome auf deinem Laptop hat sich selbst aktualisiert. Ein Node-Dienst, der aus einem im August gebauten Docker-Image eine Zahlungs-API aufruft, trägt noch die Liste vom August mit sich und vertraut einer widerrufenen Zwischen-CA so lange, bis sich die Runtime oder das Bundle in diesem Image ändert.

Browser aktualisiert sich OS-Store per OS-Update Runtime-Bundle Node, certifi Docker-Image beim Build fixiert Dein Node-Dienst ruft eine API auf von Servern nicht genutzt gestrichelt: hängt von der Runtime und vom Image-Build ab
Vier Listen, vier Update-Rhythmen. Eine Backend-App vertraut der Liste, mit der sie gebaut wurde.

Was du diese Woche tun solltest

Aktualisiere die Runtime jedes Dienstes, dann bau die Images neu und deploye sie, denn ein neues Node.js-Release auf deinem Laptop ändert nichts in einem Image, das schon läuft. Wo Python im Spiel ist, aktualisiere auch certifi.

node --version
docker build --pull --no-cache -t my-api .
pip install --upgrade certifi

Wenn ein Aufruf nach dem Update mit einem Zertifikatsfehler scheitert, ist das der Schutz, der greift. Setz nicht NODE_TLS_REJECT_UNAUTHORIZED=0 und übergib nicht rejectUnauthorized: false, um den Fehler loszuwerden: Damit schaltest du die Prüfung für jede Verbindung des Prozesses ab, nicht nur für die kaputte. Finde heraus, welches Zertifikat die Gegenseite vorlegt, und lass es ersetzen; laut eMudhra bekommen betroffene Kunden den Ersatz kostenlos.

Schreib auf, woher jeder Dienst seine CA-Liste bezieht, und mach "Runtime aktualisieren und Image neu bauen" zu einer monatlichen Aufgabe statt zu einer Reaktion auf einen Vorfall.

Nächster Schritt: Öffne das Dockerfile deines ältesten laufenden Dienstes, prüf das Datum seines Base-Images und bau es heute neu. Richte danach eine Überwachung für Zertifikatsablauf und Certificate Transparency für deine eigenen Domains ein, damit dich die nächste Änderung bei ihrer Ausstellung erreicht, bevor sie deine Nutzer erreicht.

Quelle: Pressemitteilung von eMudhra, 22. Oktober 2026, und die Node.js-Security-Releases vom Oktober 2026.

Notizen der Leser

  1. Noch keine Notizen. Die erste ist immer die mutigste.
Baust du etwas Ähnliches? Ich kann helfen. Schreib mir auf WhatsApp