Pada 20 Oktober 2026, terungkap ke publik bahwa kunci privat dari delapan otoritas sertifikat (CA) perantara yang dikelola eMudhra, sebuah CA asal India, dapat dipulihkan oleh siapa saja. Browser memblokir sertifikat tersebut pada hari yang sama saat masalah ini dilaporkan. Namun, banyak aplikasi Java hingga hari ini masih memercayainya, dan akan terus memercayainya sampai seseorang memperbarui JDK atau mengubah truststore-nya.

Pada 21 Oktober 2026, BellSoft menerbitkan hasil pengujian yang menunjukkan bahwa banyak runtime Java masih menerima sertifikat ini. Artikel ini merangkum temuan mereka, yang juga kami verifikasi dalam pengujian kami sendiri, serta menjelaskan mengapa Java terdampak padahal browser tidak, cara memeriksa sistem Anda, dan apa yang perlu dilakukan.

Apa yang terjadi

eMudhra membuat kunci privat untuk delapan sertifikat CA perantaranya dengan cara yang keliru, sehingga siapa pun dapat memulihkannya dari sertifikat publiknya. Hal ini sudah dimungkinkan sejak CA perantara tersebut diterbitkan pada April 2025.

Pada 17 Oktober 2026, seorang pelapor membuktikan masalah ini dengan menandatangani pesan “We have a problem here” menggunakan masing-masing dari delapan kunci tersebut dan mengirimkan tanda tangannya ke program root browser. Detailnya diumumkan ke publik pada 20 Oktober.

• Enam CA perantara menerbitkan sertifikat TLS: CA TLS DV, OV, dan EV milik eMudhra, generasi G3B dan G3C.
• Dua CA perantara menerbitkan sertifikat code signing.
• Setiap CA perantara ada dalam dua versi: ditandatangani oleh root emSign milik eMudhra, dan ditandatangani silang (cross-signed) oleh root AAA Certificate Services milik Sectigo. Di truststore JDK, rantainya berakhir di salah satu dari dua root: emSign ECC Root CA - G3 (melalui cross-sign) atau AAA Certificate Services.

Firefox dan Chrome telah memblokir CA perantara tersebut sejak 17 Oktober, Apple sejak 19 Oktober, dan Microsoft sejak 20 Oktober. eMudhra mencabut kedelapannya pada 18 dan 19 Oktober dengan alasan CA_COMPROMISE. Distribusi Linux telah merilis paket sertifikat CA yang diperbarui.

Apa dampaknya

Siapa pun yang memegang salah satu kunci ini dapat membuat sertifikat untuk hostname apa pun, misalnya bank Anda, penyedia cloud Anda, atau API gateway Anda sendiri. Klien yang memercayai rantainya akan menerima sertifikat tersebut. Jika digabungkan dengan cara untuk menyadap lalu lintas, misalnya jaringan yang telah disusupi atau record DNS yang diubah, penyerang dapat:

• membaca dan mengubah lalu lintas antara aplikasi Java dan layanan yang dipanggilnya, termasuk kata sandi, API key, dan token;
• menyamar sebagai repositori paket, server pembaruan, atau API mitra;
• melalui dua CA perantara untuk code signing, menandatangani kode yang tampak berasal dari penerbit tepercaya.

CA perantara ini tidak pernah muncul di log Certificate Transparency (CT), sehingga browser yang menerapkan CT tidak mungkin diserang melaluinya. Apakah kunci-kunci tersebut pernah digunakan terhadap klien yang tidak memeriksa CT belum diketahui. Java adalah salah satu klien tersebut.

Mengapa Java masih memercayai sertifikat ini

Mozilla, Google, Apple, dan Microsoft menerapkan pemblokiran melalui saluran mereka sendiri, seperti OneCRL, CRLite, dan CRLSets. Implementasi TLS default JDK tidak membaca satu pun di antaranya. Tiga pengaturan default membuat Java tetap rentan:

• Truststore sendiri. Kecuali aplikasi mengatur javax.net.ssl.trustStore, Java memercayai root di $JAVA_HOME/lib/security/jssecacerts jika file itu ada, dan di $JAVA_HOME/lib/security/cacerts jika tidak. cacerts bawaan vendor tidak menerima daftar blokir browser maupun pembaruan CA dari sistem operasi. File ini hanya berubah jika administrator mengeditnya atau pembaruan JDK menggantinya.
• Tanpa pemeriksaan pencabutan. Java tidak memeriksa pencabutan kecuali Anda mengaktifkannya (com.sun.net.ssl.checkRevocation bernilai false secara default), sehingga pencabutan oleh CA tidak terlihat oleh konfigurasi default.
• Tanpa Certificate Transparency. JDK tidak menerapkan CT, sehingga perlindungan yang melindungi pengguna browser tidak berlaku.

Halaman pengungkapan mencantumkan dua belas host uji, satu untuk setiap kombinasi CA perantara dan root. BellSoft mengujinya di Linux pada 21 Oktober, dan kami mengulangi pengujian tersebut pada 23 Oktober:

Runtime yang diuji	Host uji yang dipercaya
Liberica JDK 21.0.10	12 dari 12
Liberica JDK 8u504 (image container)	12 dari 12
Liberica JDK 21.0.12.1 (image container)	12 dari 12
Eclipse Temurin 25.0.4.1	6 dari 12 (hanya root eMudhra)
Eclipse Temurin 21.0.12.1 (image container, pengujian kami)	6 dari 12 (hanya root eMudhra)
Arch Linux OpenJDK 27 (penyimpanan CA sistem)	6 dari 12 (hanya root eMudhra)

Perbedaannya terletak pada root Sectigo. Mozilla sudah lebih dulu menghapus AAA Certificate Services, dan truststore Temurin serta Arch Linux dibangun dari daftar Mozilla, sehingga hanya jalur eMudhra yang terbuka. Truststore Liberica JDK masih berisi root tersebut, sehingga kedua jalur terbuka.

Sistem mana yang perlu diperiksa

• JDK mandiri yang diekstrak dari arsip vendor atau dipasang dengan installer vendor. JDK ini menggunakan cacerts miliknya sendiri.
• Image container yang menyertakan JDK. Pada image yang diuji BellSoft, memperbarui paket ca-certificates sistem operasi tidak mengubah cacerts milik JDK. Menarik base image yang lebih baru juga tidak membantu: image Liberica yang diuji, dari 21 Oktober, masih memercayai kedua belas host uji.
• Aplikasi dengan truststore sendiri, yang diatur dengan javax.net.ssl.trustStore, dalam konfigurasi application server, atau di dalam aplikasi. Periksa apakah truststore tersebut berisi kedua root itu.
• OpenJDK yang dipaketkan oleh distribusi. Periksa ke mana cacerts mengarah. Jika tertaut ke penyimpanan CA sistem (di Arch Linux, file ini adalah symlink ke /etc/ca-certificates/extracted/java-cacerts.jks), pembaruan ca-certificates dari distribusi akan memperbaikinya. Halaman pengungkapan mencantumkan versi paket yang sudah ditambal.

Cara memeriksa JDK Anda

Pertama, cari kedua root tersebut di truststore. Nama alias berbeda antar-vendor (Liberica JDK menggunakan emsigneccrootcag3 [jdk], Temurin menggunakan cn_emsign_ecc_root_ca__g3,...), jadi cari berdasarkan subject sertifikat. Ada beberapa root emSign lain; hanya emSign ECC Root CA - G3 yang terdampak. Pada JDK 9 dan yang lebih baru:

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

keytool di Java 8 tidak memiliki opsi -cacerts, dan truststore-nya berada di bawah 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),'

Setiap kecocokan menampilkan nama alias diikuti subject sertifikat. Catat nama aliasnya: Anda memerlukannya untuk perbaikan.

Kemudian, uji koneksi sungguhan. Program kecil ini terhubung ke kedua belas host uji dan berjalan di Java 8 serta setiap rilis sesudahnya:

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 + ")");
                    }
                }
    }
}

Pada JDK 11 atau yang lebih baru, jalankan dengan java Check.java. Pada Java 8, atau jika hanya JRE yang terpasang, kompilasi terlebih dahulu dengan javac Check.java (di mesin yang memiliki JDK jika perlu) lalu jalankan java Check. Baris TRUSTED berarti JDK ini menerima CA perantara yang terkompromi. ERROR berarti host tidak dapat dijangkau, yang tidak membuktikan apa pun. Jalankan pemeriksaan dengan JDK dan pengaturan truststore yang sama dengan aplikasi Anda, termasuk di dalam container Anda.

Cara memperbaikinya

1. Hapus kedua root (disarankan sampai JDK yang sudah diperbaiki tersedia)

Ini adalah dua root yang sama yang menurut halaman pengungkapan harus berhenti dipercaya oleh pengguna Linux dan macOS. Jalankan perintah sebagai pengguna pemilik JDK, dengan nama alias yang Anda temukan saat pemeriksaan. Misalnya, pada Liberica JDK:

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

Pada Java 8, ganti -cacerts dengan -keystore "$JAVA_HOME/jre/lib/security/cacerts". Jika truststore Anda hanya berisi salah satu dari kedua root, seperti truststore Temurin, hapus root itu saja.

Jika Anda tidak dapat mengubah instalasi JDK, edit salinannya dan arahkan JVM ke salinan tersebut:

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

Dalam pengujian kami, kedua metode membuat Liberica JDK 8 dan 21 menolak kedua belas host uji, sementara situs biasa seperti sectigo.com dan github.com tetap dapat terhubung.

Untuk image container, hapus root saat build agar setiap image baru sudah diperbaiki:

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]"

Image distroless dan non-root memerlukan dua perubahan: image ini tidak memiliki shell, jadi gunakan bentuk exec dari RUN dengan satu perintah per baris; image ini juga berjalan sebagai pengguna tanpa hak istimewa, jadi beralihlah ke USER root untuk pengeditan, lalu kembali ke pengguna normal image setelahnya.

2. Aktifkan pemeriksaan pencabutan (opsional)

eMudhra telah mencabut kedelapan CA perantara, sehingga JVM yang memeriksa pencabutan akan menolaknya tanpa perubahan apa pun pada truststore. Aktifkan CRL distribution point dan 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

Dalam pengujian kami, cara ini menolak kedua belas host uji pada Liberica JDK 8 dan 21 serta pada Temurin 21. Namun, cara ini mengubah cara setiap sertifikat divalidasi. JVM melakukan pencarian OCSP atau CRL selama validasi jalur, dan handshake dapat gagal jika status pencabutan tidak dapat ditentukan. Sebelum mengaktifkannya secara global, uji apakah responder dapat dijangkau dari server Anda, berapa banyak latensi yang ditambahkannya, dan bagaimana perilakunya saat terjadi kegagalan. Gunakan cara ini jika Anda sudah menjalankan pemeriksaan pencabutan, atau bersamaan dengan penghapusan root.

3. Perbarui JDK saat build yang sudah diperbaiki tersedia

BellSoft menyatakan sedang menyiapkan pembaruan Liberica JDK yang menghapus root-root ini. Pantau advisori keamanan dari vendor JDK Anda sendiri. Saat pembaruan dirilis, baca catatan rilisnya untuk memastikan bahwa pembaruan tersebut mencakup sertifikat eMudhra, pasang pembaruannya, build ulang image container Anda, lalu jalankan pemeriksaan lagi. Nomor versi yang lebih baru saja bukanlah bukti.

Setelah perbaikan: tinjau eksposur Anda

Kunci-kunci ini dapat dipulihkan selama sekitar delapan belas bulan, sehingga perbaikan ini menutup pintunya tetapi tidak memberi tahu apakah ada yang sudah memanfaatkannya. Untuk sistem yang mengirim kredensial atau data sensitif, telusuri log inspeksi TLS, proxy, dan endpoint untuk mencari sertifikat yang diterbitkan oleh delapan CA perantara eMudhra. Jika Anda menemukan sesuatu yang mencurigakan, rotasi kredensial yang terdampak.

Untuk jangka panjang, perlakukan truststore seperti dependensi: ketahui di mana masing-masing berada, siapa yang memperbaruinya, dan seberapa cepat perubahan sampai ke produksi. Insiden ini menunjukkan bahwa pembaruan browser tidak cukup jika server Anda menjalankan salinan daftar kepercayaannya sendiri.

Bacaan lebih lanjut

• eMudhra Intermediate CA Compromise: halaman pengungkapan, berisi host uji dan versi paket yang sudah ditambal
• BellSoft: Distrusting compromised eMudhra intermediates in Java