Kuncinya 4: siapa yang menentukan situs web mana yang dipercaya perangkat lunak Anda

Artikel ini telah diterjemahkan secara otomatis. Versi aslinya tersedia dalam bahasa Inggris.

Terakhir diperbarui: 25 Oktober 2026 · 18 menit baca

Kita punya masalah di sini

Pada Sabtu, 17 Oktober 2026, pukul 18.05 UTC, program sertifikat akar Chrome (Chrome Root Program) menerima laporan dari seorang peneliti keamanan yang di ruang publik hanya dikenal sebagai Wayne. Ia mengaku memegang kunci privat delapan otoritas sertifikat (certificate authority) yang dijalankan eMudhra, perusahaan tercatat di bursa yang berbasis di Bengaluru, India. Untuk membuktikannya, ia memakai masing-masing dari kedelapan kunci itu untuk menandatangani pesan pendek yang sama: “Kita punya masalah di sini – Wayne.”

Ia tidak perlu membobol apa pun. Setelah kabar itu tersebar, peneliti keamanan Scott Helme menjelaskan seperti apa wujud kunci-kunci itu. Salah satunya hanyalah angka 4. Dua lainnya 56 dan 115. Helme mengatakan ia mengungkap semuanya dari sertifikat publik masing-masing di laptopnya, dan itu memakan waktu kurang dari satu detik. Pemeriksaan independen oleh jurnalis memastikan bahwa kunci privat di balik “EM OV TLS CA – G3C” milik eMudhra adalah 4.

Kedelapannya adalah otoritas sertifikat perantara, lapisan kerja sebuah perusahaan sertifikat yang menandatangani kredensial untuk pihak lain. Enam di antaranya berwenang menerbitkan sertifikat untuk situs web, dan keenamnya dipercaya oleh program sertifikat akar Chrome, Mozilla, Microsoft, dan Apple. Dua lainnya untuk penandatanganan kode (code signing), yaitu sertifikat yang dipakai pembuat perangkat lunak untuk menandatangani program mereka, dan dipercaya oleh Microsoft. Kunci-kunci itu dibuat secara keliru, sehingga siapa pun yang tahu harus mencari di mana dapat menghitungnya dari sertifikat itu sendiri, yang memang sengaja dibuat terbuka untuk umum. Hal itu sudah mungkin dilakukan sejak sertifikat-sertifikat itu dibuat pada April 2025.

Pukul 19.45 UTC, satu jam empat puluh menit setelah laporan masuk, Chrome sudah memastikan temuan itu dan mengirimkan pemblokiran kepada penggunanya. Tak seorang pun perlu memasang pembaruan atau memulai ulang peramban.

Kecepatan itu penting mengingat apa yang bisa dilakukan kunci semacam itu. Siapa pun yang memegang salah satu dari enam kunci situs web itu dan mampu menyadap koneksi seseorang dapat menyodorkan sertifikat palsu untuk bank, layanan surel, atau situs lain mana pun, tak peduli perusahaan sertifikat mana yang dipakai situs aslinya, dan perangkat lunak yang memercayai rantai eMudhra akan menerimanya. Ada dua perlindungan utama yang menghadang: sistem pencatatan publik bernama Certificate Transparency, yang diwajibkan oleh sebagian perangkat lunak, sementara banyak yang lain tidak, serta pemblokiran apa pun yang diterima masing-masing perangkat lunak tepat waktu.

Berhasil tidaknya sebuah sertifikat palsu bergantung pada keputusan-keputusan yang biasanya tak terlihat: siapa yang menjamin sebuah situs web, siapa yang memutuskan bahwa penjamin itu layak dipercaya, dan seberapa cepat kepercayaan itu bisa ditarik ketika penjamin itu ternyata rusak.

Apa yang dijamin sebuah sertifikat

Sertifikat situs web adalah dokumen kecil bertanda tangan yang mengikat sebuah nama, misalnya alamat web sebuah bank, pada sebuah kunci publik. Kunci publik selalu berpasangan dengan kunci privat. Kunci privat dirahasiakan dan menghasilkan tanda tangan digital; kunci publik memungkinkan siapa pun memeriksa bahwa sebuah tanda tangan berasal dari pasangannya. Ketika peramban Anda tersambung ke sebuah situs, situs itu membuktikan bahwa ia memegang kunci privat yang cocok dengan kunci publik dalam sertifikatnya. Sertifikat itu sendiri menyatakan bahwa kunci publik ini milik nama ini, dan sebuah otoritas sertifikat, atau CA, menjamin pernyataan itu dengan menandatanganinya.

Sebelum menandatangani sertifikat situs web, CA wajib memeriksa bahwa pemohon menguasai domain tersebut. Salah satu metode yang disetujui adalah memberi pemohon sebuah nilai acak, lalu mencarinya di catatan DNS domain itu, buku alamat publik internet, tempat yang hanya bisa diisi oleh pihak yang menguasai domain tersebut. CA juga boleh memastikan bahwa pemohon benar-benar memegang kunci privat yang ingin disertifikasinya, dengan uji teknis yang disebut proof of possession (bukti kepemilikan), meski standar yang mendasarinya juga membolehkan CA berpegang pada pengakuan pemohon saja.

Tidak ada peramban yang sanggup memeriksa sendiri setiap CA di dunia, sehingga kepercayaan didelegasikan dalam sebuah rantai. Di puncaknya duduk sertifikat akar (root), yang disimpan dalam daftar bernama penyimpanan akar tepercaya (trust store) yang ikut terpasang di sistem operasi atau peramban Anda. Sertifikat akar memberi wewenang kepada CA perantara, dan CA perantara menerbitkan sertifikat yang dipakai situs web. Ketika perangkat lunak Anda melihat sertifikat sebuah situs, ia menelusuri tanda tangan ke atas, dari situs ke CA perantara lalu ke sertifikat akar, dan menerima situs itu hanya jika rantainya berakhir pada sertifikat akar yang ada di penyimpanannya, setiap tanda tangan valid, sertifikat masih dalam masa berlaku dan mencakup nama yang dikunjungi, serta tidak ada aturan lain perangkat lunak itu yang melarangnya.

Program sertifikat akar, yang dijalankan vendor sistem operasi dan peramban seperti Apple, Google, Microsoft, dan Mozilla, menyeleksi otoritas sertifikat dan memutuskan sertifikat akar mana yang masuk ke penyimpanan. Itulah sebabnya kunci privat sebuah CA perantara begitu berharga. Kecuali dibatasi pada nama-nama tertentu, dan CA perantara eMudhra tidak dibatasi demikian, CA perantara dapat menandatangani sertifikat untuk domain apa pun, dan sertifikat itu terverifikasi ke atas hingga sertifikat akar yang tepercaya. Kunci milik sertifikat akar itu sendiri bisa tetap terkunci rapat; kunci CA perantaralah yang mengerjakan penandatanganan sehari-hari, dan jika kunci itu bocor, restu sertifikat akar ikut bocor bersamanya.

Semua ini tidak memberi tahu Anda apakah sebuah situs web jujur, meski ikon gembok di peramban luas dianggap bermakna demikian. Ketika Google meneliti persoalan ini pada 2021, hanya 11 persen peserta yang memahami dengan benar arti gembok itu, dan hampir semua situs phishing memakai HTTPS sehingga ikut menampilkannya. Pada 2023 Google mengumumkan bahwa Chrome akan mengganti gembok itu dengan ikon lain. Sertifikat dasar hanya menyatakan bahwa koneksi itu menuju siapa pun yang memegang kunci untuk nama tersebut. Sebagian sertifikat juga menyebut organisasi di balik situs itu; tak satu pun menjamin niatnya.

Ada satu lapisan lagi. Certificate Transparency, yang dirumuskan para insinyur Google pada 2013, memasukkan sertifikat ke dalam log publik tempat siapa pun dapat mengaudit apa saja yang telah diterbitkan setiap CA. Para perancangnya bermaksud agar klien pada akhirnya menolak sertifikat apa pun yang belum dicatat, sehingga sertifikat yang dijauhkan dari log, entah diterbitkan oleh CA atau oleh pencuri yang memegang kunci CA, akan ditolak. Chrome melakukannya secara bawaan untuk setiap koneksi yang bergantung pada penyimpanan akarnya.

Peringatan yang tak digubris

Aturan pembuatan kunci CA sangat ketat. Untuk sertifikat akar dan kunci CA perantara tertentu, Baseline Requirements industri ini, buku aturan yang disusun bersama oleh program sertifikat akar peramban dan para CA, menyatakan bahwa CA harus mengikuti skrip pembuatan kunci tertulis dan menghadirkan auditor berkualifikasi untuk menyaksikan seremoninya atau merekam seluruhnya dalam video. Setiap kunci CA harus dibuat oleh beberapa orang bersama-sama, dan tak seorang pun di antara mereka memegang seluruh pengetahuan yang dibutuhkan untuk melakukannya sendirian.

Pada 30 April 2025 eMudhra membuat sekelompok 24 CA perantara. Semuanya terbagi dalam tiga seri berlabel A, B, dan C, dengan dua jenis kunci, RSA dan jenis kurva eliptik bernama P-384, serta empat kegunaan. Kedelapan kunci yang rusak itu adalah seluruh kunci P-384 dalam seri B dan C. Kedelapannya bilangan bulat yang lebih kecil dari 256. Jika ditulis lengkap, masing-masing berupa deretan panjang angka nol dengan sesuatu di bita terakhir.

Mengapa kunci ini bisa ditebak

Kunci privat pada kurva P-384 hanyalah sebuah bilangan, yang dipilih secara acak antara 1 dan suatu batas tetap yang panjangnya sendiri 384 bit. Kunci publik dihitung dari kunci privat melalui perhitungan yang mudah dijalankan ke depan dan, untuk bilangan yang benar-benar acak, mustahil dijalankan mundur. Kunci publik itu tercetak di sertifikat. Angka 4 adalah kunci privat yang sepenuhnya sah; angka itu juga salah satu angka pertama yang akan dicoba siapa pun. Mozilla menunjukkan bahwa kunci sekecil ini dapat diungkap nyaris seketika: hitung kunci publik untuk 1, 2, 3, dan seterusnya hingga 256, lalu bandingkan masing-masing dengan yang ada di sertifikat. Ketika keduanya cocok, kunci privatnya adalah angka awal perhitungan itu. Kunci yang benar-benar acak tidak menyisakan daftar pendek semacam itu. Seperti kata Scott Helme, rentang itu memuat kira-kira 10 pangkat 115 kemungkinan, “jadi tidak akan ada yang pernah menelusurinya.” Dennis Jackson dari Mozilla juga menyerahkan tugas itu kepada agen AI yang dijalankan secara lokal. Agen-agen itu mengungkap kuncinya pada percobaan pertama, hanya dengan prompt sederhana.

Bagaimana sebuah seremoni pembuatan kunci bisa menghasilkan angka sekecil itu? Penjelasan awal eMudhra, yang diunggah pada 19 Oktober, adalah bahwa skrip yang dipakainya hari itu cacat. Menurut eMudhra, perusahaan telah menyetujui perubahan satu kali atas prosedur biasa untuk menguji ekspor kunci, sebuah kesalahan pengodean membuat perangkat keras menciptakan pasangan kunci kedua yang lebih lemah di samping pasangan yang semestinya, dan kunci-kunci lemah itu kemudian keliru dipakai untuk mengajukan sertifikat karena labelnya tampak mirip. eMudhra mengatakan kunci-kunci itu dibuat di dalam modul keamanan perangkat keras (hardware security module) buatan Utimaco, perangkat tahan bongkar yang dimaksudkan untuk menghasilkan dan menjaga kunci CA.

eMudhra menyebut penjelasan itu sementara, dan penjelasan itu membiarkan teka-teki utamanya tetap terbuka. Seorang komentator di laporan bug publik Mozilla mencatat: kalau bukan kunci-kunci itu dibuat di luar perangkat keras yang aman lalu dimuat ke dalamnya, yang melanggar kebijakan, berarti perangkat keras itu entah bagaimana bisa dikonfigurasi untuk membuat sendiri kunci yang cacat. Peserta lain, di milis publik Mozilla, menduga tanpa konfirmasi bahwa perangkat lunak telah salah mengira sebuah berkas kecil yang menunjuk ke kunci asli di dalam perangkat keras sebagai kunci itu sendiri. Mozilla, yang berusaha jauh lebih keras, tidak berhasil mengungkap kunci P-384 seri A dari kelompok yang sama. Mozilla mengirimkan pertanyaan kepada eMudhra pada 20 Oktober dengan tenggat 24 jam; hingga 23 Oktober belum ada jawaban yang diterimanya, dan belum ada penjelasan tentang bagaimana kunci-kunci lemah itu bisa muncul.

Yang terdokumentasi adalah bahwa masalah itu sudah menampakkan diri lebih dari setahun sebelumnya. Pada Juni 2025 sebuah layanan pemantauan publik menunjukkan eMudhra menyajikan enam daftar pencabutan sertifikat dengan tanda tangan tidak valid untuk CA perantara yang sama. Daftar pencabutan, atau CRL, adalah daftar bertanda tangan berisi sertifikat yang telah dibatalkan sebuah CA, dan tanda tangannya harus terverifikasi dengan kunci publik dalam sertifikat CA tersebut. Laporan eMudhra saat itu menyebutkan bahwa Sectigo, perusahaan sertifikat lain, pertama kali memperingatkannya lewat surel pada 3 Juni 2025, dan pesan itu dikarantina oleh filter internal sehingga tidak terbaca. Daftar yang bermasalah itu diganti pada 6 Juni.

Pada Oktober 2026 eMudhra menjelaskan apa perbaikan itu sebenarnya. Daftar-daftar itu awalnya ditandatangani dengan kunci asli yang benar-benar acak; karena sertifikat-sertifikatnya memuat bagian publik dari kunci-kunci lemah, tanda tangan itu gagal, dan perusahaan itu menandatangani ulang daftar tersebut dengan kunci yang cacat. Jadi, pada Juni 2025, eMudhra sudah memegang bukti bahwa sertifikatnya tidak cocok dengan kunci yang dikiranya sedang dipakai, dan ia memperbaiki daftar-daftar itu.

Program sertifikat akar Chrome bertanya mengapa eMudhra sekadar menandatangani ulang daftar itu alih-alih menghentikan operasi, menyelidiki mengapa ada dua pasangan kunci untuk CA-CA ini, dan mencabut sertifikatnya. eMudhra menyatakan bahwa sertifikat akar dan CA penerbitnya telah menjalani audit independen dua tahun berturut-turut. Pada 14 Oktober 2026, tiga hari sebelum laporan Wayne, perusahaan itu menerbitkan daftar pencabutan untuk sertifikat akar lain, emSign Root TLS CA – G1, yang tanda tangannya juga tidak terverifikasi.

Dua jenis sakelar pemutus

Langkah pertama Chrome cepat karena sasarannya kunci. Chrome menyimpan daftar blokir bernama CRLSet, yang dikirim Google ke peramban di latar belakang. Pembaruan yang dirilisnya pukul 19.45 UTC memblokir sidik jari kunci publik keenam CA perantara itu. Karena yang disebut dalam pemblokiran adalah kunci, pemblokiran itu mencakup setiap sertifikat yang memakai kunci-kunci tersebut, termasuk yang mungkin dibuat pemalsu di kemudian hari. Mozilla memblokir sertifikat-sertifikat itu di Firefox lewat daftarnya sendiri, OneCRL, dan rampung pukul 22.59 UTC. OneCRL bekerja tanpa pengguna perlu memperbarui, bahkan tanpa perlu memulai ulang Firefox.

Daftar yang dikirim di latar belakang hanya melindungi perangkat lunak yang menerimanya. Pada 20 Oktober Mozilla merilis pembaruan Firefox bagi pengguna yang konfigurasinya membuat daftar blokir itu tidak sampai, dan kemudian perbaikan untuk sebagian profil Firefox for Android yang tidak menerapkannya. Google mulai mengirimkan pemblokiran serupa ke perangkat Android melalui Google Play Services sekitar pukul 22.00 UTC pada Senin, 19 Oktober, dan keesokan harinya menyatakan bahwa sebagian besar perangkat sudah menerimanya. Microsoft dan Apple menyusul dalam hitungan hari, meski laporan yang terbit berbeda soal tanggal pasti tindakan Apple.

Otoritas sertifikat juga bergerak. eMudhra menandai kedelapan sertifikat itu sebagai dicabut paling lambat pukul 09.38 UTC pada 18 Oktober, dengan alasan CA compromise (kunci CA tidak lagi aman). Sectigo, yang telah menandatangani silang CA-CA perantara itu, rampung mencabut sertifikat tanda tangan silangnya pada 19 Oktober. Chrome juga mengatur agar log Certificate Transparency menolak setiap sertifikat yang rantainya berujung pada CA yang kuncinya tidak lagi aman, sehingga sertifikat palsu tak bisa lagi mengumpulkan entri log yang dituntut perangkat lunak pemeriksa CT.

Alat yang lebih berat adalah mencopot sertifikat akar yang memberi wewenang kepada CA perantara itu. Pada 20 Oktober, dengan catatan bahwa beberapa orang saat itu sudah mengungkap kunci-kunci itu secara independen, Mozilla memutuskan pencopotan darurat emSign ECC Root CA – G3, sertifikat akar eMudhra di atas CA perantara yang rusak itu, dari penyimpanan akar tepercayanya. Firefox tidak membutuhkannya; OneCRL sudah melindungi Firefox. Langkah itu ditujukan bagi semua pihak lain yang memakai daftar sertifikat akar Mozilla atau daftar turunannya tanpa OneCRL. Mozilla memperingatkan bahwa perubahan itu akan membuat sebagian server tak dapat dijangkau oleh para pengguna tersebut sampai server-server itu pindah ke rantai sertifikat baru.

Chrome mencopot sertifikat akar yang sama dari penyimpanannya. Google memperkirakan perubahan itu akan menjangkau semua perangkat yang bergantung pada Chrome Root Store pada Selasa pagi, 27 Oktober 2026, waktu Pasifik, dan lebih cepat pada versi uji Canary dan Beta. Google terus terang menyatakan bahwa sebagian sertifikat sah yang berujung pada sertifikat akar itu akan berhenti berfungsi di Chrome akibatnya.

Kedua sakelar itu berbeda dalam hal apa yang ditangkap dan siapa yang dirugikan. Pencopotan sertifikat akar memutus setiap jalur yang melewati sertifikat akar itu, termasuk jalur milik situs web yang jujur, tetapi luput menangkap jalur yang melewati sertifikat akar lain, dan CA perantara eMudhra punya jalur lain. Sectigo telah menyertifikasi silang CA-CA itu, menautkan kunci yang sama ke sertifikat akar bernama AAA Certificate Services, yang diterbitkan dengan nama Comodo. Chrome sudah membuang sertifikat akar itu pada April 2025, tetapi sebagian sistem masih memercayainya: Ubuntu mencopot emSign ECC Root CA – G3 dari semua rilisnya yang masih didukung, sekaligus mencopot sertifikat akar Comodo dari rilis-rilis lama yang masih membawanya. Pemblokiran yang dikaitkan langsung pada CA perantara itu menangkap semua rute sekaligus. Bahasa pemrograman Go menempuh cara itu: mulai versi yang dirilis pada 19 Oktober, pemeriksa sertifikat Go menyaring setiap rantai yang memuat salah satu CA perantara yang kuncinya tidak lagi aman, ke sertifikat akar mana pun rantai itu berujung.

Pembaruan untuk semua yang lain

Pada 18 Oktober Mozilla menulis di laporan bug publiknya bahwa ia mengkhawatirkan ekosistem yang lebih luas, karena banyak perangkat endpoint tidak punya cara efektif untuk menerima informasi pencabutan. Peramban punya daftar yang dikirim di latar belakang. Banyak perangkat lunak lain yang membuat koneksi aman tidak punya apa pun yang serupa.

Situs pelacakan insiden, halaman publik yang dibuat Dennis Jackson dari Mozilla, merinci siapa saja yang terpapar. Aplikasi dan pustaka perangkat lunak yang membawa bundel sertifikat akar tepercayanya sendiri membutuhkan pembaruan perangkat lunak. Begitu pula aplikasi yang dibangun di atas Electron, kerangka kerja di balik program desktop seperti Slack dan Discord, yang baru mendapat perbaikan Electron ketika dibangun ulang di atas rilis yang sudah ditambal.

Sebagian celah ada di berkas kepercayaan milik sistem operasi sendiri. Per 22 Oktober, situs insiden itu menyebutkan bahwa macOS memblokir CA perantara yang kuncinya tidak lagi aman, tetapi perangkat baris perintah bawaannya, termasuk curl, git, dan python3, memeriksa sertifikat terhadap berkas terpisah tanpa mengecek status pencabutan, dan berkas itu belum diperbarui. Di Ubuntu, penyimpanan akar tepercaya Java memerlukan tindakan manual setelah pembaruan sistem karena masalah sinkronisasi yang hingga 22 Oktober belum diselesaikan Canonical, dan peramban yang dipasang sebagai paket snap sama sekali tidak memakai penyimpanan sistem.

Celah lain ada di pustaka yang membawa daftarnya sendiri. Go merilis perbaikannya sebagai rilis keamanan 1.27.3 dan 1.26.10, dengan nomor CVE-2026-111943. Bundel certifi milik Python, yang banyak dipakai, menghapus keempat sertifikat akar emSign pada 18 Oktober, lalu memulihkan tiga yang tidak terdampak dalam rilis bertanda 2026.10.19; sebuah rilis otomatis pada 23 Oktober kembali membuang dua dari ketiganya. Dan sebagian produk hanya bisa diperbaiki oleh pembuatnya: tim keamanan Talos milik Cisco secara khusus menyebut virtual private network sebagai produk yang kemungkinan perlu diperbarui.

Di bawah semua itu ada Certificate Transparency. Sebagian besar peramban menegakkannya, tetapi banyak klien nonperamban, termasuk curl, tidak. Sertifikat palsu yang dibuat dengan salah satu kunci eMudhra dan tidak pernah dicatat akan ditolak Chrome, tetapi bisa diterima klien-klien tersebut, selama mereka masih memercayai rantai eMudhra dan tidak ada hal lain yang menghentikannya, misalnya aplikasi yang hanya menerima sertifikat server miliknya sendiri yang sudah dikenal.

Ada argumen kuat bahwa sistem ini berhasil. Tidak ada sertifikat situs web yang berujung pada keenam CA perantara itu yang tercatat di Certificate Transparency sebelum pemblokiran Chrome pada 17 Oktober, sehingga antara pembuatan kunci pada April 2025 dan pemblokiran itu, tidak mungkin ada sertifikat palsu dari kunci-kunci tersebut yang dipakai terhadap klien yang menegakkan CT. Talos menyatakan belum melihat penggunaan berbahaya di dunia nyata per 21 Oktober, pukul 14.00 UTC. eMudhra mengatakan hanya satu CA perantara terdampak yang pernah dipakai dalam produksi, dan tidak satu pun pernah menerbitkan sertifikat untuk situs web atau pembuat perangkat lunak.

Bagi perangkat lunak yang menegakkan CT sepanjang waktu, argumen itu benar, dan perlindungannya datang dari aturan yang sudah lama berlaku, bukan dari keadaan darurat akhir pekan itu. Jangkauannya lebih sempit daripada yang tersirat dalam frasa “sistem ini berhasil”. Firefox for Android baru menegakkan Certificate Transparency mulai versi 145, yang pertama kali ditawarkan kepada pengguna pada 11 November 2025. Aplikasi Android baru bisa memakai pemeriksaan CT bawaan mulai Android 16, dan baru mendapatkannya secara bawaan jika dibangun untuk Android 17.

Keadaan darurat itu juga penting karena apa yang datang sesudahnya. Pemberitahuan pertama Mozilla kepada para pengelola penyimpanan akar tepercaya di hilir sengaja tidak menyebutkan bahwa kunci-kunci itu bisa diungkap siapa saja. Pada 20 Oktober hal itu nyaris tak berarti lagi: beberapa orang sudah mengungkap kunci-kunci itu secara independen, dan Helme sudah memublikasikan kedelapan nilainya. Begitu kunci-kunci itu praktis menjadi milik publik, pemblokiran dan penolakan oleh log CT itulah yang menjadi penghalang antara kunci-kunci itu dan pemalsuan baru apa pun. Hingga 24 Oktober, tidak ada informasi yang dipublikasikan yang menunjukkan apakah penyerang telah memakai kunci cacat itu terhadap klien non-CT antara April 2025 dan Oktober 2026.

Siapa yang memegang sakelar

Keputusan tentang sertifikat akar mana yang dipercaya peramban dan sistem operasi berada di tangan program sertifikat akar, dan aturan program-program itu memberi pemiliknya ruang gerak yang luas. Kebijakan Chrome menyatakan bahwa Google memasukkan atau mencopot sertifikat “atas diskresinya sendiri”, dan bahwa setiap sertifikat yang dimasukkan harus memberi nilai bagi pengguna yang melampaui risiko mempertahankannya. Kebijakan Mozilla menyatakan bahwa Mozilla dapat menonaktifkan atau mencopot sertifikat atas diskresinya sendiri, kapan saja dan dengan alasan apa pun. Mozilla juga menyatakan tidak memungut biaya untuk pencantuman.

Diskresi itu telah digunakan dengan cara yang berbeda-beda. Pada 2014, setelah National Informatics Centre India menerbitkan sertifikat tanpa izin untuk sejumlah domain Google, Chrome tidak membuang sertifikat akar India CCA di atasnya. Chrome membatasi sertifikat akar itu pada daftar domain India. Tiga tahun sebelumnya, tanggapan terhadap sebuah otoritas Belanda bersifat total: pada 3 September 2011 Google memutuskan untuk menolak semua otoritas sertifikat yang dioperasikan DigiNotar, dan tujuh belas hari kemudian sebuah pengadilan Belanda menyatakan perusahaan itu pailit.

DigiNotar, 2011

Pembobolan DigiNotar terungkap ke publik lewat seorang pengguna biasa. Pada 28 Agustus 2011 seorang pelanggan ParsOnline, penyedia internet di Iran, mengunggah tulisan di forum dukungan Google tentang peringatan sertifikat yang ditampilkan Chrome kepadanya. Sertifikat itu mengaku sebagai milik Google, dan berasal dari DigiNotar, yang sistemnya telah dibobol. Penyelidik dari perusahaan keamanan Fox-IT, yang bekerja untuk pemerintah Belanda, belakangan menemukan bahwa sebuah sertifikat palsu yang mencakup alamat google.com telah dipakai dalam serangan besar terhadap sekitar 300.000 pengguna, hampir semuanya di Iran, yang lalu lintas Google-nya kemungkinan besar disadap atau dialihkan. Mereka menurunkan perkiraan itu dari 298.140 alamat internet berbeda yang memeriksa status sertifikat palsu itu, dan menyebutnya perkiraan yang sangat kasar. Pada 3 September pemerintah Belanda secara terbuka mencabut kepercayaannya kepada DigiNotar. Hingga akhir Oktober 2026 belum ada laporan serangan yang memakai kunci eMudhra. DigiNotar memperlihatkan apa yang bisa dilakukan kuasa penandatanganan sebuah CA di tangan orang yang mau menggunakannya.

Pencantuman dalam penyimpanan akar Chrome, tulis Google, menuntut pemilik CA untuk terus-menerus menunjukkan kecakapan teknis dan ketelitian operasional yang dibutuhkan untuk melindungi pengguna Chrome, dan Google menyatakan sedang “menyelidiki dengan saksama” apakah sertifikat CA eMudhra yang tersisa layak dipertahankan. Pada 23 Oktober eMudhra menyampaikan di laporan bug publik itu bahwa sorotan media sosial yang intens serta analisis oleh investor dan pelanggan telah membuat analisis yang berarti atas peristiwa itu “nyaris mustahil.” Chrome membalas pada hari yang sama bahwa hal itu bukan alasan, dan bahwa eMudhra tetap punya kewajiban kepada “miliaran” orang yang mengandalkan sistem itu dan telah terpapar oleh kesalahannya.

Dewan direksi eMudhra sudah memutuskan, pada 22 Oktober, untuk keluar dari bisnis sertifikat SSL/TLS global. Perusahaan itu menyatakan bahwa bisnis tersebut hanya bagian yang sangat kecil dari operasinya.

Perusahaan-perusahaan yang sama juga menyusun aturan bersama dengan para CA di sebuah badan bernama CA/Browser Forum. Dalam pemungutan suara yang ditutup pada 11 April 2025, sembilan belas hari sebelum eMudhra membuat kunci-kunci cacat itu, Apple, Google, Microsoft, dan Mozilla semuanya memilih untuk memperpendek masa berlaku sertifikat situs web, dan 25 penerbit sertifikat, termasuk eMudhra, juga memilih setuju. Argumen usulan itu adalah bahwa pencabutan tidak cukup melindungi orang dalam skala internet, sementara kedaluwarsa melindungi. “Masa berlaku sertifikat, beserta penegakannya oleh pihak yang mengandalkannya, luar biasa andal,” bunyi usulan itu. Berdasarkan aturan yang berlaku pada Oktober 2026, sertifikat situs web yang diterbitkan mulai 15 Maret 2026 paling lama berlaku 200 hari; mulai 15 Maret 2027, 100 hari; dan mulai 15 Maret 2029, 47 hari.

Batas-batas itu berlaku untuk sertifikat yang dipakai situs web, berdasarkan tanggal penerbitannya. Teks aturan itu tidak membatasi masa berlaku sertifikat CA yang menjadi pusat insiden ini, sehingga masa berlaku yang lebih pendek tidak akan membuat CA perantara eMudhra kedaluwarsa. Pencabutan pun belum hilang. Let’s Encrypt, otoritas sertifikat gratis, menutup layanan OCSP-nya, yang memungkinkan peramban menanyakan sertifikat satu per satu, pada Agustus 2025, karena setiap kueri memberi tahu CA situs mana yang sedang dikunjungi dari alamat internet mana. Pemblokiran darurat 17 Oktober pada dasarnya adalah daftar pencabutan yang dikurasi dan dikirim sendiri oleh para pembuat peramban.

Pengaturan ini menaruh kekuasaan yang sangat besar di segelintir tangan swasta, sebagian besar di antaranya Amerika. Yang diperlihatkan kasus eMudhra adalah bagaimana kekuasaan itu dijalankan: dalam laporan bug terbuka tempat siapa pun dapat membaca pertanyaan, tenggat, dan jawabannya, dengan alasan-alasan yang dipublikasikan oleh perusahaan yang melakukan pencopotan.

Sertifikat yang harus pindah

Mencopot sertifikat akar cepat diumumkan dan lambat dicerna. Per 21 Oktober, Chrome menghitung sekitar 30.800 prasertifikat yang belum kedaluwarsa dan berujung pada emSign ECC Root CA – G3. Prasertifikat adalah salinan sertifikat yang diserahkan ke log transparansi sebelum diterbitkan, sehingga angka itu adalah hitungan sertifikat yang tercatat, bukan situs web yang masih memakainya. Dari jumlah itu, 30.791, atau 99,9 persen, berasal dari dua CA perantara milik InCommon, layanan sertifikat yang dijalankan Internet2, organisasi jaringan di Amerika Serikat. Kedua CA perantara itu tidak termasuk delapan yang rusak; keduanya hanya tergantung pada sertifikat akar yang sedang dicopot. eMudhra memperkirakan sekitar 30.000 sertifikat perlu dipindahkan, hampir semuanya diterbitkan melalui ACME, protokol yang memungkinkan server meminta dan memperpanjang sertifikat secara otomatis. eMudhra berhenti menerbitkan di bawah sertifikat akar G3 pada 20 Oktober.

Otomatisasi tidak menyelesaikan persoalan ini dengan sendirinya. Klien ACME standar hanya mengganti sertifikat ketika tanggal perpanjangannya tiba, kecuali klien itu mendukung ekstensi yang lebih baru yang memungkinkan CA meminta perpanjangan lebih awal, atau ada orang yang turun tangan secara manual. Pada 21 Oktober Chrome menunjukkan bahwa pindah dari hierarki kurva eliptik eMudhra ke hierarki RSA-nya mungkin juga berarti harus mengubah pengaturan klien.

Sertifikat InCommon datang melalui CertiNext, pemasok yang perusahaan induknya adalah eMudhra. Pada 22 Oktober InCommon memberi tahu pelanggannya bahwa banyak dari mereka telah menghabiskan sepekan untuk menangani galat sertifikat dan menyusun rencana di seputar perubahan di luar kendali mereka, setelah migrasi yang berhasil tetapi melelahkan sepanjang musim semi dan musim panas. Sarannya pagi itu adalah menerbitkan ulang sertifikat yang terdampak sebagai RSA sampai penerbitan kurva eliptik dipulihkan.

Pada 20 Oktober eMudhra menyatakan bahwa satu-satunya alternatif bagi pelanggan G3-nya adalah CA perantara yang berujung pada sertifikat akar RSA-nya, emSign Root CA – G1. Pada hari yang sama Mozilla menyatakan bahwa saat itu ia tidak mencabut kepercayaan terhadap G1. G1 termasuk sertifikat eMudhra tersisa yang, menurut pernyataan Chrome pada 20 Oktober, sedang diselidikinya dengan saksama; hingga 24 Oktober Chrome belum mengumumkan keputusan apa pun. Pada 21 Oktober Chrome meminta eMudhra memastikan apakah pelanggan dipindahkan ke G1, ke hierarki perusahaan lain, atau ke keduanya.

Pembaruan InCommon pada malam 22 Oktober membereskan masalah yang mendesak. Sertifikat kurva eliptik kembali diterbitkan, kini berujung pada sertifikat akar G1, dan klien yang ada dapat memperpanjang tanpa mengubah pengaturan apa pun. Pembaruan yang sama menyebutkan bahwa eMudhra akan berhenti menerbitkan dari CA perantara mana pun yang berujung pada sertifikat akar publiknya dalam 30 hari, pada tanggal yang akan dipastikan CertiNext, dan bahwa InCommon sedang menyiapkan jalur pengganti. Bagi pelanggan yang sudah menuntaskan satu migrasi melelahkan pada musim semi dan musim panas, pencopotan satu sertifikat akar telah memicu migrasi berikutnya.

Artikel terkait

• Seberapa jauh daftar sanksi AS menjangkau sebuah mahkamah di Den Haag
• Apa selanjutnya bagi Bitcoin?
• Bagaimana AI sebenarnya bekerja: apa yang diketahui para pengembang tetapi luput dari judul berita

Bacaan lanjutan

Sebagai Associate Amazon, Eikleaf memperoleh penghasilan dari pembelian yang memenuhi syarat. Tautan buku di bawah ini adalah tautan afiliasi: jika Anda membeli melaluinya, kami mungkin menerima komisi kecil tanpa biaya tambahan bagi Anda.

Video rekomendasi

Penafian AI Generatif

Sebagian konten halaman ini dihasilkan dan/atau disunting dengan bantuan AI Generatif.

Media

HTTPS dan gembok di bilah alamat situs web – Wikimedia Commons (Foto: Santeri Viinamäki, CC BY-SA 4.0)

Modul keamanan perangkat keras nCipher nShield F3 – Wikimedia Commons (Foto: Alexander Klink, CC BY 3.0)

Kantor pusat Googleplex – Wikimedia Commons (Foto: Asoundd, CC BY-SA 4.0)

Sumber dan Referensi Utama

Mozilla Bugzilla. “Bug 2083449: eMudhra: Private key compromise of Intermediate Certificates.” Opened 18 October 2026, comments to 23 October 2026. https://bugzilla.mozilla.org/show_bug.cgi?id=2083449

Chrome and Android Security Teams. “Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates.” Google, The Keyword, 20 October 2026. https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/

Mozilla dev-security-policy mailing list. “Compromised eMudhra Intermediate Certificates” thread, posts by Dennis Jackson (Mozilla) and the Chrome Root Program, 20 October 2026, and by Wayne and Corey Bonnell, 21 October 2026. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE

Jackson, Dennis. “eMudhra Intermediate CA Compromise.” Incident tracking site, 20 October 2026, updated 22 October 2026. https://emudhra.we-have-a-problem.com/

InCommon (Internet2). “Moving Forward Together: InCommon Certificate Service Update.” Updates of 22 October 2026. https://incommon.org/about/news/incommon-certificate-service-update

InCommon (Internet2). “InCommon Certificate Service FAQ.” Last updated 22 October 2026, 18:30 ET. https://incommon.org/certificates

Stanescu, Luci. “eMudhra CA compromise fixes available.” Ubuntu blog, Canonical, 20 October 2026, updated 22 October 2026. https://ubuntu.com/blog/emudhra-ca-compromise-fixes-available

Canonical. “USN-8944-1: ca-certificates update” and “USN-8944-2: ca-certificates update.” Ubuntu security notices, 20 October 2026. https://ubuntu.com/security/notices/USN-8944-1 and https://ubuntu.com/security/notices/USN-8944-2

Go team. “[security] Go 1.27.3 and Go 1.26.10 are released.” golang-announce, posted 20 October 2026 (releases dated 19 October 2026). https://groups.google.com/g/golang-announce/c/66pojueaQek

Go project. “Release History.” Accessed 24 October 2026. https://go.dev/doc/devel/release

certifi. “Remove emsign (#437),” “Restore unaffected emSign roots (#439) (#440)” and “2026.10.23 (#445).” python-certifi repository, 18, 20 and 23 October 2026. https://github.com/certifi/python-certifi/commit/5cb238caeeb6c30ec1a7309ad3e16a5aa7b10ce8 and https://github.com/certifi/python-certifi/commit/662df63d7906df66f1f07c0751a3dfe9da14d914 and https://github.com/certifi/python-certifi/commit/b60466c9f2882d9cf088943c650b0faac06c080c

Cisco Talos. “Compromised eMudhra intermediate certificates.” Talos Intelligence blog, 21 October 2026. https://blog.talosintelligence.com/compromised-intermediate-certificates/

eMudhra Limited. “eMudhra Statement on distrust of select Global TLS Intermediate and one Root CA.” 21 October 2026. https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca

eMudhra Limited. “eMudhra to exit global SSL/TLS certificate business.” 22 October 2026. https://emudhra.com/en/press-release/emudhra-to-exit-global-ssl-tls-certificate-business

Abrams, Lawrence. “Mozilla, Google, Apple block compromised eMudhra CA certificates.” BleepingComputer, 20 October 2026. https://www.bleepingcomputer.com/news/security/mozilla-google-apple-block-compromised-emudhra-ca-certificates/

Helme, Scott. “Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds.” 20 October 2026. https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/

Sharwood, Simon. “Indian certification authority eMudhra’s private keys compromised – one of them was the number ‘4’.” The Register, 20 October 2026. https://www.theregister.com/a/5304312

Mozilla Bugzilla. “Bug 1970728: eMudhra: Invalid CRL signatures.” June 2025. https://bugzilla.mozilla.org/show_bug.cgi?id=1970728

Mozilla. “Firefox for Android 145.0 release notes.” 11 November 2025. https://www.firefox.com/en-US/firefox/android/145.0/releasenotes/

Cooper, D., et al. “RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.” IETF, May 2008. https://www.rfc-editor.org/rfc/rfc5280

Laurie, B., Langley, A., and Kasper, E. “RFC 6962: Certificate Transparency.” IETF, June 2013. https://www.rfc-editor.org/rfc/rfc6962

CA/Browser Forum. “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, Version 2.3.1.” 4 October 2026, sections 3.2.2.4.7, 6.1.1.1 and 6.3.2. https://github.com/cabforum/servercert/blob/3574ae809e5f909b58ee4c26b7bac4a3b9e78421/docs/BR.md

CA/Browser Forum. “Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods.” 11 April 2025. https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/

Google. “Chrome Root Program Policy, Version 1.8.” Last updated 5 February 2026. https://googlechrome.github.io/chromerootprogram/crp/policy/

Mozilla. “Mozilla Root Store Policy, Version 3.1.” Effective 1 July 2026. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

Aas, Josh. “OCSP Service Has Reached End of Life.” Let’s Encrypt, 6 August 2025. https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-end-of-life/

Adrian, David, Serena Chen, Joe DeBlasio, Emily Stark and Emanuel von Zezschwitz. “An update on the lock icon.” Chromium Blog, May 2023. https://blog.chromium.org/2023/05/an-update-on-lock-icon.html

von Zezschwitz, Emanuel, Emily Margarete Stark and Serena Chen. “‘It builds trust with the customers’ – Exploring User Perceptions of the Padlock Icon in Browser UI.” SecWeb 2022, IEEE. https://research.google/pubs/it-builds-trust-with-the-customers-exploring-user-perceptions-of-the-padlock-icon-in-browser-ui/

Android Developers. “Network security configuration: Certificate transparency.” Accessed 24 October 2026. https://developer.android.com/privacy-and-security/security-config

Langley, Adam. “Maintaining digital certificate security.” Google Online Security Blog, July 2014. https://security.googleblog.com/2014/07/maintaining-digital-certificate-security.html

Adkins, Heather. “An update on attempted man-in-the-middle attacks.” Google Online Security Blog, 29 August 2011, updated 3 September 2011. https://security.googleblog.com/2011/08/update-on-attempted-man-in-middle.html

Fox-IT. “Black Tulip: Report of the investigation into the DigiNotar Certificate Authority breach.” 13 August 2012. https://zoek.officielebekendmakingen.nl/blg-191225.pdf