Cloudflare ingin menjadi CA sendiri akibat konsentrasi CA gratis

Selama bertahun-tahun Cloudflare mengandalkan 16 otoritas sertifikat publik mitra tanpa pernah menerbitkan sendiri satu pun sertifikat tepercaya publik. Kini perusahaan itu berniat menjadi salah satunya, dan bagian menariknya adalah rancangannya: sertifikat klasik dan Merkle Tree Certificates di bawah satu CA, dengan pembatasan dampak kegagalan yang dibangun sejak awal.

Konsumen sertifikat menjadi penerbit sertifikat #

Sebagian besar perusahaan infrastruktur tetap berada di satu sisi hubungan sertifikat. Mereka meminta sertifikat, memasangnya, dan mengeluh ketika sebuah CA mengalami insiden. Cloudflare selama ini kokoh berada di sisi konsumen. Menurut pengakuannya sendiri, perusahaan itu belum pernah menerbitkan satu pun sertifikat tepercaya publik.

Hal itu akan segera berubah, atau setidaknya Cloudflare menyatakan berniat demikian. Perusahaan itu mengumumkan niatnya menjadi otoritas sertifikat publik. Pengumumannya berhati-hati tentang posisi saat ini, dan artikel ini juga harus begitu. Cloudflare belum menerbitkan sertifikat. Segala hal tentang perilaku layanan itu, dari antarmuka ACME hingga aturan pembaruan dan dukungan Merkle Tree Certificates, adalah pernyataan rencana, bukan gambaran sistem yang sudah berjalan.

Yang membuat pengumuman ini kredibel bukanlah ambisi, melainkan persiapan yang sudah terlihat. Cloudflare telah mendaftar untuk dimasukkan ke program root Chrome, Apple, Microsoft, dan Mozilla. Perusahaan itu menyatakan sedang menjalani proses pendaftaran dan persetujuan di setiap program kunci root utama web, dan mencatat bahwa proses ini berlangsung secara terbuka. Pada prinsipnya, siapa pun dapat memantau apakah pendaftaran itu berhasil.

Mengapa Cloudflare berada pada posisi untuk mengajukan pertanyaan ini #

Argumen Cloudflare untuk membangun CA dimulai dari posisinya sebagai pelanggan. Perusahaan itu berada di depan lebih dari 20 persen lalu lintas permintaan Internet global. Ia mengakhiri TLS untuk jutaan domain dan mengandalkan jutaan sertifikat per tahun. Ia menyediakan paket sertifikat melalui Universal SSL bagi pelanggannya, dan juga memakai sertifikat dari banyak CA berbeda untuk menjalankan sistem dan operasi internalnya sendiri.

Agar layanan pelanggan tetap berjalan, Cloudflare memperoleh sertifikat itu melalui beberapa CA, dengan jalur utama dan cadangan agar layanan pelanggan tetap aktif selama gangguan CA dan peristiwa pencabutan. Jaringan CA publik mitra yang diandalkannya selama bertahun-tahun berjumlah 16.

Mekanisme cadangan itu layak dicermati karena menunjukkan cara Cloudflare memikirkan kegagalan. Setiap sertifikat Universal SSL sudah dikirim dengan sertifikat cadangan, dibungkus dengan kunci terpisah dan diterbitkan oleh otoritas yang berbeda. Jika sertifikat utama dicabut atau disusupi, cadangannya siap dipasang secara otomatis. Itu adalah lindung nilai terhadap kegagalan CA mana pun, yang dibangun dari sisi pelanggan.

Lindung nilai itu juga punya batas atas. Anda hanya dapat melakukan diversifikasi di antara CA yang ada, dan sumber berpendapat bahwa pasokan CA yang mumpuni lebih tipis daripada kelihatannya.

Masalah konsentrasi #

Angka di balik argumen itu mencolok. Let's Encrypt menerbitkan sekitar sepuluh juta sertifikat per hari. Lembaga itu melayani lebih dari 500 juta situs dan melampaui empat miliar sertifikat aktif pada 2025. Itu adalah angka untuk satu CA gratis, dan angka itu menggambarkan web yang enkripsinya sangat bergantung pada satu organisasi.

Sumber menarik kesimpulan yang jelas, dengan kehati-hatian yang tepat: jika otoritas sertifikat gratis yang dominan mengalami minggu yang buruk, sebagian besar web tidak akan memiliki alternatif gratis dan otomatis yang sebanding yang siap menanggung bebannya. Ini adalah pernyataan tentang skenario hipotetis, dan Cloudflare menyajikannya demikian. Cloudflare tidak mengklaim minggu seperti itu pernah terjadi, atau akan datang.

Meski begitu, logikanya mudah diikuti. CA gratis dan otomatis hanya menjadi pilihan ketahanan jika sudah ada sebelum keadaan darurat. Tawaran Cloudflare adalah menyediakan CA kedua dalam skala besar. Menurut saya itulah alasan komersial dan teknis terkuat dalam pengumuman ini, dan alasan itu tidak bergantung pada bagian rencana yang lebih spekulatif. Web yang memiliki satu CA gratis dominan dan hampir tidak ada yang lain adalah web dengan satu titik kegagalan, sebaik apa pun kualitas operasi CA itu.

Dimensi	CA Otomatis Gratis Tradisional (Let's Encrypt)	CA Publik Cloudflare yang Diusulkan
Strategi Jangkar Kepercayaan	ISRG Root X1 / X2 (root internal yang dibangun sejak 2015)	Root GlobalSign yang diakuisisi (dipercaya sejak 2012) + root baru
Protokol Penerbitan	ACME standar (RFC 8555)	ACME dengan penegakan ARI (RFC 9773) wajib
Paradigma Pencabutan	CRL / OCSP + penggantian massal darurat oleh pelanggan	Pemajuan pembaruan terkoordinasi melalui endpoint ARI
Jalur Pascakuantum	Tanda tangan X.509 hibrida dalam tahap evaluasi	Merkle Tree Certificates (MTC) native berdampingan dengan X.509 klasik
Skala dan Beban Kerja Awal	~10 juta sertifikat/hari di 500 juta+ situs	Validasi Pelanggan Nol di 20%+ lalu lintas web global

Membeli root alih-alih menunggunya #

Keputusan paling praktis dalam pengumuman ini menyangkut root. Cloudflare menyatakan telah menandatangani perjanjian definitif untuk mengakuisisi root yang mapan dan dipercaya secara luas dari GlobalSign. Sumber memberikan alasannya secara langsung: root yang benar-benar baru tidak berguna secara luas selama bertahun-tahun. Sebaliknya, root GlobalSign yang ada telah dipercaya di berbagai peramban, sistem operasi, dan perangkat sejak 2012.

Kepercayaan pada root berjalan lambat karena root dipasang di perangkat, dan perangkat diperbarui dengan lambat. Root baru dapat diterima oleh setiap program namun tetap gagal divalidasi di ponsel lama atau sistem tertanam. Mengakuisisi root yang sudah beredar sejak 2012 menghindari penantian itu, setidaknya menurut cara sumber membingkainya.

Cloudflare tidak sepenuhnya meninggalkan jalur root baru. Perusahaan itu juga akan mengajukan root baru untuk dimasukkan ke program kunci root, yang digambarkannya sebagai dibangun untuk arah ekosistem, termasuk program yang mulai membatasi seberapa tua root tepercaya boleh berumur. Detail terakhir itu menjadi pengingat berguna bahwa usia punya dua sisi. Usia root tepercaya adalah aset untuk cakupan perangkat, dan beberapa program bergerak ke arah batasan seberapa tua root tepercaya boleh berumur. Menjalankan root yang diakuisisi sekaligus pengajuan baru tampak sebagai jawaban atas ketegangan itu, meski sumber tidak menguraikan alasannya dengan istilah tersebut.

Layanan yang mengutamakan ACME, dengan syarat #

Adopsi adalah titik di mana banyak pengumuman CA menjadi samar. Cloudflare spesifik. CA publiknya akan mengutamakan ACME, artinya menggunakan protokol Automated Certificate Management Environment yang sudah dipakai otomatisasi yang ada. Klaimnya, siapa pun yang sudah diarahkan ke CA gratis yang ada dapat pindah ke CA Cloudflare dengan mengganti URL direktori, tanpa alat baru dan tanpa merancang ulang apa pun. Itu adalah rencana, bukan jalur migrasi yang sudah diuji, dan harus dibaca demikian. Namun perubahan konfigurasi satu baris adalah sasaran yang tepat, karena biaya migrasilah yang membuat orang bertahan pada pilihan bawaan.

Masalahnya ada pada persyaratan yang belum pernah harus dipenuhi sebagian besar pengguna ACME. Cloudflare hanya akan menerbitkan sertifikat untuk klien yang mendukung ACME Renewal Information, atau ARI, yang distandarkan dalam RFC 9773. Pelanggan wajib memelihara otomatisasi yang menanyakan endpoint pembaruan Cloudflare, bertindak sesuai jendela pembaruan yang diterbitkan Cloudflare, dan mengidentifikasi sertifikat yang digantikannya.

Ini adalah sikap yang tegas, dan menurut saya sikap yang benar. Sikap ini juga memunculkan pertanyaan yang wajar tentang adopsi: CA yang hanya melayani klien berkemampuan ARI lebih sempit daripada CA yang melayani siapa pun yang memiliki pustaka ACME. Sumber tidak menyebutkan berapa banyak klien yang tersisih karenanya saat ini, jadi saya tidak akan menebak. Yang disebutkan adalah alasan Cloudflare menginginkan batasan itu.

Pencabutan tanpa merusak situs #

Cloudflare menyatakan telah mengamati banyak hal selama 16 tahun terakhir, dan satu pengamatan mendorong rancangan ini. Perusahaan itu telah melihat otoritas sertifikat terjepit antara pencabutan tepat waktu dan menjaga situs pelanggan tetap daring.

Ketegangan itu nyata bagi CA mana pun. Mencabut sertifikat dengan cepat melindungi publik, tetapi dapat menjatuhkan setiap situs yang bergantung pada sertifikat itu jika pelanggan tidak dapat menggantinya cukup cepat. CA yang terjepit di tengah akan mencabut terlambat atau merusak pelanggannya.

ARI adalah jawaban Cloudflare. Ketika sertifikat perlu dipensiunkan, Cloudflare menyatakan dapat memajukan jendela pembaruan untuk sertifikat yang terdampak. Karena pelanggan diwajibkan menanyakan endpoint pembaruan dan bertindak sesuai jendela yang diterbitkannya, CA dapat mengarahkan mereka ke penggantian sebelum pencabutan keras terjadi. Mekanisme ini digambarkan sebagai kemampuan yang ingin dimiliki Cloudflare, bukan kemampuan yang telah dibuktikannya sebagai CA. Tetap saja, logikanya utuh: persyaratan penanyaan itu ada agar tuas ini bekerja.

Pemikiran yang sama terlihat dalam tujuan rancangan yang lebih luas. Cloudflare berniat membangun otoritas sertifikat yang keandalannya tidak hanya bergantung pada menghindari kesalahan, tetapi, seperti produk Cloudflare lainnya, pada gagal dalam skala kecil dan membatasi dampak dari setiap masalah. Menghindari kesalahan wajib bagi CA, dan tidak ada CA yang dapat menjanjikannya secara sempurna. Merancang agar kesalahan tetap terkurung adalah sikap rekayasa yang lebih jujur.

Transparansi di luar audit #

CA publik biasanya dinilai berdasarkan audit. Sumber terus terang tentang batasannya: audit bersifat sesaat dan memberi tahu Anda bahwa sebuah CA lulus. Audit tidak memberi tahu apa yang dilakukan CA itu pada hari Selasa sembarang sesudahnya.

Jawaban Cloudflare adalah menyatakan akan menerbitkan build yang dapat direproduksi dari perangkat lunak yang menandatangani sertifikat. Hal itu dibingkai sebagai komitmen, bukan hasil yang sudah jadi. Build yang dapat direproduksi memungkinkan pihak luar memeriksa bahwa biner yang berjalan di jalur penandatanganan sesuai dengan kode sumber yang diterbitkan, dan itu adalah sifat yang berkelanjutan dengan cara yang tidak dimiliki laporan audit. Apakah itu terbukti memadai akan bergantung pada apa yang benar-benar diterbitkan Cloudflare, dan apakah pihak lain memeriksanya.

Paruh kedua pengumuman: Merkle Tree Certificates #

Materi pascakuantum adalah bagian yang paling jauh menatap ke depan. Cloudflare mengumumkan rencana menjadi salah satu CA pertama yang melayani sertifikat pascakuantum, dan berencana menerbitkan Merkle Tree Certificates pertamanya pada kuartal pertama 2027. Bagian lain dari sumber menyebutkan bahwa MTC pertama diharapkan pada awal 2027. Keduanya adalah rencana.

Sumber menggambarkan MTC sebagai cara baru yang jauh lebih ringkas untuk mengirimkan sertifikat tepercaya publik. Rumusan itu adalah deskripsi, dan sumber tidak menyertakan pengukuran dalam bagian yang saya gunakan, jadi saya tidak dapat mengatakan seberapa jauh lebih ringkas. Cloudflare menyatakan telah memperjuangkan proposal berbasis standar untuk MTC di IETF. Perusahaan itu juga melaporkan bahwa Chrome menyebut MTC sebagai jalur pilihan untuk autentikasi pascakuantum awal tahun ini. Itu adalah peristiwa yang sudah terjadi, dan penting, karena preferensi yang dinyatakan sebuah vendor peramban mengubah proposal menjadi sesuatu yang dapat dijadikan dasar perencanaan oleh CA.

Cloudflare tidak mengharapkan transisi yang mendadak. Perusahaan itu memperkirakan sebagian besar Internet akan tetap mengandalkan sertifikat klasik dan WebPKI yang ada selama bertahun-tahun lagi. Sepanjang periode itu, diperkirakan MTC akan mengambil porsi penerbitan yang terus bertambah. Itu adalah perkiraan, dan sumber melabelinya demikian.

Satu CA, satu siklus hidup #

Pilihan arsitektur yang lahir dari hal ini adalah yang paling meyakinkan bagi saya. CA baru dirancang untuk membawa sertifikat klasik dan Merkle Tree Certificates di bawah satu CA, dengan satu siklus hidup dan satu rangkaian jaminan. Pelanggan kemudian dapat mengadopsi sesuai kecepatan yang cocok bagi mereka dan membantu web melakukan peralihan tanpa pemutusan mendadak.

Alternatifnya adalah dua CA paralel, dua rangkaian prosedur, dan migrasi paksa pada suatu saat. Pemutusan mendadak adalah cara paling berisiko untuk mengubah ekosistem sertifikat, dan tujuan yang dinyatakan sumber adalah menghindarinya. Rumusannya berhati-hati, dan memang seharusnya: ini adalah niat rancangan untuk CA yang belum menerbitkan sertifikat.

Hal ini juga sesuai dengan gambaran insentifnya. Cloudflare menyatakan memperkirakan jumlah sertifikat yang diandalkannya setiap tahun akan terus bertambah seiring memendeknya masa berlaku maksimum, meningkatnya aktivitas agentik, dan meluasnya sertifikat pascakuantum. Lebih banyak sertifikat, yang diterbitkan lebih sering, mendukung otomatisasi dan CA yang memperlakukan pembaruan sebagai operasi kelas satu. Sistem yang dibangun di sekitar ARI dan satu siklus hidup adalah respons yang masuk akal terhadap perkiraan itu, meski perkiraan itu sendiri adalah proyeksi, bukan pengukuran.

Pelanggan Nol #

Bagaimana menguji CA sebelum publik mengandalkannya? Jawaban Cloudflare adalah menjadi pelanggan pertamanya sendiri. Perusahaan itu akan menjadi Pelanggan Nol bagi CA baru dan sertifikatnya, baik WebPKI maupun MTC. Tujuan yang dinyatakan adalah memastikan semua aspek sistem dan proses baru memenuhi standar internal Cloudflare yang tinggi, dan bahwa infrastruktur CA diuji pada skala Cloudflare.

Mengingat angka-angka sebelumnya, itu adalah beban internal yang berat: jutaan sertifikat per tahun, di perusahaan yang berada di depan lebih dari 20 persen lalu lintas permintaan global. Apakah tahun-tahun pertama operasi akan berjalan mulus tidak dapat diketahui dari klaim-klaim itu. Yang ditunjukkannya adalah urutan kerja yang masuk akal. Perusahaan itu mulai sebagai pengguna berat dari apa yang sedang dibangunnya, dengan riwayat penyediaan multi-CA, jalur cadangan, dan 16 CA mitra di belakangnya.

Perlu dikatakan terus terang apa yang belum ada. Sumber tidak melaporkan volume penerbitan, tingkat kesalahan, latensi validasi, atau riwayat insiden untuk CA Cloudflare sendiri, karena riwayat seperti itu belum ada. Pengumuman ini adalah pernyataan niat yang didukung pendaftaran, perjanjian akuisisi, dan rancangan. Ini bukan rekam jejak.

Yang perlu dipantau #

Tiga hal akan menentukan apakah ini menjadi tambahan berarti bagi WebPKI atau sekadar pengumuman yang menarik.

Pertama adalah program root. Cloudflare telah mendaftar ke Chrome, Apple, Microsoft, dan Mozilla, dan prosesnya berlangsung secara terbuka. Memantaunya adalah cara paling langsung untuk melihat sejauh mana rencana itu berjalan, dan hasilnya bukanlah sesuatu yang dapat saya prediksi dari klaim mana pun.

Kedua adalah persyaratan ARI. CA yang bersikeras pada dukungan RFC 9773 sedang bertaruh bahwa otomatisasi pembaruan dapat didorong maju di seluruh basis pelanggannya. Jika taruhannya benar, Cloudflare mendapat kemampuan untuk memajukan jendela pembaruan ketika sertifikat harus dipensiunkan, yang merupakan jawaban yang dinyatakannya atas dilema pencabutan yang pernah dilihatnya. Jika salah, adopsi akan lebih lambat daripada yang tersirat dalam cerita migrasi satu baris.

Ketiga adalah kuartal pertama 2027. Saat itulah Cloudflare merencanakan Merkle Tree Certificates pertamanya. Pertanyaan terbukanya adalah seberapa cepat porsi yang terus bertambah yang diharapkannya benar-benar akan tumbuh, mengingat pandangannya sendiri bahwa sebagian besar Internet akan tetap memakai sertifikat klasik selama bertahun-tahun lagi. Perusahaan itu menyatakan peralihan ini seharusnya tidak memerlukan pemutusan mendadak. Kuartal pertama 2027 akan menjadi kesempatan pertama untuk melihat apakah satu CA yang membawa kedua jenis sertifikat dapat mewujudkannya.

Artinya bagi Setiap Sektor #

Munculnya otoritas sertifikat publik otomatis bervolume tinggi dari penyedia infrastruktur edge mengubah risiko operasional dan perencanaan PKI di beberapa bidang teknis.

Infrastruktur cloud dan jaringan edge #

Mengoperasikan CA publik pada skala edge mengurangi ketergantungan eksternal pada API verifikasi pihak ketiga dan CRL. Dengan menggabungkan terminasi edge reverse proxy dengan pembaruan ACME ARI otomatis, penyedia infrastruktur dapat melindungi pelanggan mereka dari gangguan otoritas sertifikat di hulu.

PKI perusahaan dan tim DevOps #

Organisasi yang mengandalkan Let's Encrypt untuk endpoint publik mendapatkan alternatif otomatis yang kredibel. Namun, penegakan wajib RFC 9773 (ARI) berarti tim harus mengaudit klien ACME mereka (Certbot, Lego, Caddy, Traefik) untuk memastikan dukungan ARI aktif sebelum mengganti endpoint direktori.

Vendor peramban dan tata kelola root #

Program root (Chrome, Mozilla, Apple, Microsoft) menghadapi ekosistem CA otomatis bervolume tinggi yang terus meluas. Pendekatan root jalur ganda (mengakuisisi root lama tahun 2012 sambil mengajukan root modern) menavigasi kebijakan peramban yang semakin membatasi masa hidup sertifikat root sambil mempertahankan kompatibilitas mundur untuk perangkat lama.

Kesimpulan #

Langkah Cloudflare menjadi otoritas sertifikat publik menyasar kerentanan struktural yang nyata dalam WebPKI modern: konsentrasi ekstrem dalam penerbitan sertifikat gratis dan otomatis. Dengan menggabungkan root GlobalSign yang mapan, otomatisasi pembaruan ARI yang ketat, dan jembatan ke depan menuju Merkle Tree Certificates pascakuantum, rancangan ini menangani ketahanan operasional, bukan sekadar penyediaan sertifikat. Keberhasilannya akan ditentukan oleh persetujuan program root dan seberapa cepat perangkat klien mengadopsi standar ARI menjelang peluncuran 2027.

Pertanyaan yang Sering Diajukan #

Dapatkah saya mengalihkan klien ACME saya ke CA Cloudflare hari ini?

Belum. Cloudflare telah mengumumkan niatnya, menandatangani perjanjian akuisisi root, dan mengajukan pendaftaran ke program root utama. Penerbitan publik dijadwalkan setelah program root memberikan persetujuan.

Apa itu ACME Renewal Information (ARI) dan mengapa penting?

ARI (RFC 9773) adalah ekstensi protokol ACME yang memungkinkan otoritas sertifikat memberi tahu pelanggan kapan sebuah sertifikat sebaiknya diperbarui. Ini memungkinkan CA mengoordinasikan pembaruan lebih awal dengan mulus menjelang pencabutan terencana, sehingga mencegah gangguan situs.

Apa perbedaan Merkle Tree Certificates (MTC) dengan sertifikat X.509 standar?

MTC menggantikan tanda tangan kriptografis individual tradisional dengan bukti inklusi Merkle yang berlabuh pada log yang dapat diverifikasi publik. Hal ini secara signifikan mengurangi ukuran sertifikat dan beban transmisi, sehingga MTC menjadi kandidat pilihan untuk autentikasi TLS pascakuantum.

Referensi #

Cloudflare, (2026). Membangun Otoritas Sertifikat untuk Seluruh Internet ⧉. Cloudflare Blog.
IETF, (2024). RFC 9773: Informasi Pembaruan Automated Certificate Management Environment (ACME) (ARI) ⧉. IETF.
IETF, (2025). Merkle Tree Certificates untuk TLS ⧉. IETF.
Chrome Root Program, (2026). Kebijakan dan Pertimbangan tentang Autentikasi Pascakuantum ⧉. Chromium Projects.

Terakhir ditinjau 2026-09-20.

Terakhir ditinjau 2026-10-27.

Terbitkan ulang artikel ini

Cloudflare ingin menjadi CA sendiri akibat konsentrasi CA gratis — Sebastien Rousseau

Cloudflare mengumumkan niat menjadi otoritas sertifikat publik: mendaftar ke program root utama dan membeli root GlobalSign untuk mengurangi konsentrasi CA gratis.

Artikel ini berlisensi Creative Commons Attribution 4.0 International. Penerbitan ulang memerlukan atribusi ke URL kanonis.

Cloudflare ingin menjadi CA sendiri akibat konsentrasi CA gratis — Sebastien Rousseau

Cloudflare mengumumkan niat menjadi otoritas sertifikat publik: mendaftar ke program root utama dan membeli root GlobalSign untuk mengurangi konsentrasi CA gratis.

Originally published at https://sebastienrousseau.com/id/2026-09-20-cloudflare-ingin-menjadi-ca-sendiri-akibat/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER