8 Intermediate CA eMudhra Bocor: Update ca-certificates Sekarang

Delapan intermediate CA certificate milik eMudhra kehilangan kerahasiaan private key, dan delapan rantai sertifikat itu menempel ke root yang dipercaya program Mozilla, Microsoft, Apple, serta Chrome. Bukti publikasinya bukan sekadar kecurigaan: pelapor bernama Wayne menandatangani satu pesan memakai private key masing-masing intermediate, lalu melaporkannya ke tim Root Program pada 17 Oktober 2026. Siapa pun yang memegang key tersebut bisa mengaku sebagai situs atau layanan mana pun.

TL;DR

• Private key delapan intermediate CA eMudhra dinyatakan bocor, dan kedelapannya rantai ke root yang dipercaya browser serta sistem operasi utama.
• Firefox dan Chrome memblokir sertifikat tersebut sejak 17 Oktober 2026, sementara perangkat Apple menyusul pada 19 Oktober 2026.
• CA sudah mencabut intermediate yang terdampak, tetapi banyak klien tidak membaca informasi revocation dan hanya berhenti percaya setelah paket CA-nya diperbarui.
• Ubuntu, Arch, Gentoo, NSS, Go, Python certifi, pip, uv, dan rustls-webpki sudah punya versi patch, sementara Debian, FreeBSD, dan Node.js masih berstatus pending.
• Pemeriksaan paling cepat: buka salah satu host uji resmi, kalau sertifikatnya masih diterima berarti trust store lo belum diperbarui.

Apa yang Sebenarnya Terjadi?

Kasus ini masuk kategori kompromi otoritas sertifikat, bukan sekadar sertifikat domain yang salah terbit. Intermediate CA adalah lapisan perantara yang menandatangani sertifikat untuk pelanggan; kalau private key-nya bocor, penyerang tidak perlu menyerang situs satu per satu, cukup menerbitkan sertifikat sendiri yang tampak sah di mata klien. Karena kedelapan intermediate itu rantai ke root yang ada di trust store mayor, dampaknya lintas sistem operasi dan lintas browser.

Yang membuat kasus ini tidak bisa dibantah adalah metode pembuktiannya. Pelapor menandatangani pesan yang sama dengan private key setiap intermediate, lalu mengirimkannya bersama sertifikat, public key, dan signature ke tim Root Program. Verifikasi bisa dilakukan sendiri dengan OpenSSL: ambil public key dari sertifikat, cocokkan dengan public key yang dikirim, lalu periksa signature pesan memakai algoritma yang dipakai, dalam contoh ini SHA-384. Kalau signature valid, berarti pemegang key memang punya private key yang seharusnya tidak dipegang siapa pun selain CA.

Rincian teknis, berkas bukti, dan daftar host uji tersedia di laman koordinasi insiden we-have-a-problem.com yang dipublikasikan 20 Oktober 2026. Halaman itu juga mencantumkan status patch per paket, yang jadi rujukan paling berguna buat admin sistem.

Siapa yang Sudah Mencabut Kepercayaan?

Tiga ekosistem besar bergerak cepat. Sertifikat sudah diblokir di Firefox dan Chrome sejak 17 Oktober 2026, dan di perangkat Apple sejak 19 Oktober 2026. Pemblokiran itu memakai mekanisme distribusi revocation masing-masing vendor, seperti OneCRL di Mozilla, CRLite di Firefox, dan CRLSets di Chrome, sehingga pengguna yang browser-nya diperbarui otomatis ikut terlindungi tanpa harus install ulang apa pun.

Masalahnya, tidak semua klien punya jalur distribusi seperti itu. Banyak bahasa pemrograman, image container, dan perangkat embedded membawa trust store sendiri yang hanya berubah saat paketnya diperbarui. Di sinilah perbedaan antara pengguna rumahan dan operator server jadi penting: browser di laptop mungkin sudah aman, sementara container yang dipakai build pipeline masih mempercayai intermediate yang sama.

CA juga sudah mencabut intermediate yang terdampak. Namun revocation hanya efektif bagi klien yang benar-benar memeriksa status pencabutan, dan banyak klien sengaja tidak melakukannya karena biaya latensi serta masalah ketersediaan OCSP. Itu sebabnya pembaruan paket CA tetap jadi langkah utama, bukan pelengkap.

Bagaimana Cara Cek Apakah Sistem Lo Masih Percaya CA Itu?

Cara paling langsung adalah mencoba membuka host uji resmi dari mesin yang mau diperiksa. Kalau koneksi berhasil tanpa peringatan sertifikat, artinya trust store di mesin itu masih menerima rantai yang sudah dicabut. Kalau gagal dengan error sertifikat, berarti klien sudah tidak mempercayainya.

curl -sS -o /dev/null https://dv-g3b-emudhra.we-have-a-problem.com/
curl -sS -o /dev/null https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

Perintah itu memakai trust store default curl. Untuk memeriksa sistem secara menyeluruh, ulangi dari dalam container, dari runner CI, dan dari bahasa yang dipakai aplikasi, karena masing-masing bisa memakai bundel berbeda. Java punya cacerts sendiri, Python memakai certifi, Go memakai root sistem atau bundel internal, dan Rust dengan rustls biasanya memakai webpki-roots.

Untuk pemeriksaan offline, laman insiden menyediakan berkas rantai sertifikat per host dalam format PEM beserta instruksi verifikasi OpenSSL. Pendekatan ini berguna kalau lo ingin memeriksa trust store tanpa akses jaringan, misalnya pada image container yang dibekukan atau perangkat yang tidak punya koneksi keluar.

Paket Mana yang Sudah Dipatch?

Status per 20 Oktober 2026 menunjukkan sebagian ekosistem sudah punya versi perbaikan, sebagian masih menunggu. Tabel berikut merangkum yang tercantum di laman insiden, dan versi yang disebut adalah versi minimum yang sudah membuang intermediate terdampak.

Paket atau runtime	Versi patch	Status
Ubuntu ca-certificates	20260816ubuntu0.22.04.1, 24.04.1, 26.04.1, 26.10.1	Tersedia
Debian ca-certificates	Belum disebut	Pending
Arch ca-certificates-mozilla	3.131.1-1	Tersedia
Gentoo ca-certificates	20260816.3.125	Tersedia
FreeBSD ca_root_nss	Belum disebut	Pending
NSS	3.131.1	Tersedia
Go	1.27.3 dan 1.26.10	Tersedia
Node.js	Belum disebut	Pending
Python certifi	2026.10.19	Tersedia
pip	26.2.2	Tersedia
uv	0.13.4	Tersedia
Rust rustls-webpki	0.103.16	Tersedia

Bundel CA milik curl juga sudah diperbarui, dan versi bundel terbaru bisa dilihat di halaman resmi curl CA bundle. Kebijakan root store Mozilla yang jadi acuan banyak distribusi dijelaskan di halaman kebijakan sertifikat Mozilla.

Untuk Ubuntu, paket ca-certificates bisa diperiksa lewat arsip resmi di Launchpad. Kebiasaan yang sehat: jangan hanya memperbarui satu paket, tapi pastikan seluruh jalur trust yang dipakai aplikasi ikut diperbarui, termasuk image dasar container yang dipakai build.

Apa Risiko Kalau Tidak Update?

Risiko utamanya penyamaran. Penyerang yang memegang private key intermediate bisa membuat sertifikat untuk domain apa pun yang masih dipercaya klien terdampak, termasuk domain internal yang tidak menghadap internet. Karena sertifikatnya terlihat sah, tidak ada peringatan yang muncul, dan trafik bisa dibaca atau diubah di tengah jalan.

Risiko kedua adalah jendela waktu yang panjang. Browser besar sudah memblokir sejak 17 dan 19 Oktober, tapi sistem yang tidak pernah memperbarui trust store bisa tetap rentan berbulan-bulan. Server lama, image container yang di-pin, dan perangkat IoT adalah kandidat terkuat untuk kategori ini.

Risiko ketiga justru muncul setelah patch: koneksi yang tadinya jalan bisa tiba-tiba gagal kalau ada layanan internal yang memakai sertifikat terbitan intermediate tersebut. Kegagalan itu benar secara keamanan, tapi tetap perlu diantisipasi supaya tidak jadi insiden baru di jam sibuk.

Apa yang Harus Dilakukan Sekarang?

Urutan yang paling aman: perbarui browser dan sistem operasi lebih dulu, lalu paket CA di server, lalu image container, lalu runtime bahasa. Setelah itu jalankan ulang pemeriksaan memakai host uji untuk memastikan hasilnya berubah sesuai harapan. Kalau ada layanan internal yang memakai sertifikat dari intermediate terdampak, terbitkan ulang sertifikatnya dari CA lain sebelum memaksa pembaruan trust store ke seluruh armada.

Untuk lingkungan build, jangan lupa memperbarui image dasar. Container yang di-pin ke digest lama akan terus membawa trust store lama, dan itu jenis utang teknis yang tidak terlihat sampai ada yang memeriksanya. Sertakan langkah verifikasi trust store di pipeline supaya kejadian serupa bisa dideteksi lebih awal.

Untuk pemakaian pribadi, cukup perbarui browser dan sistem operasi, lalu periksa ulang kalau ada aplikasi yang menolak koneksi ke situs tertentu. Kalau muncul error sertifikat di situs yang sebelumnya normal, kemungkinan besar situs itu memakai sertifikat dari rantai yang baru dicabut, dan itu bukan masalah di sisi perangkat.

Kenapa Kompromi Intermediate CA Lebih Berbahaya dari Sertifikat Biasa?

Karena cakupan penerbitannya tidak terbatas pada satu domain. Sertifikat leaf yang dicuri hanya membahayakan satu nama host, sementara intermediate CA bisa menandatangani sertifikat untuk nama apa pun yang masih dipercaya klien. Penyerang juga tidak perlu menyentuh infrastruktur korban: cukup menerbitkan sertifikat sendiri, lalu mengarahkan trafik ke server miliknya.

Efek lanjutannya adalah hilangnya jaminan integritas, bukan cuma kerahasiaan. Kalau trafik TLS bisa disadap dan dimodifikasi tanpa peringatan, penyerang bisa menyuntikkan skrip ke halaman yang diakses, memalsukan respons API, atau mencuri kredensial dari formulir. Semua itu terjadi tanpa ikon gembok yang berubah, karena secara teknis sertifikatnya memang valid.

Karena itu industri memperlakukan insiden CA sebagai masalah tingkat ekosistem, bukan masalah satu vendor. Root program bertindak cepat, browser memblokir lewat mekanisme revocation, dan proyek bahasa merilis pembaruan bundel CA. Rantai koordinasi inilah yang membuat dampak nyata biasanya lebih kecil daripada potensi teoretisnya, asalkan operator sistem ikut memperbarui bagian yang jadi tanggung jawabnya.

Bagaimana Menyiapkan Prosedur Tanggap untuk Insiden CA?

Mulai dari inventaris. Kumpulkan daftar tempat trust store berada di organisasi lo: sistem operasi server, image container, runtime bahasa, perangkat jaringan, dan aplikasi yang membawa bundel sendiri. Tanpa daftar ini, respons selalu berjalan berdasarkan ingatan, dan biasanya ada satu bagian yang terlewat.

Berikutnya, siapkan perintah verifikasi yang bisa dijalankan siapa saja. Satu skrip kecil yang membuka host uji dan melaporkan hasilnya per lingkungan jauh lebih berguna daripada instruksi panjang di dokumen. Jalankan skrip itu setelah setiap pembaruan paket, bukan hanya saat ada berita insiden.

Ketiga, tentukan urutan prioritas yang tetap. Untuk insiden CA, urutan yang masuk akal: sistem yang menghadap internet lebih dulu, lalu layanan internal yang menangani autentikasi, lalu build pipeline, lalu perangkat yang jarang diperbarui. Urutan ini perlu disepakati sebelum insiden, karena saat insiden berlangsung tidak ada waktu untuk berdebat soal prioritas.

Terakhir, siapkan jalur komunikasi ke tim aplikasi. Pembaruan trust store bisa memutus koneksi ke layanan yang memakai sertifikat dari CA terdampak, dan tim aplikasi perlu tahu bahwa kegagalan itu disengaja serta apa langkah perbaikannya. Insiden CA yang ditangani cepat tapi dikomunikasikan buruk tetap berakhir sebagai gangguan panjang.

FAQ

Apakah semua sertifikat eMudhra otomatis tidak valid?

Tidak. Yang dicabut adalah delapan intermediate CA yang private key-nya terbukti dipegang pihak lain. Sertifikat leaf yang diterbitkan lewat rantai itu ikut tidak dipercaya, tetapi sertifikat dari rantai lain milik CA yang sama belum tentu terdampak.

Apakah cukup menunggu browser diperbarui?

Untuk pemakaian desktop, umumnya cukup, karena Firefox dan Chrome sudah memblokir sejak 17 Oktober dan Apple sejak 19 Oktober. Untuk server, container, dan runtime bahasa, pembaruan browser tidak berpengaruh sama sekali karena trust store-nya terpisah.

Bagaimana kalau layanan internal masih memakai sertifikat dari CA itu?

Terbitkan ulang sertifikatnya dari CA lain sebelum memaksa pembaruan trust store. Kalau urutannya dibalik, layanan akan gagal lebih dulu dan pemulihannya jadi lebih rumit, terutama kalau sertifikat dipakai untuk komunikasi antar layanan.

Apakah pencabutan oleh CA sudah cukup?

Belum. Pencabutan hanya bekerja pada klien yang memeriksa status revocation. Banyak klien tidak melakukannya, sehingga pembaruan paket CA tetap wajib supaya intermediate tersebut dibuang dari daftar kepercayaan.