CAA record domain mengatur CA yang boleh menerbitkan TLS; sertifikat untuk domain bisnis tetap bisa terbit tanpa izin pemilik bila attacker menguasai DNS otoritatif dan lolos domain-control validation (DCV) CA. Gembok HTTPS tidak membuktikan otorisasi bisnis.
Certificate Transparency (CT) mengekspos penerbitan di log publik supaya Anda mendeteksi anomali, bukan mencegah hijack DNS.
Pada 6 Oktober 2026, Google Security Blog melaporkan hijack infrastruktur ccTLD pihak ketiga untuk namespace .gh (Ghana), .sl (Sierra Leone), dan .as (American Samoa). Attacker mengubah authoritative DNS; lalu CA terpercaya menerbitkan sertifikat HTTPS untuk sejumlah domain Google dan organisasi lain. Google menegaskan tidak ada kompromi sistem internal Google dan tidak ada alasan menganggap CA penerbit melakukan kesalahan.
Di Indonesia, banyak UMKM mengandalkan HTTPS aktif di hosting tanpa inventory CA, nameserver, atau alert CT. Walau demikian, insiden ccTLD membuktikan lapisan TLS harus Anda pasangkan dengan keamanan akun registrar, audit delegasi DNS, dan kebijakan penerbitan setelah DNS kembali normal.
Highlight
Record CAA dan Certificate Transparency: Mengapa Sertifikat TLS Domain Bisa Terbit Tanpa Izin Pemilik
- Sertifikat unauthorized = valid kriptografis di browser, tetapi diterbitkan tanpa otorisasi pemilik domain (bukan signature CA dipalsukan).
- CT = transparansi dan deteksi; CAA = kebijakan otorisasi penerbitan; keduanya melengkapi, tidak saling mengganti.
- Google: CAA tidak menghentikan issuance saat attacker masih menguasai DNS aktif (record CAA ikut bisa diubah).
- Setelah recovery DNS, CAA restrictive plus ACME account binding (bila CA mendukung) mempersempit penerbitan lanjutan.
- Chrome CRLSets membantu user Chrome; pemilik domain tetap wajib monitoring CT dan hardening akun DNS/registrar.
Insiden ccTLD .gh, .sl, dan .as: Ringkasan Google
Menurut Chrome Secure Web and Networking Team, attacker mengompromikan operator ccTLD pihak ketiga. Domain di bawah namespace tersebut berisiko; attacker bisa mengubah delegation dan record DNS otoritatif. Lalu CA yang memvalidasi kontrol domain via DNS melihat bukti yang memuaskan syarat DCV.
Google segera memblokir sertifikat unauthorized untuk properti Google lewat CRLSets dan bekerja dengan CA untuk revocation. Kemudian, setelah data CT mengungkap organisasi lain, Chrome turut memblokir sertifikat mencurigakan untuk situs teridentifikasi. Jadi mitigasi browser tidak menggantikan tanggung jawab pemilik domain.
Google memperingatkan penelusuran insiden mungkin tidak menemukan setiap domain terdampak, dan intervensi Chrome tidak melindungi pengguna non-Chrome secara andal. Selanjutnya, CT monitoring plus CAA record domain menjadi rekomendasi eksplisit untuk portfolio domain, termasuk parked dan ccTLD regional.
Unauthorized Certificate Bukan Signature CA Palsu
Headline berita kerap memakai “sertifikat palsu” atau counterfeit TLS. Namun, CA yang browser percaya menandatangani sertifikat insiden ini; yang salah adalah otorisasi pemilik domain, bukan integritas kriptografi CA.
Google menyatakan tidak ada indikasi attacker mencuri private key CA atau CA melanggar prosedur validation yang mereka lihat. Lalu attacker memanipulasi proof of domain control lewat DNS. Istilah yang lebih presisi: mis-issued / unauthorized certificate dari sudut pandang pemilik domain.
Namun, gembok HTTPS membuktikan koneksi terautentikasi menurut aturan PKI, bukan legitimasi bisnis atau kepemilikan organisasi. Untuk situs kredibilitas tinggi (kantor hukum, kesehatan), desain dan kebijakan privasi tetap relevan; lihat contoh elemen trust di artikel fitur website kantor hukum, terpisah dari kontrol PKI.
Rantai Serangan: DNS, DCV, dan CA
Berikut alur konseptual insiden ccTLD:
- Attacker menguasai layer registry/ccTLD atau delegasi DNS otoritatif.
- Record DNS (termasuk TXT/CNAME untuk ACME) mengarah ke bukti yang attacker kendalikan.
- CA otomatis memverifikasi domain control.
- CA menerbitkan sertifikat publik terpercaya.
- Attacker memegang sertifikat unauthorized; intercept traffic butuh posisi routing/DNS tambahan, bukan cert saja.
Jadi, registry (operator TLD), registrar (tempat Anda beli domain), dan DNS host (Cloudflare, Route53, panel hosting) adalah peran berbeda. Kegagalan di layer ccTLD/DNS otoritatif bisa memengaruhi validasi tanpa “meretas” CA.
Menurut kami, audit keamanan website yang hanya mengecek expiry TLS di panel hosting melewatkan titik lemah ini. Lantaran itu, kombinasi WAF edge plus DNS hardening lebih masuk akal; panduan konfigurasi Cloudflare WAF membahas firewall rules, bukan pengganti CAA/CT.
Certificate Transparency: Deteksi, Bukan Pencegahan
Certificate Transparency adalah ekosistem log publik append-only untuk sertifikat TLS yang browser percaya (Chrome mewajibkan disclosure ke log CT untuk sertifikat publik). Tujuannya: issuance dapat diaudit; pemilik domain melihat “siapa menerbitkan apa” untuk nama host mereka.
Namun, CT tidak otomatis memblokir sertifikat jahat. Apabila ada penerbitan baru yang tidak Anda kenali, CT membantu Anda menemukannya. Google menyarankan monitoring CT berkelanjutan untuk semua domain, bukan hanya homepage produk.
Akhirnya, sumber resmi: certificate.transparency.dev. Alat pencarian seperti crt.sh populer sebagai antarmuka komunitas; anggap sebagai titik awal investigasi, bukan SLA monitoring produksi.
Memantau Certificate Transparency dan CAA Record Domain
Meski portfolio bisnis sering mencakup .co.id, kampanye, domain parkir, dan ccTLD regional, attacker bisa menargetkan aset yang jarang diaudit. Pertahankan inventori: apex, wildcard, subdomain produksi, staging, serta CA/ACME account yang tim Anda pakai.
Anda perlu selidiki sinyal CT seperti CA yang tidak pernah Anda pakai, wildcard tiba-tiba, hostname asing, atau issuance di luar jadwal renew. Tetapi entri baru bisa legitimate (CDN, managed certificate host). Verifikasi ke tim infra sebelum panik.
Apabila sertifikat asing terkonfirmasi, kumpulkan detail cert, audit perubahan DNS dan nameserver, cek akun registrar/registry, hubungi CA untuk revocation, rotasi kredensial, dan perluas review ke domain sister. CT alert tidak otomatis revoke cert.
Apa Itu CAA Record Domain?
CAA (Certification Authority Authorization) adalah record DNS yang menyatakan CA mana yang boleh menerbitkan sertifikat untuk zone tersebut. CA publik terpercaya wajib memeriksa CAA (CA/Browser Forum) sebelum issuance.
Namun, CAA tidak mengenkripsi situs, tidak mencabut sertifikat lama, dan tidak melindungi password registrar. CAA hanya kebijakan otorisasi penerbitan.
Contoh konseptual (ganti identifier CA sesuai dokumentasi CA Anda, jangan copy mentah):
example.com. 3600 IN CAA 0 issue "digicert.com"
example.com. 3600 IN CAA 0 issuewild "digicert.com"Angka 0 pada contoh di atas adalah flags, bukan prioritas seperti MX. Tag issue mengatur sertifikat non-wildcard; issuewild mengatur wildcard. Tanpa issuewild yang eksplisit, perilaku fallback mengikuti RFC 8659; cek spesifikasi sebelum mengandalkan asumsi lama.
Batasan CAA Record Domain Saat DNS Dibajak
Google secara eksplisit: CAA cannot prevent certificate issuance during an active DNS hijack, karena attacker yang menguasai DNS juga bisa menambah atau mengubah record CAA agar sesuai CA pilihan mereka.
Jadi, setelah Anda memulihkan kontrol DNS, CAA restrictive mencegah attacker memanfaatkan state validasi domain yang masih cached/reusable untuk menerbitkan sertifikat tambahan. Itu nuansa utama insiden ccTLD: pencegahan lanjutan pasca-recovery, bukan magic shield saat breach aktif.
Record CAA yang terlalu sempit tanpa audit CDN/ACME bisa memutus renew legitimate. Sebelum production, uji issuance/renew di staging dan dokumentasikan CA partner (Universal SSL Cloudflare, ACM, host panel, dll.) dari dokumentasi vendor terbaru.
ACME Account Binding dan CAA Restrictive
RFC 8657 mendefinisikan parameter CAA seperti accounturi dan validationmethods. Google merekomendasikan CAA restrictive dengan ACME account bindings bila CA Anda mendukung: hanya CA tertentu plus akun ACME tertentu yang boleh menerbitkan.
Contoh ilustratif (placeholder; ganti URI akun resmi dari CA):
example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/PLACEHOLDER"Ternyata, dukungan CA bervariasi; jangan anggap semua host panel otomatis compatible. Setelah mengubah CAA, jalankan renew test terjadwal, bukan hanya cek DNS propagate.
Checklist Keamanan Domain Berlapis
Berikut prioritas praktis untuk domain bisnis (bukan jaminan nol insiden):
- MFA pada registrar dan DNS provider; pisahkan akun tim.
- Registrar lock vs registry lock (ketersediaan bervariasi per TLD).
- Alert perubahan nameserver/delegation; simpan baseline NS.
- Monitoring CT untuk seluruh portfolio domain.
- CAA record domain restrictive setelah peta CA/ACME jelas.
- DNSSEC bila TLD/registrar mendukung (melindungi integritas respons DNS, bukan substitusi registry compromise).
- Prosedur respons bila CT menemukan issuer asing.
HTTPS aktif di WordPress atau Laravel tidak menutup celah DNS. Apabila Anda baru memetakan stack web, roadmap belajar membuat website dari nol membantu urutan skill. Tetap masukkan keamanan domain sejak domain pertama Anda beli.
Konteks berita tambahan untuk pembaca umum: laporan Ars Technica (6 Oktober 2026) merangkum insiden; fakta teknis dan rekomendasi pemilik domain tetap mengacu Google Security Blog di atas.
