Sertifikat SSL Tidak Bisa Diperpanjang karena CAA Record? Cara Membacanya dengan dig

Renewal SSL gagal, dan log AutoSSL atau Certbot menyebut CAA. Padahal domain sudah mengarah ke server yang benar dan challenge validasi sebenarnya lolos. Yang membuat bingung, sering kali tidak ada yang merasa pernah membuat CAA record. Penyebabnya biasanya satu: ada CAA record di domain itu atau di domain induknya yang hanya mengizinkan CA (Certificate Authority, pihak yang menerbitkan sertifikat) tertentu, dan CA yang dipakai server kamu tidak ada di daftar itu. Versi singkat cara mengeceknya ada di Why a CAA Record Can Block Let's Encrypt Renewal and How to Check It. Di artikel ini kita masuk lebih dalam: bagaimana CA sebenarnya mencari CAA, kenapa record di domain induk ikut berlaku, dan cara membaca output dig supaya tidak salah tafsir.

Validasi lolos tapi tetap ditolak: dua pengecekan yang terpisah

CAA (Certification Authority Authorization) adalah tipe record DNS bernomor 257 yang didefinisikan di RFC 8659. Setiap record berisi tiga bagian: flag, tag, dan value. Tag yang paling sering dipakai ada tiga. issue menentukan CA mana yang boleh menerbitkan sertifikat biasa. issuewild khusus untuk sertifikat wildcard. iodef berisi alamat tujuan laporan kalau ada percobaan penerbitan yang ditolak. Urutan kerjanya kira-kira seperti ini. Client ACME seperti Certbot atau AutoSSL membuat order ke CA. CA lalu memvalidasi kepemilikan domain lewat HTTP-01 atau DNS-01. Sebelum menandatangani sertifikat, CA mengirim query DNS tipe CAA untuk setiap nama yang ada di sertifikat. Aturan industri dari CA/Browser Forum mewajibkan CA publik melakukan langkah ini. Karena dua pengecekan ini terpisah, wajar kalau challenge lolos tapi penerbitan tetap ditolak. Validasi kepemilikan menjawab pertanyaan "apakah kamu menguasai domain ini". CAA menjawab pertanyaan lain, yaitu "apakah pemilik domain mengizinkan CA ini". Logika keputusannya sederhana. Kalau tidak ada CAA yang relevan, CA mana pun boleh menerbitkan. Kalau ada set CAA tapi isinya tidak memuat tag issue sama sekali, misalnya hanya iodef, penerbitan biasa tetap diizinkan. Kalau ada tag issue, hanya CA yang identifier-nya tercantum yang boleh. Identifier itu dipublikasikan oleh CA sendiri, contohnya Let's Encrypt memakai letsencrypt.org. Ada satu pengecualian: kalau sebuah record memakai flag 128 (critical) dengan tag yang tidak dipahami CA, CA wajib menolak.

Pencarian naik ke domain induk dan berhenti di set pertama yang ditemukan

CA tidak hanya mengecek nama persis yang ada di sertifikat. Untuk shop.blog.example.com, prosesnya berjalan seperti ini:

Query CAA untuk shop.blog.example.com.
Kalau kosong, naik ke blog.example.com.
Kalau masih kosong, naik ke example.com, lalu ke TLD com.
Berhenti di set CAA pertama yang tidak kosong. Hanya set itu yang dipakai.

Poin yang sering terlewat ada di langkah keempat: set dari level berbeda tidak pernah digabung. Ini membawa dua konsekuensi. Pertama, CAA di root domain berlaku untuk semua subdomain yang tidak punya CAA sendiri. Pola ini sering muncul saat seseorang menambahkan CAA ke example.com untuk sertifikat berbayar di situs utama. Subdomain yang di-host di server lain dengan AutoSSL ikut terkunci, padahal tidak ada yang menyentuh DNS subdomain tersebut. Kedua, CAA di subdomain menimpa induknya secara total. Kalau kamu menambahkan issue untuk Let's Encrypt saja di shop.example.com, CA lain yang diizinkan di root tidak lagi berlaku untuk subdomain itu. Dari sisi support, pertanyaan pertama yang perlu dijawab di tiket seperti ini bukan "ada CAA atau tidak". Pertanyaan yang lebih tepat adalah "level mana yang menjawab CAA untuk nama ini".

Membaca hasil dig level demi level

Telusuri dengan cara yang sama seperti CA, mulai dari nama paling lengkap lalu naik ke atas. Pada contoh ini, ns1.example-dns.net hanyalah placeholder. Ganti dengan nameserver hasil query NS milik domain kamu.

BASH

# Cek CAA di nama persis yang ada di sertifikat
dig shop.example.com CAA

# Kalau kosong, naik ke induknya
dig example.com CAA +noall +answer

# Bandingkan dengan jawaban langsung dari nameserver authoritative, bukan dari cache resolver
dig example.com NS +short
dig example.com CAA @ns1.example-dns.net +noall +answer

Perintah pertama sengaja dijalankan tanpa +noall. Tujuannya supaya baris status di header ikut terlihat, karena di situ letak perbedaan pentingnya. NOERROR dengan ANSWER: 0 artinya kosong, dan CA akan naik ke level berikutnya. NXDOMAIN juga diperlakukan sebagai kosong. SERVFAIL beda cerita, kita bahas di bagian berikutnya. Contoh format output untuk level induk yang punya CAA:

TEXT

example.com.   3600  IN  CAA  0 issue "sectigo.com"
example.com.   3600  IN  CAA  0 issuewild ";"
example.com.   3600  IN  CAA  0 iodef "mailto:[email protected]"

Cara membacanya: kolom kedua adalah TTL, angka 0 adalah flag (bukan critical), lalu tag dan value. Dari tiga baris itu, hanya Sectigo yang boleh menerbitkan sertifikat biasa. Value ";" pada issuewild berarti tidak ada CA yang boleh menerbitkan wildcard. Kalau server memakai Let's Encrypt, renewal pasti ditolak, baik untuk sertifikat biasa maupun wildcard. Di versi dig yang lama, record CAA kadang tampil sebagai TYPE257 dengan isi hex. Itu masalah tampilan saja, bukan masalah record-nya. Selain itu, bandingkan jawaban dari setiap nameserver authoritative. Kalau satu nameserver masih menyajikan zona lama, CA bisa kebetulan menanyai yang itu. Pola yang sama dengan TXT record dibahas di Adding the _acme-challenge TXT Record Doesn't Mean Every Nameserver Serves It.

CNAME, wildcard, dan SERVFAIL yang menyamar jadi masalah CAA

CNAME mengubah jalur pencarian. Misalnya shop.example.com adalah CNAME ke hostname CDN. Query CAA akan mengikuti CNAME itu seperti query DNS biasa. Kalau target CNAME punya CAA, set itulah yang dipakai, walaupun pemiliknya pihak lain. Kalau target kosong, RFC 8659 menyuruh CA naik ke induk dari nama asli, yaitu example.com, bukan ke induk dari target. Aturan di RFC lama (6844) sempat berbeda, jadi perilaku di sistem yang lebih tua bisa tidak sama. Untuk wildcard, aturannya begini. Kalau set yang relevan punya issuewild, hanya tag itu yang dipakai untuk *.example.com, dan issue diabaikan. Kalau tidak ada issuewild, tag issue berlaku juga untuk wildcard. Jadi satu baris issuewild ";" cukup untuk memblokir semua wildcard, walaupun issue sudah mengizinkan CA kamu. Lalu SERVFAIL. Kalau nameserver tidak menjawab query tipe CAA dengan benar, atau validasi DNSSEC zona rusak, CA tidak bisa memastikan izinnya. Biasanya CA memilih menolak. Pesan error-nya bisa menyebut CAA, padahal domain tidak punya CAA record sama sekali. Karena itu, jalankan dig tanpa +short ke setiap nameserver authoritative dan lihat status-nya, bukan hanya isi jawabannya.

Menambahkan entri yang benar tanpa merusak yang sudah ada

Langkah perbaikannya:

Pastikan CA yang benar-benar dipakai. Certbot biasanya mengarah ke Let's Encrypt, tapi bisa dikonfigurasi ke server ACME lain. AutoSSL di WHM tergantung provider yang dipilih di pengaturan AutoSSL. Cek langsung di konfigurasi, jangan menebak.
Ambil identifier CAA resmi dari dokumentasi CA tersebut.
Tambahkan record di level yang ditemukan dig sebagai level yang aktif, dan lakukan di DNS authoritative sesuai hasil query NS. Lokasinya bisa di registrar, layanan DNS eksternal, atau Zone Editor di panel hosting.
Tambahkan entri baru, jangan ganti entri lama. Entri CA lain mungkin masih dipakai oleh sertifikat yang sudah terbit di situs utama.

Contoh isi zona setelah perbaikan, kalau Sectigo masih dibutuhkan dan Let's Encrypt perlu ditambahkan:

TEXT

example.com.  3600  IN  CAA  0 issue "sectigo.com"
example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 issuewild "letsencrypt.org"

Perhatikan baris ketiga. Dengan konfigurasi itu, hanya Let's Encrypt yang boleh menerbitkan wildcard, sedangkan Sectigo tidak. Kalau kamu tidak butuh pembatasan khusus untuk wildcard, hapus saja baris issuewild dan biarkan issue yang berlaku. Ada juga parameter tambahan seperti accounturi dan validationmethods untuk pembatasan yang lebih ketat. Tapi satu kesalahan nilai di parameter itu justru akan memblokir renewal, jadi pakai hanya kalau memang perlu. Setelah record ditambahkan, cek ulang dengan dig ke setiap nameserver authoritative. Ingat bahwa resolver yang sudah menyimpan jawaban lama bisa menahannya sampai TTL habis. Setelah itu baru jalankan ulang AutoSSL atau certbot renew --dry-run. Intinya, kalau renewal ditolak karena CAA, jangan langsung menghapus record-nya. Telusuri dengan dig dari nama paling lengkap ke atas sampai ketemu set pertama yang tidak kosong. Pastikan status-nya bukan SERVFAIL, cek apakah ada CNAME atau issuewild yang ikut berpengaruh, lalu tambahkan identifier CA yang dipakai di level itu juga. Dengan cara ini masalah renewal selesai tanpa mencabut izin CA lain yang mungkin masih dibutuhkan.