Certificate authority publik tidak hanya memvalidasi kontrol atas nama DNS. Sebelum menerbitkan sertifikat, CA yang mengikuti spesifikasi CAA juga memeriksa DNS untuk mencari kebijakan Certification Authority Authorization yang relevan bagi setiap nama dalam permintaan. Kebijakan itu dapat mempersempit kumpulan penerbit yang diizinkan membuat sertifikat untuk domain tersebut.
CAA merupakan kontrol penerbitan, bukan pengganti validasi kontrol domain. CA yang sudah diizinkan tetap harus menjalankan persyaratan validasi dan penerbitannya. Record ini menambahkan satu keputusan lagi: setelah validasi berhasil, apakah penerbit tersebut diizinkan oleh kebijakan CAA yang dipublikasikan domain?
RRset CAA yang relevan menetapkan batas penerbitan
CAA adalah DNS resource record tipe 257. Record dasar memiliki flags, property tag, dan value:
example.net. CAA 0 issue "ca.example"Property issue mengizinkan CA yang disebutkan untuk menerbitkan sertifikat non-wildcard bagi nama yang berada di bawah RRset relevan tersebut. Jika tidak ada property issuewild terpisah, issue juga berlaku untuk penerbitan wildcard.
RFC 8659 menetapkan pencarian RRset yang relevan. Untuk FQDN yang diminta, CA memeriksa nama tersebut lalu bergerak naik melalui label induknya sampai menemukan RRset CAA, tanpa memeriksa DNS root. RRset pertama yang berlaku dari prosedur itu menjadi kebijakan untuk permintaan tersebut.
Pewarisan ini memungkinkan sebuah zona menerbitkan kebijakan pada nama induk tanpa menyalin record yang sama ke setiap anak. Nama anak juga dapat menerbitkan RRset CAA sendiri, yang kemudian menjadi kebijakan terdekat bagi nama tersebut.
Efeknya adalah pewarisan kebijakan melalui pohon nama DNS, bukan pencocokan wildcard. Perbedaan ini penting saat operator mengaudit record pada nama yang didelegasikan dan subdomain khusus layanan.
issue dan issuewild memisahkan penerbitan biasa dan wildcard
Dua property otorisasi utama adalah issue dan issuewild.
example.net. CAA 0 issue "ca-a.example"
example.net. CAA 0 issuewild "ca-b.example"Jika property issuewild ada pada RRset yang relevan, permintaan wildcard dievaluasi terhadap issuewild, bukan issue. Dengan begitu, domain dapat memakai satu penerbit untuk sertifikat biasa dan penerbit lain untuk sertifikat wildcard.
Beberapa property dengan tipe yang sama bersifat aditif. Jika RRset relevan memuat beberapa record issue, setiap penerbit yang tercantum dapat diizinkan sesuai aturan pemrosesan yang berlaku. CAA tidak menyatakan urutan preferensi di antara CA yang diizinkan.
Value penerbit kosong dapat menolak penerbitan untuk kelas property tersebut:
example.net. CAA 0 issue ";"Kebijakan seperti ini dapat dipakai pada nama yang memang tidak semestinya menerima sertifikat publik biasa. Penerapannya harus disengaja karena perubahan CAA yang restriktif juga dapat menghentikan renewal yang sah.
Setiap nama dalam permintaan harus lolos pemeriksaan
Satu sertifikat dapat memuat beberapa identifier DNS. Otorisasi untuk satu identifier tidak mengotorisasi identifier lain. RFC 8659 mewajibkan penerbit memverifikasi otorisasi CAA untuk seluruh FQDN dan nama wildcard dalam permintaan sertifikat.
Misalnya, sebuah permintaan sertifikat memuat:
www.example.net
api.example.netKebijakan permisif yang relevan bagi www.example.net tidak membatalkan kebijakan restriktif yang relevan bagi api.example.net. CA harus memperoleh hasil yang dapat diterima untuk kedua nama sebelum penerbitan dapat dilanjutkan.
Sifat ini membuat CAA berkaitan langsung dengan otomasi. Proses renewal dapat gagal setelah kebijakan DNS berubah meskipun akun ACME, private key, dan mekanisme challenge tetap berfungsi. Jalur penerbitan bergantung pada validasi domain sekaligus kebijakan CAA yang sedang berlaku.
Critical flag melindungi semantik yang tidak didukung penerbit
CAA mencadangkan most significant bit pada octet flags sebagai Issuer Critical flag. Dalam presentation format, nilainya adalah 128.
example.net. CAA 128 futuretag "policy-data"Jika property yang relevan membawa critical flag dan CA tidak mendukung property tag tersebut, CA yang patuh tidak boleh menerbitkan sertifikat bagi nama terkait. Flag ini memungkinkan ekstensi CAA mendatang menandai semantik sebagai wajib, alih-alih membiarkan penerbit mengabaikan property yang tidak dikenalnya.
Property yang tidak dikenal tanpa critical flag tidak otomatis melarang penerbitan. Reserved flag bits harus tetap kosong menurut spesifikasi saat ini.
Mekanisme ini memberi kompatibilitas dengan opsi fail-closed. Memasang critical flag pada property yang tidak dapat diproses CA tujuan dapat menghentikan penerbitan, sehingga penerapannya memerlukan rollout terkontrol, bukan eksperimen langsung di produksi.
iodef menyediakan kontak pelaporan, bukan otorisasi penerbit
CAA juga menetapkan property iodef untuk informasi pelaporan:
example.net. CAA 0 iodef "mailto:security@example.net"Record iodef tidak mengizinkan CA menerbitkan sertifikat. Record tersebut menyediakan lokasi yang dapat dipakai penerbit untuk melaporkan pelanggaran kebijakan atau kejadian terkait sesuai prosedur yang didukungnya.
RRset relevan yang hanya berisi record iodef tidak membatasi penerbitan dengan sendirinya. Pembatasan penerbitan berasal dari property otorisasi beserta aturan pemrosesannya.
Perbedaan ini mencegah salah konfigurasi yang sederhana: menambahkan alamat pelaporan tidak sama dengan membuat allowlist penerbit.
CAA mempersempit otorisasi CA tetapi tidak mengamankan DNS sendirian
Kebijakan CAA diambil melalui DNS. RFC 8659 menetapkan perilaku penerbit terhadap RRset yang relevan, tetapi memublikasikan CAA tidak menambahkan perlindungan integritas pada respons DNS. DNSSEC merupakan mekanisme DNS yang dirancang untuk menyediakan data DNS terautentikasi.
CAA juga tidak membuat penerbitan sertifikat mustahil bagi setiap penyerang. Nilai keamanannya bergantung pada kepatuhan penerbit terhadap batasan, integritas dan administrasi kebijakan DNS, serta bagian lain dari proses validasi CA. CAA adalah kontrol kebijakan dalam ekosistem sertifikat publik, bukan jaminan sertifikat yang berdiri sendiri.
Manfaat praktisnya adalah otorisasi yang lebih sempit. Jika organisasi memang memakai CA publik tertentu, kebijakan CAA yang sesuai dapat menyatakan keputusan tersebut dalam bentuk yang wajib diperiksa penerbit yang patuh sebelum penerbitan.
Perubahan kebijakan perlu kehati-hatian seperti rotasi sertifikat
Record CAA mengikuti perilaku caching DNS. Perubahan kebijakan tidak selalu terlihat oleh setiap resolver atau komponen CA tepat pada saat record baru dipublikasikan.
Sebelum menghapus penerbit, operator perlu memperhitungkan otomasi sertifikat aktif dan renewal yang tertunda. Sebelum menambahkan penerbit baru, operator perlu memastikan kebijakan baru sudah terlihat di jalur evaluasi penerbitan. Sertifikat dengan banyak nama juga memerlukan otorisasi yang konsisten untuk setiap identifier yang diminta.
Review operasional yang berguna mencakup RRset CAA efektif bagi setiap nama sertifikat, penanganan wildcard, batas delegasi DNS, serta penerbit yang dipakai otomasi renewal. Pemeriksaan tersebut sebaiknya selesai sebelum kebijakan restriktif diaktifkan.
CAA paling efektif sebagai batas penerbitan yang kecil dan eksplisit: DNS memublikasikan kumpulan penerbit yang dapat diterima, lalu CA memeriksa batas tersebut sebelum membuat sertifikat. Mekanisme ini mengurangi jumlah CA publik yang sengaja diterima domain tanpa mengubah persyaratan terpisah untuk memvalidasi kontrol atas nama yang diminta.