DNS CAA Membatasi CA yang Boleh Menerbitkan Sertifikat

Certificate authority yang dipercaya secara publik hanya dapat menerbitkan sertifikat setelah menyelesaikan validasi yang diwajibkan oleh policy-nya dan aturan ekosistem yang berlaku. DNS Certification Authority Authorization (CAA) menambahkan kontrol lain: domain dapat menyatakan CA mana yang diizinkan menerbitkan sertifikat untuk namespace DNS tersebut.

CAA tidak menggantikan validasi kontrol domain, Certificate Transparency, atau verifikasi sertifikat oleh client. Mekanisme ini membatasi penerbitan di sisi CA. CA yang memproses permintaan memeriksa policy CAA yang relevan sebelum penerbitan dan tidak boleh menerbitkan ketika policy melarangnya.

permintaan sertifikat
        |
        v
CA resolve policy CAA
        |
        +--> diizinkan ----> validasi lain ----> penerbitan dapat dilanjutkan
        |
        +--> tidak diizinkan -----------------> jangan terbitkan

Kontrol ini berguna karena Web PKI memiliki banyak issuer tepercaya. Domain yang hanya berniat memakai CA tertentu dapat menyatakan pilihan tersebut di DNS, sehingga tidak semua CA yang secara umum dipercaya tetap memiliki izin yang sama untuk menerbitkan sertifikat bagi nama itu.

Record CAA membawa policy issuer

RFC 8659 mendefinisikan DNS resource record CAA. Sebuah record berisi flags, property tag, dan property value. Property issue memberi otorisasi penerbitan sertifikat untuk domain.

example.com.  CAA 0 issue "ca.example"

Value tersebut mengidentifikasi issuer yang diizinkan sesuai issuer-domain-name yang didaftarkan CA. Contoh ini hanya ilustrasi; deployment harus memakai identifier yang didokumentasikan oleh CA yang benar-benar digunakan.

Beberapa record issue dapat mengizinkan beberapa CA:

example.com.  CAA 0 issue "ca-one.example"
example.com.  CAA 0 issue "ca-two.example"

CAA dengan demikian berfungsi sebagai allowlist, bukan mekanisme pemeringkatan. Dua issuer yang diizinkan tidak menyatakan preferensi di antara keduanya.

Domain juga dapat secara eksplisit menolak penerbitan biasa dengan issuer value kosong:

example.com.  CAA 0 issue ";"

Bentuk ini menyatakan bahwa tidak ada CA yang diizinkan oleh property issue untuk domain tersebut. Perubahan operasional perlu memperhitungkan policy itu sebelum renewal atau penggantian sertifikat diminta.

Otorisasi wildcard memiliki property terpisah

Property issuewild mengontrol otorisasi penerbitan sertifikat wildcard. Jika CAA RRset yang relevan berisi issuewild, record tersebut mengatur permintaan wildcard sebagai pengganti record issue.

example.com.  CAA 0 issue "ca-one.example"
example.com.  CAA 0 issuewild "ca-two.example"

Dalam policy ini, penerbitan biasa dan wildcard dapat diserahkan kepada CA berbeda. Pemisahan tersebut berguna pada lingkungan yang mengizinkan sertifikat host rutin tetapi menyalurkan sertifikat wildcard melalui proses penerbitan yang lebih sempit.

Jika tidak ada property issuewild pada RRset yang berlaku, property issue juga mengontrol penerbitan wildcard. Penambahan issuewild karena itu mengubah boundary otorisasi secara khusus untuk permintaan wildcard.

Policy dapat diwarisi dari nama parent

Pemrosesan CAA tidak berhenti pada nama persis yang diminta ketika policy CAA tidak ditemukan di sana. Prosedur lookup dapat bergerak ke atas melalui hierarki DNS sampai menemukan CAA RRset yang berlaku, mengikuti aturan RFC 8659.

Domain parent dengan demikian dapat menetapkan policy penerbitan yang mencakup nama di bawahnya ketika nama tersebut tidak menerbitkan policy yang berlaku lebih dekat.

service.dev.example.com
        |
        | tidak ada CAA yang berlaku di sini
        v
dev.example.com
        |
        | tidak ada CAA yang berlaku di sini
        v
example.com
        |
        +--> policy CAA ditemukan

Nama child dapat menerbitkan CAA RRset sendiri jika membutuhkan kumpulan issuer berbeda. Kepemilikan DNS dan policy penerbitan sertifikat menjadi berkaitan erat: penambahan namespace yang didelegasikan atau dikelola secara independen juga dapat mengubah lokasi policy CAA yang diperlukan.

Pemrosesan CNAME dan DNAME menambahkan aturan resolusi lain. Automation sertifikat sebaiknya mengandalkan resolusi CAA yang sesuai standar, bukan menerapkan lookup exact-name sederhana seperti TXT.

Critical flag memengaruhi property yang tidak dikenal

Flags octet mencakup issuer-critical bit. Ketika bit tersebut dipasang pada property yang tidak dikenali CA, CA tidak boleh menerbitkan berdasarkan CAA RRset tersebut.

example.com.  CAA 128 custom-property "value"

Mekanisme ini memungkinkan domain menandai extension property sebagai wajib bagi issuer. Konsekuensi operasionalnya juga jelas: critical bit pada property yang tidak didukung CA tujuan dapat memblokir penerbitan.

Untuk property standar issue, issuewild, dan iodef, deployment tetap perlu mengikuti syntax dan semantic yang ditetapkan standar serta identifier issuer yang didokumentasikan CA. Critical flag bukan pengganti property value yang benar.

iodef menyediakan kontak pelaporan

Property iodef dapat memublikasikan URI kontak untuk laporan pelanggaran policy CAA atau exception pada permintaan penerbitan.

example.com.  CAA 0 iodef "mailto:security@example.com"

Keberadaan iodef tidak dengan sendirinya mengizinkan atau melarang penerbitan. Property ini menyediakan informasi pelaporan. Domain yang membutuhkan pembatasan issuer tetap memerlukan policy issue atau issuewild sesuai kebutuhan.

Perilaku pelaporan juga bergantung pada dukungan issuer dan situasi yang terjadi. Record iodef tidak tepat diperlakukan sebagai kanal alert yang dijamin atau sebagai pengganti inventaris sertifikat dan monitoring Certificate Transparency.

CAA membatasi CA, bukan penggunaan sertifikat

CAA dievaluasi di sekitar proses penerbitan. Browser dan TLS client tidak memakai record CAA domain saat ini untuk menentukan validitas sertifikat yang sudah diterbitkan. Menghapus CA dari CAA karena itu tidak mencabut sertifikat yang sebelumnya diterbitkan CA tersebut.

Boundary ini memisahkan beberapa kontrol yang kadang dikelompokkan bersama:

  • CAA menyatakan CA yang boleh menerbitkan.
  • Validasi CA menentukan apakah permintaan penerbitan memenuhi validasi yang diwajibkan.
  • Certificate Transparency menghasilkan bukti logging publik untuk sertifikat yang tercakup policy ekosistem browser.
  • Mekanisme revocation mengomunikasikan status sertifikat setelah penerbitan.
  • TLS client memvalidasi sertifikat yang disajikan selama koneksi.

Tidak ada satu item yang menggantikan item lain. CAA mengurangi kumpulan issuer yang diizinkan, tetapi tidak membuat CA yang diizinkan bebas dari kesalahan dan tidak menjamin penerbitan tanpa izin mustahil secara teknis.

Operasi DNS menjadi bagian dari operasi sertifikat

Policy CAA yang ketat dapat memblokir penerbitan sah ketika DNS dan automation sertifikat tidak lagi selaras. Migrasi CA, issuer cadangan, alur wildcard, subdomain terdelegasi, dan prosedur penggantian darurat perlu sesuai dengan record yang dipublikasikan.

Sebelum memperketat policy, operator dapat menginventarisasi CA yang benar-benar dipakai oleh jalur penerbitan aktif, memetakan alur wildcard dan non-wildcard secara terpisah, serta memverifikasi issuer identifier yang diminta setiap CA. Perubahan DNS juga memerlukan waktu propagasi sesuai perilaku resolver dan cache normal sebelum alur penerbitan yang bergantung padanya menganggap policy baru sudah terlihat.

CAA paling kuat ketika diperlakukan sebagai lapisan otorisasi sempit dengan pemilik operasional yang jelas. Mekanisme ini memberi domain cara berbasis standar untuk mengurangi pilihan issuer pada saat penerbitan sertifikat, sementara validasi sertifikat, logging, revocation, dan enforcement TLS tetap ditangani oleh mekanisme masing-masing.

Keamanan Siber PKI DNS TLS CAA