Let's Encrypt Tambah 2 Perspektif Validasi: 7 Request Mulai November 2026

Let's Encrypt akan memvalidasi domain lewat tujuh request mulai 10 November 2026, naik dari lima request sebelumnya. Perubahan ini mengikuti Baseline Requirements CA/Browser Forum bagian 3.2.2.9 yang mewajibkan minimal lima remote Network Perspectives efektif 15 Desember 2026. Pengumuman resminya diposting staf Let's Encrypt, Phil Porada, pada 15 Oktober 2026, dan uji coba di staging dijadwalkan 27 Oktober 2026.

TL;DR

• Tujuh request validasi: satu dari datacenter primer, enam dari remote perspective.
• Dasar aturannya BR 3.2.2.9, wajib berlaku 15 Desember 2026.
• Staging 27 Oktober 2026, produksi 10 November 2026.
• Let's Encrypt memperkirakan dampak ke pengguna hampir nol.

Apa yang sebenarnya berubah di validasi domain?

Yang berubah adalah jumlah titik jaringan yang dimintai konfirmasi, bukan cara pemilik domain membuktikan kepemilikan. Sebelumnya Let's Encrypt mengirim satu request dari datacenter primer dan empat request dari remote perspective, total lima. Setelah perubahan, jumlah remote perspective menjadi enam sehingga totalnya tujuh. Validasi tetap dinyatakan sukses kalau server primer dan kuorum remote perspective menerima respons challenge yang benar.

Challenge yang dipakai tidak berubah. Untuk HTTP-01, Let's Encrypt tetap mengambil file token dari port 80 di domain yang diminta. Untuk DNS-01, validasi tetap membaca TXT record di zona DNS. Untuk TLS-ALPN-01, koneksi TLS di port 443 tetap diperiksa dengan protokol ALPN khusus. Semua mekanisme ini sudah didefinisikan di spesifikasi ACME pada RFC 8555, jadi tidak ada perubahan format file, record, atau sertifikat yang perlu ditulis ulang.

Yang bertambah adalah beban observasi. Satu nama domain kini dilihat dari tujuh lokasi jaringan berbeda dalam satu proses issuance. Bagi server yang sehat, perbedaannya tidak terasa. Bagi server yang hanya bisa diakses dari sebagian wilayah, perbedaan ini bisa terasa sangat nyata.

Kenapa jumlah perspektif ditambah?

Alasannya keamanan routing, bukan penambahan beban. Validasi domain berbasis jaringan selalu punya titik lemah yang sama: keputusan diambil berdasarkan apa yang terlihat dari satu sudut internet. Kalau penyerang bisa mengalihkan trafik ke arah sudut itu lewat BGP hijacking atau manipulasi DNS resolver, server validasi akan melihat respons yang benar padahal domainnya bukan milik pemohon.

Multi-perspective validation mempersempit celah itu. Untuk menipu sistem, penyerang harus mengalihkan trafik ke banyak lokasi sekaligus, dan lokasi-lokasi itu harus berada di wilayah registri internet yang berbeda. Baseline Requirements menyebut syarat eksplisit: remote perspective yang mengonfirmasi perspektif primer harus mencakup setidaknya dua Regional Internet Registry yang berbeda. Kalau syarat itu tidak terpenuhi, CA dilarang melanjutkan penerbitan sertifikat.

Let's Encrypt sudah memakai pendekatan ini sejak 2020. Penjelasan konsepnya ada di blog Let's Encrypt tahun 2020, dan teks aturan terbarunya bisa dibaca langsung di dokumen Baseline Requirements CA/Browser Forum. Perubahan tahun 2026 ini menaikkan jumlah minimum dari empat menjadi enam remote perspective, sejalan dengan kewajiban lima perspektif remote di BR 3.2.2.9.

Apa dampaknya buat server yang pakai firewall atau geo-blocking?

Dampak terbesarnya justru ada di sini, bukan di server biasa. Server yang membatasi akses berdasarkan negara, ASN, atau rentang IP tertentu berisiko gagal validasi karena request dari perspektif baru datang dari alamat yang belum pernah masuk daftar izin. Selama ini empat perspektif mungkin sudah cukup dikenal, tetapi dua perspektif tambahan berarti dua kemungkinan baru untuk ditolak firewall.

Gejala kegagalan biasanya tidak ambigu. ACME client akan melaporkan error validasi dengan tipe challenge yang jelas, misalnya koneksi timeout pada HTTP-01 atau NXDOMAIN pada DNS-01, sementara domain yang sama bisa diakses dari jaringan biasa. Kalau pola ini muncul tepat setelah tanggal rollout, penyebab paling mungkin adalah filter jaringan, bukan masalah DNS atau sertifikat.

Yang perlu dilakukan sederhana: pastikan port 80 dan 443 terbuka untuk publik tanpa pembatasan geografis selama proses validasi, atau longgarkan filter minimal sampai semua perspektif bisa menjangkau server. Untuk pemilik domain yang memakai DNS-01, masalah ini biasanya tidak muncul karena validasi membaca zona DNS, bukan koneksi langsung ke server.

Kapan perubahan ini benar-benar berlaku?

Tanggalnya bertahap dan sudah diumumkan terbuka. Let's Encrypt mulai menjalankan validasi dengan wilayah baru di staging pada Selasa, 27 Oktober 2026. Kalau tidak ada masalah, rollout produksi dilakukan Selasa, 10 November 2026. Kewajiban aturan dari CA/Browser Forum sendiri baru efektif 15 Desember 2026, jadi Let's Encrypt mengambil langkah lebih awal dari tenggat.

Urutan ini penting untuk tim operasi. Staging memberi ruang uji tanpa risiko sertifikat produksi gagal, dan periode antara 27 Oktober dan 10 November cukup untuk menemukan masalah firewall sebelum kena di lingkungan nyata. Siapa pun yang punya otomasi issuance sebaiknya memakai jendela itu untuk mencoba ulang alur renew di staging.

Aspek	Sebelum perubahan	Setelah perubahan
Request dari datacenter primer	1	1
Request dari remote perspective	4	6
Total request validasi	5	7
Dasar aturan	BR lama	BR 3.2.2.9
Mulai staging	-	27 Oktober 2026
Mulai produksi	-	10 November 2026

Apa yang perlu disiapkan admin sebelum 10 November?

Ada empat hal yang layak dicek, dan semuanya bisa dilakukan tanpa menyentuh sertifikat produksi. Pertama, audit aturan firewall di edge dan cloud security group untuk port 80 dan 443. Kedua, cek apakah ada WAF atau rate limiter yang bisa menganggap enam request beruntun dari IP berbeda sebagai serangan. Ketiga, pastikan tidak ada aturan geo-blocking yang menolak negara tempat perspektif baru berada. Keempat, uji renew di staging setelah 27 Oktober.

Untuk yang memakai DNS-01 lewat provider seperti Cloudflare atau Route 53, risikonya lebih kecil karena tidak ada trafik masuk ke server. Meski begitu, propagation delay tetap layak diperiksa: enam perspektif membaca zona dari resolver yang berbeda, dan zona dengan TTL tinggi bisa memperlambat konvergensi. Menurunkan TTL record challenge sebelum renew adalah langkah murah yang sering menyelamatkan.

Let's Encrypt menegaskan ekspektasi dampaknya kecil. Dalam pengumuman resmi di thread komunitas Let's Encrypt, tim menyebut perubahan ini "little to no impact to users". Kalimat itu masuk akal untuk domain publik biasa, tetapi tidak otomatis berlaku untuk infrastruktur yang sengaja dibatasi.

Bagaimana kuorum validasi dihitung?

Kuorum berarti suara mayoritas dari perspektif yang diminta, bukan kesepakatan semua pihak. Dalam skema Let's Encrypt, server primer tetap menjadi perspektif utama, lalu sejumlah remote perspective harus menerima respons yang sama. Kalau server primer melihat respons benar tetapi kuorum remote melihat respons berbeda, validasi tidak lolos. Sebaliknya, kalau satu perspektif remote gagal karena masalah jaringan lokal di sisi mereka, kegagalan itu tidak otomatis membatalkan issuance selama kuorum terpenuhi.

Konsekuensinya, dua perspektif tambahan tidak berarti dua kali lipat kemungkinan gagal bagi domain yang sehat. Yang bertambah adalah cakupan pemeriksaan. Domain yang dilayani dengan benar dari banyak lokasi akan lolos dengan pola yang sama seperti sebelumnya, hanya dengan jumlah pengamatan yang lebih banyak. Perubahan terasa terutama pada domain yang responsnya bergantung pada lokasi pengakses, misalnya karena DNS anycast yang tidak konsisten atau karena aturan firewall yang berbeda per region.

BR 3.2.2.9 juga mengatur bahwa perspektif yang mengonfirmasi perspektif primer harus tersebar di minimal dua Regional Internet Registry. Aturan ini mencegah satu operator jaringan menguasai seluruh suara, dan itulah alasan teknis di balik penambahan cakupan wilayah, bukan sekadar penambahan jumlah server.

Apa yang terjadi kalau validasi gagal?

Kegagalan validasi tidak merusak sertifikat yang sedang aktif. Sertifikat lama tetap berlaku sampai tanggal kedaluwarsanya, dan yang gagal hanyalah permintaan penerbitan atau perpanjangan baru. ACME client akan menerima error dengan detail challenge, lalu biasanya mencoba ulang sesuai kebijakan retry masing-masing. Let's Encrypt juga punya batas laju penerbitan, jadi percobaan berulang tanpa perbaikan hanya akan menghabiskan kuota.

Praktik yang aman adalah memperbaiki penyebabnya dulu, baru meminta ulang. Untuk HTTP-01, periksa apakah file token benar-benar bisa diambil dari jaringan luar, bukan hanya dari localhost. Untuk TLS-ALPN-01, pastikan tidak ada reverse proxy yang memutus koneksi sebelum handshake ALPN selesai. Untuk DNS-01, pastikan TXT record sudah terpropagasi ke resolver publik, bukan hanya ke resolver lokal.

Satu hal yang sering terlewat: memantau tanggal kedaluwarsa. Kalau renewal gagal berulang karena masalah firewall yang baru muncul, sertifikat bisa kedaluwarsa tanpa disadari. Alert sederhana pada 21 hari sebelum kedaluwarsa memberi ruang cukup untuk mendiagnosis tanpa panik.

Apakah ini memengaruhi performa server?

Secara langsung, tidak. Request validasi datang dari luar dan berhenti di endpoint challenge, bukan di aplikasi. Untuk HTTP-01, beban tambahan hanya dua request HTTP kecil ke path token yang biasanya dilayani langsung oleh reverse proxy atau web server. Untuk TLS-ALPN-01, bebannya dua handshake TLS tambahan, yang pada server modern berada di kisaran milidetik. Tidak ada koneksi persisten, tidak ada beban database, dan tidak ada pekerjaan CPU berat.

Yang bisa terasa adalah noise di log dan metrik. Enam request dari IP berbeda dalam waktu berdekatan bisa memicu alert yang menganggapnya pemindaian, terutama kalau ambang deteksi disetel ketat. Solusi paling sederhana adalah mengecualikan path challenge ACME dari aturan alerting, bukan melonggarkan aturan untuk seluruh situs. Pendekatan itu menjaga deteksi tetap tajam untuk trafik lain.

Untuk sistem yang memakai rate limiter berbasis IP, perhatikan juga bahwa enam perspektif berarti enam alamat sumber berbeda. Rate limit per IP tidak akan terpicu, tetapi rate limit per domain atau per path bisa. Kalau ada aturan seperti itu di edge, tambahkan pengecualian untuk path well-known ACME sebelum tanggal rollout produksi.

FAQ

Apakah sertifikat yang sudah terbit perlu diterbitkan ulang?

Tidak. Perubahan ini hanya menyentuh proses validasi domain saat issuance dan renewal, bukan isi sertifikat. Sertifikat yang masih berlaku tetap sah sampai masa berlakunya habis, dan renewal berikutnya akan otomatis memakai tujuh request.

Apakah semua jenis challenge terkena dampaknya?

Ya, dalam arti jumlah perspektif berlaku untuk proses validasi secara umum. Yang berbeda adalah mediumnya: HTTP-01 dan TLS-ALPN-01 bergantung pada koneksi ke server, sedangkan DNS-01 bergantung pada pembacaan zona dari resolver yang berbeda.

Bagaimana kalau server saya di balik CDN?

Biasanya aman, karena CDN punya titik presence di banyak wilayah dan meneruskan challenge ke origin. Yang perlu dipastikan adalah konfigurasi cache tidak menyajikan respons lama untuk path token ACME, dan aturan keamanan CDN tidak memblokir request dari lokasi baru.

Apakah ini berlaku untuk CA lain?

Kewajiban lima remote perspective berasal dari Baseline Requirements CA/Browser Forum, jadi berlaku untuk CA yang tunduk pada aturan itu. Jadwal implementasinya bisa berbeda antar CA, tetapi tenggat aturannya sama, yaitu 15 Desember 2026.

Di mana saya bisa memantau perkembangan rollout?

Thread pengumuman di forum komunitas Let's Encrypt adalah kanal resminya, dan update akan diposting di thread yang sama. Untuk perubahan mendadak, status page Let's Encrypt juga layak dipantau selama periode staging dan produksi.