Defaults.Exposed › Pembaikan › Rekod CAA

Cara memperbaiki Rekod CAA

Rekod CAA adalah arahan pendek dalam tetapan domain anda yang menamakan syarikat sijil mana yang dibenarkan untuk mengeluarkan sijil keselamatan 'kunci' untuk laman web anda. Dengan ia dihidupkan, tiada syarikat lain yang boleh secara senyap mencipta sijil yang sah atas nama anda.

Kesimpulan untuk perniagaan anda: Tanpa rekod CAA, hampir mana-mana daripada ratusan syarikat sijil di seluruh dunia boleh mengeluarkan sijil kunci yang tulen dan dipercayai sepenuhnya untuk domain anda — membolehkan penipu menubuhkan klon laman anda yang sempurna dan kelihatan 'selamat' sepenuhnya untuk menuai log masuk dan butiran kad pelanggan anda, tanpa sebarang amaran di skrin untuk memberi amaran kepada mereka.

Apakah kos yang boleh timbul

• Penipu mendapat sijil sebenar untuk salinan laman anda, jadi ia menunjukkan kunci hijau dan HTTPS — pelanggan anda tidak nampak apa-apa yang salah, menaip kata laluan dan nombor kad mereka, dan anda hanya mengetahuinya apabila caj balik dan panggilan marah mula.
• Pelanggan anda dipancing melalui tiruan sempurna halaman log masuk anda; akibatnya — bayaran balik, beban sokongan, kerosakan reputasi — mendarat pada jenama anda walaupun laman sebenar anda tidak pernah disentuh.
• Pasukan keselamatan atau perolehan prospek menjalankan semakan pantas pada domain anda sebelum menandatangani, melihat tiada perlindungan CAA, dan secara senyap menandakan anda sebagai 'lemah pada asas-asas' — meletakkan urusan perniagaan pada risiko atas tetapan yang mengambil masa lima minit untuk ditambah.
• Salah satu syarikat sijil dunia terjejas (ini telah berlaku berulang kali — DigiNotar, Comodo, Symantec), dan kerana anda tidak pernah menyatakan siapa yang dibenarkan untuk bertindak bagi pihak anda, domain anda terdedah kepada mana-mana yang ternyata menjadi pautan paling lemah.

Mengapa ia penting. Pada masa ini pintu terbuka luas: mana-mana syarikat sijil di Bumi boleh menjamin laman yang mendakwa menjadi anda, sama ada anda pernah berurusan dengan mereka atau tidak. Rekod CAA mengunci pintu itu supaya hanya pembekal yang anda pilih yang boleh mengeluarkan sijil — ia adalah pertahanan paling mudah dan murah terhadap seseorang yang menyamar perniagaan anda dalam talian.

Rekod CAA, dalam bahasa mudah

Setiap laman web yang selamat mempunyai sijil — perkara di belakang kunci dalam pelayar dan “https” di hadapan alamat anda. Sijil-sijil itu diedarkan oleh firma pakar yang dipanggil pihak berkuasa sijil (CA): nama seperti Let’s Encrypt, DigiCert, Sectigo, Google Trust Services. Apabila pelayar anda melihat sijil yang sah, ia menunjukkan kunci dan memberitahu pelanggan anda sambungan adalah tulen dan selamat.

Inilah bahagian yang kebanyakan pemilik perniagaan tidak pernah diberitahu: secara lalai, ratusan pihak berkuasa sijil ini di seluruh dunia masing-masing dibenarkan untuk mengeluarkan sijil untuk domain anda — sama ada anda pernah mendengar tentang mereka atau tidak. Rekod CAA (Certification Authority Authorization) adalah nota satu baris yang anda tambah kepada tetapan DNS domain anda yang berkata, secara berkesan, “hanya pembekal-pembekal ini yang dibenarkan untuk mengeluarkan sijil untuk saya.” Setiap pihak berkuasa sijil yang sah dikehendaki oleh peraturan industri untuk memeriksa nota itu sebelum mengeluarkan — dan untuk menolak jika mereka tidak ada dalam senarai anda.

Ia adalah perbezaan antara pintu hadapan yang tidak berkunci yang sesiapa boleh masuk, dan satu di mana hanya orang yang anda pilih yang memegang kunci. Dan ia tidak memerlukan kos apa-apa untuk ditambah.

Apa yang ini boleh koskan anda

Risiko yang rekod CAA menutup adalah penyamaran yang meyakinkan. Apabila penipu boleh mendapat sijil sebenar untuk salinan laman anda, tanda amaran biasa hilang — tiada kunci yang rosak, tiada sepanduk “tidak selamat,” tiada ralat sijil. Segalanya kelihatan betul, yang adalah tepat apa yang membuatnya berbahaya.

• Tiruan yang sempurna. Penipu mendaftarkan alamat yang menyerupai (atau menjejaskan laluan kepada pelanggan anda), mendapat sijil yang tulen, dan menubuhkan klon sempurna halaman log masuk atau checkout anda — kunci dan semua. Pelanggan memasukkan kata laluan dan nombor kad seperti biasa. Anda mengetahuinya untuk pertama kali dengan gelombang caj balik, laporan penipuan, dan panggilan telefon yang marah.
• Kempen pancingan data atas nama anda. Penyerang menghantar e-mel “sila sahkan akaun anda” yang menghubungkan ke klon laman anda yang bersijil. Kerana halaman kelihatan selamat sepenuhnya, lebih ramai orang terjebak. Pembersihan — memberitahu pelanggan, bayaran balik, jam sokongan, penjelasan awam yang janggal — semuanya mendarat pada anda, walaupun pelayan sebenar anda tidak pernah disentuh.
• Urusan yang terhenti pada senarai semak. Pasukan keselamatan atau perolehan pelanggan yang lebih besar mengimbas domain anda sebelum menandatangani. “Tiada rekod CAA” muncul sebagai item merah atau ambar di sebelah nama anda. Ia adalah perkara kecil secara teknikal, tetapi ia dibaca sebagai “tidak merangkumi asas-asas,” dan ia boleh melambatkan atau menenggelamkan kontrak yang sebaliknya akan anda menangkan.
• Terperangkap oleh pelanggaran orang lain. Pihak berkuasa sijil yang tidak pernah anda berurusan dengannya terjejas — ini bukan hipotetikal; DigiNotar, Comodo dan Symantec semuanya pernah mengalami insiden serius. Kerana anda tidak pernah menyekat siapa yang boleh bertindak bagi pihak anda, penyerang boleh mendapat sijil yang sah untuk domain anda melalui CA yang lemah itu. Rekod CAA akan menolak mereka.
• Titik buta wildcard. Malah perniagaan yang berhati-hati tentang laman utama mereka sering terlupa subdomain. Tanpa peraturan issuewild, penyerang yang boleh mendapat sijil wildcard secara berkesan mendapat kunci kepada setiap subdomain yang anda akan ada sekaligus.

Tidak ada di sini memerlukan serangan canggih pada pelayan anda. Mereka mengeksploitasi fakta bahawa, dengan tiada rekod CAA, sistem sijil yang lebih luas hanyalah terlalu mempercayai bagi pihak anda.

Apa yang sebenarnya, dan apa yang “baik” kelihatan

Rekod CAA berada dalam DNS domain anda — tetapan yang sama yang menghala domain anda ke laman web dan e-mel anda. Setiap rekod mempunyai tiga bahagian: bendera, tag, dan nilai. Tag yang penting ialah:

• issue — menamakan pihak berkuasa sijil yang dibenarkan untuk mengeluarkan sijil biasa untuk domain anda. Anda boleh mempunyai beberapa, satu per pembekal yang anda gunakan secara sah.
• issuewild — mengawal sijil wildcard (satu sijil yang merangkumi setiap subdomain, mis. *.contoh.com). Jika anda tidak menggunakan wildcard, tetapan yang disyorkan menyekatnya sepenuhnya.
• iodef — alamat hubungan pilihan di mana anda akan diberitahu jika pihak berkuasa sijil menolak permintaan kerana dasar CAA anda. Ini adalah amaran awal anda bahawa seseorang mencuba.

Apa yang “baik” kelihatan: sekurang-kurangnya satu rekod issue (atau issuewild) hadir, menamakan pembekal yang anda sebenarnya gunakan, dengan wildcard sama ada dihadkan kepada pembekal yang dinamakan atau disekat. Itulah garis yang semakan ini ukur — ia mencari rekod CAA domain anda merentas beberapa penyelesai bebas dan lulus apabila mendapati dasar issue atau issuewild yang nyata. Domain tanpa sebarang rekod CAA langsung dianggap sebagai pintu terbuka yang ia adalah.

Adakah ini mempengaruhi gred saya? Ya. Rekod CAA yang hilang adalah item yang dinilai dan ditandakan pada keparahan sederhana — ia adalah jurang yang tulen, bukan sekadar elok ada, kerana ia meninggalkan laluan penyamaran yang nyata terbuka. Menambah rekod menutup jurang dan membersihkan penemuan.

Cara membetulkannya (percuma, ~5 minit)

Serahkan bahagian ini kepada sesiapa yang menguruskan domain atau laman web anda — pembetulan adalah percuma. Ia adalah perubahan DNS kecil, bukan pembinaan semula. Kami hanya mengenakan bayaran jika anda kemudiannya mahu kami terus memantau bahawa rekod kekal di tempat; menambahnya tidak memerlukan kos apa-apa.

Langkah 1 — Cari tahu pihak berkuasa sijil mana yang anda sebenarnya gunakan. Ini adalah satu langkah yang berbaloi untuk betul, kerana menyenaraikan pembekal yang salah boleh menyekat pembaharuan seterusnya anda. Kes biasa:

• Let’s Encrypt — digunakan oleh banyak hos dan panel kawalan (cPanel, Plesk) → letsencrypt.org
• Cloudflare (jika ia mengeluarkan sijil tepi anda) → letsencrypt.org, digicert.com, comodoca.com, pki.goog, dan ssl.com (Cloudflare menggunakan beberapa CA back-end; senaraikan yang papan pemuka menunjukkan, atau set penuhnya, supaya pembaharuan tidak pernah rosak)
• 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 sijil yang diuruskan → digicert.com (sahkan dalam portal anda)

Jika tidak pasti, lihat sijil semasa anda dalam pelayar (klik kunci → butiran sijil → “Dikeluarkan oleh”) untuk melihat siapa yang mengeluarkannya.

Langkah 2 — Log masuk ke pembekal DNS anda. Ini adalah di mana sahaja rekod domain anda berada — biasanya pendaftar anda, hos web anda, atau Cloudflare. Cari bahagian rekod DNS dan pilih untuk menambah rekod baru jenis CAA (beberapa antara muka melabelnya jenis 257).

Langkah 3 — Tambah rekod issue untuk setiap pembekal yang anda gunakan. Untuk Let’s Encrypt, sebagai contoh:

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

Tambah satu baris issue per pembekal yang sah. Kebanyakan papan pemuka DNS memberikan anda kotak berasingan untuk bendera (0), tag (issue), dan nilai (domain CA) supaya anda tidak perlu menaip keseluruhan baris dengan tangan.

Langkah 4 — Kawal sijil wildcard. Jika anda tidak menggunakan wildcard, sekat mereka terus supaya tiada siapa dapat mendapatnya secara senyap:

contoh.com.   CAA   0 issuewild ";"

Jika anda menggunakan wildcard, namakan pembekal sebaliknya: 0 issuewild "letsencrypt.org".

Langkah 5 — (Disyorkan) Tambah alamat pemberitahuan. Supaya anda diberitahu apabila CA menolak percubaan — amaran awal anda bahawa seseorang mencuba:

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

Langkah 6 — Simpan dan sahkan. Jalankan dig CAA contoh.com (atau gunakan mana-mana alat carian DNS dalam talian) dan sahkan rekod anda muncul. Perubahan boleh mengambil masa dari beberapa minit hingga beberapa jam untuk merebak merentasi internet. Sijil sedia ada anda dan semua pembaharuan terus berfungsi sepanjang masa — CAA hanya mengawal pengeluaran baru.

Nota pantas platform: Pada Cloudflare, DNS → Rekod → Tambah rekod → jenis CAA. Pada Google Workspace, anda menguruskan DNS di pendaftar anda (atau Cloud DNS jika anda menggunakannya) — tambah rekod CAA di sana dengan pki.goog. Pada Microsoft 365, CAA tidak ditetapkan dalam pusat pentadbir M365; tambahkan di mana sahaja DNS domain anda dihoskan, menyenaraikan CA sijil yang diuruskan anda (biasanya DigiCert). Pada hos biasa (GoDaddy, Namecheap, dan yang serupa), ia berada dalam panel DNS yang sama di mana rekod A dan MX anda berada.

Kesilapan biasa

• Menyenaraikan CA yang salah — atau lupa satu. Risiko dunia sebenar terbesar bukan keselamatan, ia menyekat pembaharuan anda sendiri. Jika anda menggunakan lebih daripada satu pengeluar (mis. satu untuk laman utama dan satu lagi di belakang Cloudflare), senaraikan semua. Apabila ragu-ragu, senaraikan beberapa yang anda percayai daripada terlalu sedikit.
• Menetapkan issue tetapi mengabaikan wildcard. Domain yang menyekat sijil biasa tetapi tidak mengatakan apa-apa tentang wildcard masih meninggalkan laluan wildcard yang lebih berkuasa terbuka. Sentiasa tetapkan issuewild juga — sama ada kepada pembekal anda atau kepada ";" untuk menyekatnya.
• Meletakkan CAA pada nama yang salah. CAA dibaca oleh pihak berkuasa sijil untuk nama tepat yang dipersijilankan, berjalan naik pokok. Menetapkannya di atas domain anda (the “apex,” mis. contoh.com) adalah langkah yang betul — ia merangkumi subdomain secara lalai melainkan subdomain menetapkan miliknya sendiri.
• Menganggap platform anda sudah melakukannya. Cloudflare, Google dan Microsoft menguruskan sijil tetapi tidak menambah rekod CAA untuk anda. Melainkan anda menambahnya, domain anda masih terbuka.
• Menganggapnya selesai-dan-lupakan tanpa pemantauan. Penghijrahan DNS kemudian, perubahan pendaftar, atau “kemas kini” rekod boleh secara senyap menjatuhkan perlindungan CAA anda. Berbaloi menyemak ia masih di sana selepas sebarang perubahan DNS.

Lapisan teknikal (serahkan ini kepada orang IT anda)

CAA ditakrifkan dalam RFC 8659 dan dikuatkuasakan di bawah Keperluan Garis Dasar CA/Browser Forum — setiap CA yang dipercayai secara awam dikehendaki memeriksa CAA pada masa pengeluaran. Rekod mengambil bentuk <bendera> <tag> <nilai>, dengan tag issue, issuewild, dan iodef. Dasar issue atau issuewild yang tidak kosong adalah yang memuaskan semakan ini; kehadiran iodef sahaja tidak (ia adalah pelaporan, bukan kebenaran).

Garis dasar yang kukuh di apex:

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

Nota untuk pelaksana:

• Pendakian pokok CAA: CA menilai CAA dari FQDN yang diminta ke atas ke apex, berhenti pada nama pertama dengan set rekod CAA. Rekod di apex oleh itu melindungi semua subdomain melainkan subdomain menerbitkan miliknya sendiri, yang boleh — berguna jika subdomain tertentu menggunakan pengeluar yang berbeza.
• Nilai ; dalam issuewild bermaksud “tiada CA yang boleh mengeluarkan wildcard” — penolakan eksplisit. Gunakannya apabila wildcard bukan sebahagian daripada persediaan anda.
• Bendera 0 adalah bendera kritikal-pengeluar; 0 (bukan-kritikal) adalah betul untuk penggunaan biasa. Elakkan menetapkan bit kritikal kecuali anda memahaminya sepenuhnya, kerana tag kritikal yang disalahfahami boleh menyebabkan CA yang mematuhi menolak pengeluaran.
• Pelbagai pengeluar: beberapa rekod issue dibenarkan dan bersifat tambahan — senaraikan setiap CA yang sah dalam tindanan anda (termasuk CA back-end yang pembekal CDN/tepi anda gunakan) untuk mengelakkan kegagalan pembaharuan.
• Pengesahan: dig CAA contoh.com +short, atau semak melalui alat ujian CAA CA/Browser Forum. Semakan ini sendiri menanya CAA melalui beberapa penyelesai bebas (DNS tempatan, kemudian Google, Cloudflare dan Quad9 DNS-over-HTTPS sebagai sandaran) dan menerima jawapan autoritatif pertama, supaya satu pemadaman penyelesai tidak akan menghasilkan hasil “tiada CAA” palsu.
• Pemasangan DNSSEC: CAA memberitahu CA siapa yang boleh mengeluarkan; DNSSEC menghentikan jawapan CAA itu sendiri daripada dipalsukan dalam transit. Mereka adalah pelengkap — untuk domain bernilai tinggi, jalankan kedua-duanya.

Sediakan pada hos anda

Langkah demi langkah untuk pembekal popular:

• Sediakan CAA pada GoDaddy
• Sediakan CAA pada Namecheap
• Sediakan CAA pada Cloudflare
• Sediakan CAA pada AWS Route 53

Soalan Lazim