Kompromittierte eMudhra-CA-Zertifikate: Was Java-Anwender jetzt tun müssen

Was passiert ist

Am 20. Oktober 2026 wurde bekannt, dass acht Intermediate-CA-Zertifikate von eMudhra kompromittiert sind. Wie eMudhra mitteilte und Mozilla sowie das Chrome Root Program von Google bestätigten, wurden die betroffenen privaten Schlüssel fehlerhaft erzeugt, sodass sie sich aus den öffentlichen Zertifikaten ableiten lassen. Dritte können sich damit gegenüber allen Systemen, die der betroffenen Zertifikatskette vertrauen, als beliebige Websites oder Dienste ausgeben. eMudhra hat die Zertifikate widerrufen, und Apple, Google, Microsoft und Mozilla haben sie in ihren Browsern und Betriebssystemen gesperrt. Laut eMudhra war nur eines der acht Intermediate-Zertifikate jemals im Produktiveinsatz, und keines davon hat ein Endnutzerzertifikat (End-Entity-Zertifikat) ausgestellt. Auch Google fand nach eigenen Angaben in den Certificate-Transparency-Logs keine Zertifikate, die auf diesen Intermediate-Zertifikaten aufbauen. Reagieren müssen daher alle Komponenten, die Zertifikate auf Vertrauenswürdigkeit prüfen, auch Java-Laufzeitumgebungen.

Warum das für Java relevant ist

Java-Laufzeitumgebungen erhalten Widerrufsdaten nicht automatisch und prüfen standardmäßig nicht, ob Zertifikate widerrufen wurden. Die kompromittierten Intermediate-Zertifikate sind von Root-Zertifikaten abgeleitet, denen viele OpenJDK-Distributionen vertrauen. Ein ungepatchtes JDK kann daher ein gefälschtes Zertifikat akzeptieren, das mit den kompromittierten Schlüsseln signiert wurde. Da ein Großteil der Geschäfts- und Infrastruktursoftware weltweit für den Aufbau sicherer Verbindungen auf die Java-Laufzeitumgebung (JVM/JDK) angewiesen ist, muss die Korrektur im JDK selbst erfolgen. Diese Korrektur besteht aus einer Sperrliste (lib/security/blocked.certs), die sich auf zwei Wegen in eine Laufzeitumgebung einbringen lässt: über ein JDK-Update oder als Datei, die von Hand in jede installierte Laufzeitumgebung kopiert werden muss – einschließlich Kopien, die in Anwendungen, Container-Images und CI-Pipelines eingebettet sind –, gefolgt von einem Neustart. Der erste Weg läuft über den Update-Prozess, den die meisten Unternehmen mit Java-Einsatz bereits etabliert haben. Der zweite erfordert ein eigenes Verfahren, das unter Zeitdruck erst aufgesetzt werden muss. Azul hat das Problem als kritisch und zeitkritisch eingestuft und sich unmittelbar auf die Bereitstellung des ersten Wegs konzentriert.

Was Azul unternommen hat

Innerhalb von 24 Stunden nach der öffentlichen Bekanntgabe hat Azul einen dokumentierten Workaround veröffentlicht sowie aktualisierte, getestete Azul Zulu Builds of OpenJDK für Java 27, 25, 21, 17, 11, 8, 7 und 6 und Azul Prime (Azul Zing Builds of OpenJDK) für Java 25, 21, 17, 11 und 8 bereitgestellt. Diese Updates sperren die acht kompromittierten Zertifikate, und nach der Installation sind keine manuellen Änderungen am JDK erforderlich. Um die Stabilität zu maximieren, hat Azul die Korrektur als Teil eines Security-only, Stability-first Update ausgeliefert. Es baut auf dem Release des vorherigen Zyklus auf und enthält ausschließlich Sicherheitsfixes, sodass das Regressionsrisiko geringer ist.

(red/Azul)