Pada 20:06 UTC, 17 Oktober, Mozilla menerima laporan, yang dimajukan oleh Program Akar Chrome, bahawa kunci persendirian bagi 8 sijil perantaraan milik pihak berkuasa sijil India eMudhra telah terjejas; laporan itu disertakan bukti kawalan ke atas kesemua 8 kunci. Pada 21:48, Mozilla memulihkan kunci-kunci itu sendiri tanpa mengetahui kaedah pelapor — menurut penjelasan Mozilla dalam insiden tersebut (Bugzilla 2083449), kesemua 8 kunci persendirian P-384 itu ialah integer kurang daripada 256, hampir kesemuanya sifar, dan boleh dipulihkan hampir serta-merta. 6 daripada 8 ialah sijil perantaraan TLS yang dipercayai oleh program akar Chrome, Mozilla, Microsoft dan Apple; 2 lagi untuk tandatangan kod dan dipercayai oleh Microsoft. Kunci-kunci itu dijana dalam satu majlis penjanaan kunci pada 30 April 2025.

Garis Masa

  • 17 Oktober: Firefox selesai menarik balik kepercayaan terhadap sijil-sijil itu melalui OneCRL pada 22:59 UTC.
  • 18 Oktober: pada 09:38 UTC eMudhra membatalkan 8 sijil tersebut (sebab caCompromise). eMudhra menyatakan tiada sijil entiti akhir dikeluarkan daripadanya, tetapi kerana sesiapa sahaja boleh mengira kunci itu, sesiapa sahaja boleh menggunakannya untuk memalsukan sijil bagi mana-mana domain.
  • 20 Oktober: Mozilla mengumumkan penarikan kepercayaan secara kecemasan terhadap akar emSign ECC Root CA - G3, untuk melindungi klien yang tidak menggunakan maklumat pembatalan atau tiada cara untuk menarik balik kepercayaan terhadap sijil perantaraan tertentu; Program Akar Chrome komited kepada pendekatan yang serupa pada hari yang sama. eMudhra menghentikan pengeluaran daripada semua sijil perantaraan di bawah akar itu dan menganggarkan kira-kira 30,000 sijil perlu dipindahkan, kira-kira 97% daripadanya dikeluarkan melalui ACME.
  • 22 Oktober: eMudhra mengumumkan bahawa lembaga pengarahnya memutuskan untuk menarik diri secara sukarela daripada perniagaan sijil SSL/TLS global.

Mengapa Pelayan Memerlukan Pembaikan Sendiri

Pelayar mempunyai mekanisme pembatalan pantas dan boleh menyekat sijil ini dengan hanya memetik suis. Program pada pelayan anda berbeza: apabila curl, wget, Python, PHP, Node, Java atau Go membuat permintaan HTTPS, kebanyakannya bergantung pada stor kepercayaan sistem atau senarai sijil yang dibundel, dan kemas kini pelayar tidak memberi sebarang kesan kepada mereka. Tulisan Cloudflare pada 20 Oktober secara khusus memberi amaran bahawa mengemas kini SDK mungkin tidak mengubah dasar pengesahan di bawahnya — semuanya bergantung pada stor kepercayaan yang akhirnya digunakan — dan jika ralat sijil muncul selepas menampal, jangan sekali-kali menghilangkannya dengan mematikan pengesahan.

Apa yang Perlu Dilakukan pada VPS

  • Ubuntu: USN-8944-1 pada 20 Oktober membuang emSign ECC Root CA - G3 daripada ca-certificates — 20260816ubuntu0.22.04.1 untuk 22.04 dan 20260816ubuntu0.24.04.1 untuk 24.04; USN-8947-1 pada 21 Oktober turut mengemas kini NSS, membuang akar itu dan "Comodo AAA Services root".
  • Debian: DSA-6572-1 membuang dua akar yang sama, 20250419+deb13u1 untuk Debian 13; untuk Debian 12 ia ialah DLA-4845-1, 20250419~deb12u2.
  • Selepas mengemas kini, ls /etc/ssl/certs | grep -i emsign_ecc_root_ca_-_g3 sepatutnya tidak memaparkan apa-apa, yang bermakna akar itu tiada lagi dalam stor kepercayaan sistem.
  • Program yang mempunyai bundel sijil sendiri perlu dikemas kini secara berasingan: certifi untuk Python tidak lagi mengandungi akar ini mulai versi 2026.10.18 (kami menyemak fail sijil yang dibundel bagi setiap keluaran). Di Linux, program Go menggunakan stor kepercayaan sistem secara lalai, jadi mengemas kini ca-certificates sudah meliputi kebanyakan kes; untuk kes yang lebih sempit apabila stor sistem tidak dikemas kini, Go 1.26.10 / 1.27.3 yang dikeluarkan pada 19 Oktober menambah senarai tolak dalam crypto/x509 (GO-2026-6809 / CVE-2026-111943), jadi bina semula program Go yang anda kompil sendiri dengan versi baharu. Imej Docker juga membawa ca-certificates sendiri: bina semula imej dan mulakan semula bekas — lihat Docker pada VPS.
  • Mulakan semula perkhidmatan yang berkaitan selepas itu; proses yang sudah berjalan tidak akan memuat semula stor kepercayaan.

Ini tidak menjejaskan secara langsung sijil kebanyakan pemilik tapak: jika anda menggunakan Let's Encrypt atau CA lain, tiada apa yang perlu diganti — lihat menyediakan SSL Let's Encrypt untuk konfigurasi. Namun ia sekali lagi menunjukkan bahawa pertahanan terhadap sijil palsu memerlukan beberapa lapisan; pemantauan CT dan rekod CAA yang dibincangkan dalam artikel kami tentang rampasan pendaftaran .gh, .sl dan .as turut terpakai di sini.