Defaults.Exposed › Perbaikan › Record CAA

Cara memperbaiki Record CAA

Record CAA adalah instruksi singkat dalam pengaturan domain Anda yang menyebutkan perusahaan sertifikat mana yang diizinkan untuk menerbitkan sertifikat keamanan 'gembok' untuk website Anda. Dengan mengaktifkannya, tidak ada perusahaan lain yang bisa diam-diam membuat sertifikat yang valid atas nama Anda.

Intinya bagi bisnis Anda: Tanpa record CAA, hampir semua dari ratusan perusahaan sertifikat di seluruh dunia bisa menerbitkan sertifikat gembok asli yang sepenuhnya dipercaya untuk domain Anda — membiarkan penipu mendirikan klon website Anda yang sempurna dan 'aman' penuh untuk memanen login dan detail kartu pelanggan Anda, dengan tidak ada peringatan di layar untuk memperingatkan mereka.

Kerugian yang dapat ditimbulkan

• Penipu mendapatkan sertifikat nyata untuk salinan website Anda, sehingga menampilkan gembok hijau dan HTTPS — pelanggan Anda tidak melihat ada yang salah, mengetikkan kata sandi dan nomor kartu mereka, dan Anda baru mengetahuinya ketika chargeback dan panggilan marah mulai datang.
• Pelanggan Anda di-phish melalui tiruan sempurna dari halaman login Anda; dampaknya — pengembalian dana, beban dukungan, kerusakan reputasi — mendarat pada merek Anda meskipun website asli Anda tidak pernah disentuh.
• Tim keamanan atau pengadaan calon pelanggan menjalankan pemeriksaan cepat di domain Anda sebelum menandatangani, melihat tidak ada perlindungan CAA, dan diam-diam menandai Anda sebagai 'lemah pada dasar-dasar' — mempertaruhkan kesepakatan atas pengaturan yang butuh lima menit untuk ditambahkan.
• Salah satu perusahaan sertifikat dunia dikompromikan (ini telah terjadi berulang kali — DigiNotar, Comodo, Symantec), dan karena Anda tidak pernah menyatakan siapa yang diizinkan bertindak untuk Anda, domain Anda terekspos ke siapa pun yang ternyata menjadi mata rantai terlemah.

Mengapa ini penting. Saat ini pintu terbuka lebar: setiap perusahaan sertifikat di Bumi bisa menjamin website yang mengklaim sebagai milik Anda, apakah Anda pernah berurusan dengan mereka atau tidak. Record CAA mengunci pintu itu sehingga hanya penyedia yang Anda pilih yang bisa menerbitkan sertifikat — ini adalah pertahanan paling sederhana dan termurah yang ada terhadap seseorang yang menyamar sebagai bisnis Anda secara online.

Record CAA, dalam bahasa sederhana

Setiap website yang aman memiliki sertifikat — hal yang ada di balik gembok di browser dan “https” di depan alamat Anda. Sertifikat tersebut dikeluarkan oleh firma spesialis yang disebut otoritas sertifikat (CA): nama seperti Let’s Encrypt, DigiCert, Sectigo, Google Trust Services. Ketika browser Anda melihat sertifikat yang valid, ia menampilkan gembok dan memberi tahu pelanggan Anda bahwa koneksinya asli dan aman.

Inilah bagian yang sebagian besar pemilik bisnis belum pernah diberitahu: secara default, ratusan otoritas sertifikat ini di seluruh dunia masing-masing diizinkan untuk menerbitkan sertifikat untuk domain Anda — apakah Anda pernah mendengar tentang mereka atau tidak. Record CAA (Certification Authority Authorization) adalah catatan satu baris yang Anda tambahkan ke pengaturan DNS domain Anda yang mengatakan, intinya, “hanya penyedia-penyedia ini yang diizinkan untuk menerbitkan sertifikat untuk saya.” Setiap otoritas sertifikat yang sah diwajibkan oleh aturan industri untuk memeriksa catatan itu sebelum menerbitkan — dan menolak jika mereka tidak ada dalam daftar Anda.

Ini adalah perbedaan antara pintu depan yang tidak terkunci yang bisa diterobos siapa saja, dan pintu di mana hanya orang yang Anda pilih yang memegang kunci. Dan tidak ada biaya untuk menambahkannya.

Dampak finansial yang perlu diketahui

Risiko yang ditutup record CAA adalah peniruan yang meyakinkan. Ketika penipu bisa mendapatkan sertifikat nyata untuk salinan website Anda, tanda peringatan biasa menghilang — tidak ada gembok yang rusak, tidak ada banner “tidak aman”, tidak ada kesalahan sertifikat. Semuanya terlihat benar, yang persis itulah yang membuatnya berbahaya.

• Tiruan yang sempurna. Penipu mendaftarkan alamat yang mirip (atau mengkompromikan rute ke pelanggan Anda), mendapatkan sertifikat asli, dan mendirikan klon sempurna dari halaman login atau checkout Anda — gembok dan semua. Pelanggan memasukkan kata sandi dan nomor kartu seperti biasa. Pertama kali Anda mendengarnya adalah gelombang chargeback, laporan penipuan, dan panggilan telepon marah.
• Kampanye phishing atas nama Anda. Penyerang mengirimkan email “harap konfirmasi akun Anda” yang menautkan ke klon bersertifikat website Anda. Karena halaman terlihat sepenuhnya aman, lebih banyak orang tertipu. Pembersihan — memberi tahu pelanggan, pengembalian dana, jam dukungan, penjelasan publik yang canggung — semuanya mendarat pada Anda, meskipun server asli Anda tidak pernah disentuh.
• Kesepakatan yang terhenti pada daftar periksa. Tim keamanan atau pengadaan pelanggan yang lebih besar memindai domain Anda sebelum menandatangani. “Tidak ada record CAA” muncul sebagai item merah atau kuning di sebelah nama Anda. Ini adalah hal kecil secara teknis, tapi terbaca sebagai “tidak mencakup dasar-dasar,” dan bisa memperlambat atau menenggelamkan kontrak yang seharusnya Anda menangkan.
• Tertimpa oleh pelanggaran orang lain. Otoritas sertifikat yang tidak pernah Anda berurusan dengan dikompromikan — ini bukan hipotesis; DigiNotar, Comodo dan Symantec semuanya pernah mengalami insiden serius. Karena Anda tidak pernah membatasi siapa yang bisa bertindak untuk Anda, penyerang bisa mendapatkan sertifikat yang valid untuk domain Anda melalui CA yang lemah itu. Record CAA akan menolak mereka.
• Titik buta wildcard. Bahkan bisnis yang berhati-hati tentang website utama mereka sering melupakan subdomain. Tanpa aturan issuewild, penyerang yang bisa mendapatkan sertifikat wildcard secara efektif mendapatkan kunci ke setiap subdomain yang pernah Anda miliki sekaligus.

Tidak satu pun dari ini memerlukan serangan canggih pada server Anda. Mereka mengeksploitasi fakta bahwa, tanpa record CAA, sistem sertifikat yang lebih luas terlalu mempercayai atas nama Anda.

Apa sebenarnya itu, dan seperti apa “baik” itu

Record CAA tinggal di DNS domain Anda — pengaturan yang sama yang mengarahkan domain Anda ke website dan email Anda. Setiap record memiliki tiga bagian: tanda, tag, dan nilai. Tag yang penting adalah:

• issue — menyebutkan otoritas sertifikat yang diizinkan untuk menerbitkan sertifikat normal untuk domain Anda. Anda bisa memiliki beberapa, satu per penyedia yang sah Anda gunakan.
• issuewild — mengontrol sertifikat wildcard (satu sertifikat yang mencakup setiap subdomain, misalnya *.example.com). Jika Anda tidak menggunakan wildcard, pengaturan yang direkomendasikan memblokir semuanya.
• iodef — alamat kontak opsional di mana Anda akan diberi tahu jika otoritas sertifikat menolak permintaan karena kebijakan CAA Anda. Ini adalah peringatan dini Anda bahwa seseorang mencoba.

Seperti apa “baik” itu: setidaknya satu record issue (atau issuewild) ada, menyebutkan penyedia yang benar-benar Anda gunakan, dengan wildcard dibatasi ke penyedia yang disebutkan atau diblokir. Itulah tolak ukur yang diukur pemeriksaan ini — ini mencari record CAA domain Anda di beberapa resolver independen dan lulus ketika menemukan kebijakan issue atau issuewild nyata di tempat. Domain tanpa record CAA sama sekali diperlakukan sebagai pintu terbuka yang memang demikian.

Apakah ini mempengaruhi nilai saya? Ya. Record CAA yang hilang adalah item yang dinilai dan ditandai dengan tingkat keparahan sedang — ini adalah kesenjangan nyata, bukan sekadar hal yang baik untuk dimiliki, karena meninggalkan jalur peniruan nyata terbuka. Menambahkan record menutup kesenjangan dan membersihkan temuan.

Cara memperbaikinya (gratis, ~5 menit)

Berikan bagian ini kepada siapa pun yang mengelola domain atau website Anda — perbaikannya gratis. Ini adalah perubahan DNS kecil, bukan pembangunan ulang. Kami hanya mengenakan biaya jika Anda nanti ingin kami terus memantau bahwa record tetap ada; menambahkannya tidak ada biaya.

Langkah 1 — Cari tahu otoritas sertifikat mana yang sebenarnya Anda gunakan. Ini adalah satu langkah yang layak dilakukan dengan benar, karena mencantumkan penyedia yang salah bisa memblokir pembaruan Anda berikutnya. Kasus umum:

• Let’s Encrypt — digunakan oleh banyak host dan panel kontrol (cPanel, Plesk) → letsencrypt.org
• Cloudflare (jika menerbitkan sertifikat edge Anda) → letsencrypt.org, digicert.com, comodoca.com, pki.goog, dan ssl.com (Cloudflare menggunakan beberapa CA backend; cantumkan yang ditampilkan dashboard-nya, atau seluruh set, sehingga pembaruan tidak pernah rusak)
• Google Workspace / Google Trust Services → pki.goog
• DigiCert → digicert.com
• Sectigo / Comodo → sectigo.com (dan comodoca.com)
• Microsoft 365 / Azure — Microsoft biasanya menggunakan DigiCert untuk sertifikat terkelola → digicert.com (konfirmasi di portal Anda)

Jika tidak yakin, lihat sertifikat Anda saat ini di browser (klik gembok → detail sertifikat → “Diterbitkan oleh”) untuk melihat siapa yang menerbitkannya.

Langkah 2 — Masuk ke penyedia DNS Anda. Di sinilah record domain Anda tinggal — biasanya registrar Anda, host web Anda, atau Cloudflare. Temukan bagian record DNS dan pilih untuk menambahkan record baru bertipe CAA (beberapa antarmuka melabelinya tipe 257).

Langkah 3 — Tambahkan record issue untuk setiap penyedia yang Anda gunakan. Untuk Let’s Encrypt, misalnya:

example.com.   CAA   0 issue "letsencrypt.org"

Tambahkan satu baris issue per penyedia yang sah. Sebagian besar dasbor DNS memberi Anda kotak terpisah untuk tanda (0), tag (issue), dan nilai (domain CA) sehingga Anda tidak perlu mengetik seluruh baris secara manual.

Langkah 4 — Kontrol sertifikat wildcard. Jika Anda tidak menggunakan wildcard, blokir sepenuhnya sehingga tidak ada yang bisa diam-diam mendapatkannya:

example.com.   CAA   0 issuewild ";"

Jika Anda menggunakan wildcard, sebutkan penyedianya: 0 issuewild "letsencrypt.org".

Langkah 5 — (Direkomendasikan) Tambahkan alamat notifikasi. Sehingga Anda diberi tahu setiap kali CA menolak percobaan — peringatan dini Anda bahwa seseorang mencoba:

example.com.   CAA   0 iodef "mailto:[email protected]"

Langkah 6 — Simpan dan verifikasi. Jalankan dig CAA example.com (atau gunakan alat pencarian DNS online mana pun) dan konfirmasi record Anda muncul. Perubahan bisa membutuhkan waktu dari beberapa menit hingga beberapa jam untuk menyebar di internet. Sertifikat Anda yang ada dan semua pembaruan terus bekerja selama proses — CAA hanya mengatur penerbitan baru.

Catatan platform cepat: Di Cloudflare, DNS → Records → Add record → tipe CAA. Di Google Workspace, Anda mengelola DNS di registrar Anda (atau Cloud DNS jika Anda menggunakannya) — tambahkan record CAA di sana dengan pki.goog. Di Microsoft 365, CAA tidak diatur di pusat admin M365; tambahkan di mana pun DNS domain Anda dihosting, mencantumkan CA sertifikat terkelola Anda (biasanya DigiCert). Di host umum (GoDaddy, Namecheap, dll.), ini ada di panel DNS yang sama di mana record A dan MX Anda tinggal.

Kesalahan umum

• Mencantumkan CA yang salah — atau melupakannya. Risiko nyata terbesar bukan keamanan, melainkan memblokir pembaruan Anda sendiri. Jika Anda menggunakan lebih dari satu penerbit (misalnya satu untuk website utama dan satu lagi di belakang Cloudflare), cantumkan semuanya. Jika ragu, cantumkan beberapa yang Anda percaya daripada terlalu sedikit.
• Mengatur issue tapi mengabaikan wildcard. Domain yang membatasi sertifikat normal tapi tidak mengatakan apa-apa tentang wildcard masih meninggalkan rute wildcard yang lebih kuat terbuka. Selalu atur issuewild juga — baik ke penyedia Anda atau ke ";" untuk memblokir.
• Menempatkan CAA pada nama yang salah. CAA dibaca oleh otoritas sertifikat untuk nama persis yang disertifikasi, berjalan ke atas pohon. Mengaturnya di bagian atas domain Anda (“apex,” misalnya example.com) adalah langkah yang tepat — ini mencakup subdomain secara default kecuali subdomain mengatur miliknya sendiri.
• Mengasumsikan platform Anda sudah melakukannya. Cloudflare, Google dan Microsoft mengelola sertifikat tapi tidak menambahkan record CAA untuk Anda. Kecuali Anda menambahkannya, domain Anda masih terbuka.
• Memperlakukannya sebagai sekali jadi tanpa pemantauan. Migrasi DNS nantinya, perubahan registrar, atau “perapian” record bisa diam-diam menghapus perlindungan CAA Anda. Layak untuk memeriksa masih ada setelah perubahan DNS apa pun.

Lapisan teknis (berikan ini kepada orang IT Anda)

CAA didefinisikan dalam RFC 8659 dan diberlakukan di bawah CA/Browser Forum Baseline Requirements — setiap CA yang dipercaya secara publik diwajibkan untuk memeriksa CAA pada saat penerbitan. Record mengambil bentuk <flags> <tag> <value>, dengan tag issue, issuewild, dan iodef. Kebijakan issue atau issuewild non-kosong adalah apa yang memenuhi pemeriksaan ini; kehadiran iodef saja tidak (ini adalah pelaporan, bukan otorisasi).

Baseline solid di apex:

example.com.   CAA   0 issue "letsencrypt.org"
example.com.   CAA   0 issuewild ";"
example.com.   CAA   0 iodef "mailto:[email protected]"

Catatan untuk pelaksana:

• CAA tree-climbing: CA mengevaluasi CAA dari FQDN yang diminta ke atas ke apex, berhenti pada nama pertama dengan set record CAA. Record di apex karena itu melindungi semua subdomain kecuali subdomain menerbitkan miliknya sendiri, yang bisa — berguna jika subdomain spesifik menggunakan penerbit berbeda.
• Nilai ; di issuewild berarti “tidak ada CA yang boleh menerbitkan wildcard” — penolakan eksplisit. Gunakan kapan pun wildcard bukan bagian dari pengaturan Anda.
• Tanda 0 adalah tanda critical penerbit; 0 (non-critical) adalah benar untuk penggunaan normal. Hindari mengatur bit critical kecuali Anda sepenuhnya memahaminya, karena tag critical yang salah dipahami bisa menyebabkan CA yang konform menolak penerbitan.
• Beberapa penerbit: beberapa record issue diizinkan dan bersifat aditif — cantumkan setiap CA yang secara sah ada dalam stack Anda (termasuk CA backend yang digunakan penyedia CDN/edge Anda) untuk mencegah kegagalan pembaruan.
• Verifikasi: dig CAA example.com +short, atau periksa melalui alat uji CAA CA/Browser Forum. Pemeriksaan ini sendiri mengkueri CAA melalui beberapa resolver independen (DNS lokal, kemudian Google, Cloudflare dan DNS-over-HTTPS Quad9 sebagai fallback) dan menerima jawaban otoritatif pertama, sehingga pemadaman resolver tunggal tidak akan menghasilkan hasil “tidak ada CAA” palsu.
• Pasangan DNSSEC: CAA memberi tahu CA siapa yang boleh menerbitkan; DNSSEC menghentikan jawaban CAA itu sendiri dari dipalsu saat transit. Mereka saling melengkapi — untuk domain bernilai tinggi, jalankan keduanya.

Atur di host Anda

Langkah demi langkah untuk penyedia populer:

• Atur CAA di GoDaddy
• Atur CAA di Namecheap
• Atur CAA di Cloudflare
• Atur CAA di AWS Route 53

FAQ