Am 20. Oktober 2026 wurde bekannt, dass die privaten Schlüssel von acht Zwischenzertifizierungsstellen (Intermediate-CAs) des indischen CA-Betreibers eMudhra von jedermann rekonstruiert werden können. Browser haben die Zertifikate noch am Tag der Meldung blockiert. Viele Java-Anwendungen vertrauen ihnen jedoch bis heute – und werden das weiter tun, bis jemand das JDK aktualisiert oder dessen Truststore ändert.

Am 21. Oktober 2026 hat BellSoft Testergebnisse veröffentlicht, die zeigen, dass viele Java-Runtimes diese Zertifikate weiterhin akzeptieren. Dieser Artikel fasst die Ergebnisse zusammen, die wir in eigenen Tests bestätigt haben, und erklärt, warum Java betroffen ist, Browser aber nicht, wie Sie Ihre Systeme prüfen und was Sie tun können.

Was ist passiert?

eMudhra hat die privaten Schlüssel von acht seiner Intermediate-CA-Zertifikate fehlerhaft erzeugt, sodass jeder sie aus den öffentlichen Zertifikaten rekonstruieren kann. Das ist seit der Ausstellung der Intermediates im April 2025 möglich.

Am 17. Oktober 2026 hat ein Melder das Problem nachgewiesen, indem er die Nachricht „We have a problem here“ mit jedem der acht Schlüssel signierte und die Signaturen an die Root-Programme der Browser schickte. Die Details wurden am 20. Oktober öffentlich.

• Sechs Intermediates stellen TLS-Zertifikate aus: die DV-, OV- und EV-TLS-CAs von eMudhra, jeweils in den Generationen G3B und G3C.
• Zwei Intermediates stellen Code-Signing-Zertifikate aus.
• Jedes Intermediate gibt es zweimal: signiert von einer emSign-Root von eMudhra und cross-signiert von der Sectigo-Root AAA Certificate Services. In einem JDK-Truststore enden die Ketten bei einer von zwei Roots: emSign ECC Root CA - G3 (über eine Cross-Signatur) oder AAA Certificate Services.

Firefox und Chrome blockieren die Intermediates seit dem 17. Oktober, Apple seit dem 19. und Microsoft seit dem 20. Oktober. eMudhra hat alle acht am 18. und 19. Oktober mit dem Grund CA_COMPROMISE gesperrt. Linux-Distributionen haben aktualisierte CA-Zertifikatspakete veröffentlicht.

Welche Auswirkungen hat das?

Wer einen dieser Schlüssel besitzt, kann ein Zertifikat für jeden beliebigen Hostnamen erstellen, etwa für Ihre Bank, Ihren Cloud-Anbieter oder Ihr eigenes API-Gateway. Ein Client, der der Kette vertraut, akzeptiert es. Hat ein Angreifer zusätzlich eine Möglichkeit, Datenverkehr abzufangen – zum Beispiel über ein kompromittiertes Netzwerk oder einen manipulierten DNS-Eintrag –, könnte er:

• den Datenverkehr zwischen einer Java-Anwendung und den von ihr aufgerufenen Diensten mitlesen und verändern, einschließlich Passwörtern, API-Schlüsseln und Tokens;
• sich als Paket-Repository, Update-Server oder Partner-API ausgeben;
• über die beiden Code-Signing-Intermediates Code signieren, der scheinbar von einem vertrauenswürdigen Herausgeber stammt.

Die Intermediates sind nie in Certificate-Transparency-Logs (CT) aufgetaucht, daher konnten Browser, die CT erzwingen, über sie nicht angegriffen werden. Ob die Schlüssel gegen Clients eingesetzt wurden, die CT nicht prüfen, ist noch nicht bekannt. Java gehört zu diesen Clients.

Warum Java diesen Zertifikaten weiterhin vertraut

Mozilla, Google, Apple und Microsoft haben die Sperre über eigene Kanäle wie OneCRL, CRLite und CRLSets verteilt. Die Standard-TLS-Implementierung des JDK liest keinen davon. Drei Standardeinstellungen machen Java angreifbar:

• Ein eigener Truststore. Sofern eine Anwendung nicht javax.net.ssl.trustStore setzt, vertraut Java den Roots in $JAVA_HOME/lib/security/jssecacerts, falls diese Datei existiert, und andernfalls denen in $JAVA_HOME/lib/security/cacerts. Ein vom Anbieter mitgeliefertes cacerts erhält weder Sperrlisten der Browser noch CA-Updates des Betriebssystems. Es ändert sich nur, wenn ein Administrator es bearbeitet oder ein JDK-Update es ersetzt.
• Keine Sperrprüfung. Java prüft den Sperrstatus nur, wenn Sie das aktivieren (com.sun.net.ssl.checkRevocation ist standardmäßig false). Die Sperrung durch die CA bleibt in einer Standardkonfiguration also unsichtbar.
• Keine Certificate Transparency. Das JDK erzwingt CT nicht, daher greift der Schutz, der Browser-Nutzer abgesichert hat, hier nicht.

Die Seite mit der Offenlegung nennt zwölf Testhosts, einen für jede Kombination aus Intermediate und Root. BellSoft hat sie am 21. Oktober unter Linux getestet, wir haben den Test am 23. Oktober wiederholt:

Getestete Runtime	Vertraute Testhosts
Liberica JDK 21.0.10	12 von 12
Liberica JDK 8u504 (Container-Image)	12 von 12
Liberica JDK 21.0.12.1 (Container-Image)	12 von 12
Eclipse Temurin 25.0.4.1	6 von 12 (nur eMudhra-Root)
Eclipse Temurin 21.0.12.1 (Container-Image, unser Test)	6 von 12 (nur eMudhra-Root)
Arch Linux OpenJDK 27 (System-CA-Store)	6 von 12 (nur eMudhra-Root)

Der Unterschied liegt in der Sectigo-Root. Mozilla hatte AAA Certificate Services bereits entfernt, und die Truststores von Temurin und Arch Linux werden aus der Mozilla-Liste erzeugt. Dort ist also nur der eMudhra-Pfad offen. Der Truststore von Liberica JDK enthält diese Root noch, daher sind beide Pfade offen.

Welche Systeme Sie prüfen sollten

• Eigenständige JDKs, die aus einem Archiv des Anbieters entpackt oder mit dessen Installer installiert wurden. Sie verwenden ihr eigenes cacerts.
• Container-Images, die ein JDK enthalten. In den von BellSoft getesteten Images hat ein Update des Betriebssystempakets ca-certificates das cacerts des JDK nicht verändert. Auch ein neueres Base-Image half nicht: Das getestete Liberica-Image vom 21. Oktober vertraute weiterhin allen zwölf Testhosts.
• Anwendungen mit eigenem Truststore, gesetzt über javax.net.ssl.trustStore, in der Konfiguration eines Application Servers oder innerhalb der Anwendung. Prüfen Sie, ob sie die beiden Roots enthalten.
• OpenJDK aus Distributionspaketen. Prüfen Sie, worauf cacerts verweist. Ist es mit dem System-CA-Store verknüpft (unter Arch Linux ist es ein Symlink auf /etc/ca-certificates/extracted/java-cacerts.jks), behebt das ca-certificates-Update der Distribution das Problem. Die Seite mit der Offenlegung listet die korrigierten Paketversionen auf.

So prüfen Sie Ihr JDK

Suchen Sie zuerst im Truststore nach den beiden Roots. Die Alias-Namen unterscheiden sich je nach Anbieter (Liberica JDK verwendet emsigneccrootcag3 [jdk], Temurin cn_emsign_ecc_root_ca__g3,...), suchen Sie daher nach dem Subject des Zertifikats. Es gibt mehrere weitere emSign-Roots; betroffen ist nur emSign ECC Root CA - G3. Ab JDK 9:

keytool -list -v -cacerts -storepass changeit | grep -E '^Alias name:|^Owner:' | grep -B1 -E '^Owner: CN=(emSign ECC Root CA - G3|AAA Certificate Services),'

Das keytool von Java 8 kennt die Option -cacerts nicht, und der Truststore liegt unter jre/:

keytool -list -v -keystore "$JAVA_HOME/jre/lib/security/cacerts" -storepass changeit | grep -E '^Alias name:|^Owner:' | grep -B1 -E '^Owner: CN=(emSign ECC Root CA - G3|AAA Certificate Services),'

Jeder Treffer gibt den Alias-Namen und darunter das Subject des Zertifikats aus. Notieren Sie sich die Alias-Namen: Sie brauchen sie für die Korrektur.

Testen Sie anschließend echte Verbindungen. Dieses kleine Programm verbindet sich mit allen zwölf Testhosts und läuft unter Java 8 und allen späteren Versionen:

import java.net.URI;
import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.SSLHandshakeException;
public class Check {
    public static void main(String[] args) {
        for (String level : new String[]{"dv", "ov", "ev"})
            for (String gen : new String[]{"g3b", "g3c"})
                for (String via : new String[]{"", "-aaa"}) {
                    String host = level + "-" + gen + via + "-emudhra.we-have-a-problem.com";
                    try {
                        HttpsURLConnection c = (HttpsURLConnection) URI.create("https://" + host).toURL().openConnection();
                        c.setConnectTimeout(10000);
                        c.setReadTimeout(10000);
                        c.connect();
                        c.disconnect();
                        System.out.println("TRUSTED       " + host);
                    } catch (SSLHandshakeException e) {
                        System.out.println("TLS_REJECTED  " + host);
                    } catch (Exception e) {
                        System.out.println("ERROR         " + host + " (" + e + ")");
                    }
                }
    }
}

Ab JDK 11 starten Sie es mit java Check.java. Unter Java 8 oder wenn nur eine JRE installiert ist, kompilieren Sie es zuerst mit javac Check.java (bei Bedarf auf einem Rechner mit JDK) und führen dann java Check aus. Eine Zeile TRUSTED bedeutet, dass dieses JDK ein kompromittiertes Intermediate akzeptiert. ERROR bedeutet, dass der Host nicht erreichbar war – das beweist weder das eine noch das andere. Führen Sie die Prüfung mit demselben JDK und denselben Truststore-Einstellungen wie Ihre Anwendung aus, auch innerhalb Ihrer Container.

So beheben Sie das Problem

1. Die beiden Roots entfernen (empfohlen, bis ein korrigiertes JDK erscheint)

Es sind dieselben beiden Roots, denen Linux- und macOS-Nutzer laut der Seite mit der Offenlegung das Vertrauen entziehen sollen. Führen Sie die Befehle als der Benutzer aus, dem das JDK gehört, und mit den Alias-Namen, die Sie bei der Prüfung gefunden haben. Zum Beispiel unter Liberica JDK:

keytool -delete -cacerts -storepass changeit -alias "comodoaaaca [jdk]"
keytool -delete -cacerts -storepass changeit -alias "emsigneccrootcag3 [jdk]"

Ersetzen Sie unter Java 8 -cacerts durch -keystore "$JAVA_HOME/jre/lib/security/cacerts". Enthält Ihr Truststore nur eine der beiden Roots, wie bei Temurin, löschen Sie nur diese.

Wenn Sie die JDK-Installation nicht ändern können, bearbeiten Sie eine Kopie und verweisen die JVM darauf:

cp "$JAVA_HOME/lib/security/cacerts" ./trimmed-cacerts
keytool -delete -keystore ./trimmed-cacerts -storepass changeit -alias "comodoaaaca [jdk]"
keytool -delete -keystore ./trimmed-cacerts -storepass changeit -alias "emsigneccrootcag3 [jdk]"
java -Djavax.net.ssl.trustStore=./trimmed-cacerts -Djavax.net.ssl.trustStorePassword=changeit -jar app.jar

In unseren Tests haben beide Methoden dazu geführt, dass Liberica JDK 8 und 21 alle zwölf Testhosts abgelehnt haben, während normale Websites wie sectigo.com und github.com weiterhin erreichbar waren.

Löschen Sie bei Container-Images die Roots schon beim Build, damit jedes neue Image korrigiert ist:

FROM bellsoft/liberica-runtime-container:jdk-21-musl
RUN keytool -delete -cacerts -storepass changeit -alias "comodoaaaca [jdk]" \
 && keytool -delete -cacerts -storepass changeit -alias "emsigneccrootcag3 [jdk]"

Distroless- und Non-Root-Images brauchen zwei Anpassungen: Sie haben keine Shell, verwenden Sie also die Exec-Form von RUN mit einem Befehl pro Zeile. Und sie laufen als unprivilegierter Benutzer, wechseln Sie also für die Änderung zu USER root und danach wieder zum normalen Benutzer des Images.

2. Sperrprüfung aktivieren (optional)

eMudhra hat alle acht Intermediates gesperrt. Eine JVM, die den Sperrstatus prüft, lehnt sie daher ab, ohne dass der Truststore geändert werden muss. Aktivieren Sie CRL Distribution Points und OCSP:

echo 'ocsp.enable=true' > revocation.security
java -Dcom.sun.net.ssl.checkRevocation=true \
     -Dcom.sun.security.enableCRLDP=true \
     -Djava.security.properties=revocation.security \
     -jar app.jar

In unseren Tests wurden damit alle zwölf Testhosts unter Liberica JDK 8 und 21 sowie unter Temurin 21 abgelehnt. Allerdings ändert sich dadurch die Validierung jedes Zertifikats. Die JVM führt bei der Pfadvalidierung OCSP- oder CRL-Abfragen durch, und ein Handshake kann fehlschlagen, wenn sich der Sperrstatus nicht ermitteln lässt. Testen Sie vor einer globalen Aktivierung, ob die Responder von Ihren Servern aus erreichbar sind, wie viel Latenz sie verursachen und wie sich Fehler auswirken. Nutzen Sie diese Option, wenn Sie bereits mit Sperrprüfung arbeiten, oder zusätzlich zum Entfernen der Roots.

3. Das JDK aktualisieren, sobald korrigierte Builds verfügbar sind

BellSoft hat angekündigt, Updates für Liberica JDK vorzubereiten, die diese Roots entfernen. Verfolgen Sie die Sicherheitshinweise Ihres eigenen JDK-Anbieters. Sobald das Update erscheint, prüfen Sie anhand der Release Notes, dass es die eMudhra-Zertifikate abdeckt, installieren es, bauen Ihre Container-Images neu und führen die Prüfung erneut aus. Eine neuere Versionsnummer allein ist kein Beweis.

Nach der Korrektur: Prüfen Sie, ob Sie betroffen waren

Die Schlüssel waren etwa achtzehn Monate lang rekonstruierbar. Die Korrektur schließt die Tür, verrät Ihnen aber nicht, ob jemand sie benutzt hat. Durchsuchen Sie bei Systemen, die Zugangsdaten oder sensible Daten übertragen, die Logs von TLS-Inspection, Proxys und Endpoints nach Zertifikaten, die von den acht eMudhra-Intermediates ausgestellt wurden. Finden Sie etwas Verdächtiges, tauschen Sie die betroffenen Zugangsdaten aus.

Behandeln Sie Truststores langfristig wie Abhängigkeiten: Wissen Sie, wo jeder einzelne liegt, wer ihn aktualisiert und wie schnell eine Änderung in der Produktion ankommt. Dieser Vorfall zeigt, dass ein Browser-Update nicht ausreicht, wenn Ihre Server eine eigene Kopie der Vertrauensliste verwenden.

Weiterführende Informationen

• eMudhra Intermediate CA Compromise: die Seite mit der Offenlegung, mit Testhosts und korrigierten Paketversionen
• BellSoft: Distrusting compromised eMudhra intermediates in Java