Defaults.Exposed › การแก้ไข › ระเบียน CAA

วิธีแก้ไข ระเบียน CAA

ระเบียน CAA เป็นคำสั่งสั้นๆ ในการตั้งค่าโดเมนของคุณที่ระบุว่าบริษัทใบรับรองใดได้รับอนุญาตให้ออกใบรับรองความปลอดภัย 'padlock' สำหรับเว็บไซต์ของคุณ เมื่อเปิดใช้งาน ไม่มีบริษัทอื่นสามารถสร้างใบรับรองที่ถูกต้องในนามของคุณอย่างเงียบๆ

สรุปสำหรับธุรกิจของคุณ: หากไม่มีระเบียน CAA บริษัทใบรับรองหลายร้อยแห่งทั่วโลกแทบทุกแห่งสามารถออกใบรับรอง padlock จริงที่น่าเชื่อถือเต็มรูปแบบสำหรับโดเมนของคุณ — ทำให้นักต้มตุ๋นสามารถสร้างโคลนของเว็บไซต์ของคุณที่ดูสมบูรณ์แบบและ 'ปลอดภัย' เพื่อดักรับข้อมูล login และรายละเอียดบัตรของลูกค้าของคุณ โดยไม่มีสัญญาณเตือนบนหน้าจอ

สิ่งนี้อาจทำให้คุณเสียค่าใช้จ่าย

• นักต้มตุ๋นได้รับใบรับรองจริงสำหรับสำเนาเว็บไซต์ของคุณ ดังนั้นมันจึงแสดง padlock สีเขียวและ HTTPS — ลูกค้าของคุณไม่เห็นสิ่งผิดปกติ พิมพ์รหัสผ่านและหมายเลขบัตร และคุณรู้เรื่องนี้เมื่อ chargebacks และสายที่โกรธเริ่มมา
• ลูกค้าของคุณถูก phish ผ่านหน้า login look-alike ที่สมบูรณ์แบบ; ผลที่ตามมา — การคืนเงิน ภาระงาน support ความเสียหายต่อชื่อเสียง — ตกหนักที่แบรนด์ของคุณแม้ว่าเว็บไซต์จริงของคุณจะไม่ถูกแตะต้อง
• ทีมความปลอดภัยหรือการจัดซื้อของผู้มีโอกาสเป็นลูกค้ารันการตรวจสอบอย่างรวดเร็วบนโดเมนของคุณก่อนเซ็นสัญญา เห็นว่าไม่มีการป้องกัน CAA และทำเครื่องหมายคุณเงียบๆ ว่า 'อ่อนแอในพื้นฐาน' — ทำให้ดีลอยู่ในความเสี่ยงจาก setting ที่ใช้เวลาห้านาทีในการเพิ่ม
• หนึ่งในบริษัทใบรับรองของโลกถูก compromise (เกิดขึ้นซ้ำแล้วซ้ำเล่า — DigiNotar, Comodo, Symantec) และเพราะคุณไม่เคยบอกว่าใครได้รับอนุญาตให้ดำเนินการแทนคุณ โดเมนของคุณเปิดรับ CA ที่กลายเป็นจุดอ่อนที่สุด

เหตุใดจึงสำคัญ ขณะนี้ประตูเปิดกว้าง: บริษัทใบรับรองใดๆ บนโลกสามารถรับรองเว็บไซต์ที่อ้างว่าเป็นของคุณ ไม่ว่าคุณจะเคยติดต่อกับพวกมันหรือไม่ ระเบียน CAA ล็อคประตูนั้นเพื่อให้เฉพาะผู้ให้บริการที่คุณเลือกเท่านั้นที่สามารถออกใบรับรอง — มันเป็นการป้องกันที่ง่ายและถูกที่สุดที่มีต่อใครบางคนที่แอบอ้างเป็นธุรกิจของคุณออนไลน์

วิธีแก้ไข ทีละขั้นตอน

1. บันทึก certificate authority ของคุณ. แสดงรายการ CA ที่ออกใบรับรองของคุณ เช่น Let's Encrypt หรือ CA ของ host ของคุณ
2. เพิ่มระเบียน CAA. สร้างระเบียน CAA ที่ domain root เพื่ออนุญาตเฉพาะ CA เหล่านั้น เช่น 0 issue "letsencrypt.org"
3. ครอบคลุม wildcard และการแจ้งเตือน. เพิ่ม issuewild ถ้าคุณใช้ wildcard certs และ iodef mailto เพื่อรับการแจ้งเตือนเมื่อมีการละเมิด
4. ห้ามล็อคการต่ออายุ. ตรวจสอบให้แน่ใจว่า CA ทุกตัวที่คุณใช้จริงอยู่ในรายการ หรือการต่ออายุใบรับรองในอนาคตจะล้มเหลว
5. ยืนยันว่ามันทำงาน. ตรวจสอบใหม่เพื่อยืนยันว่าระเบียน CAA มีอยู่และมีรูปแบบที่ดี

ระเบียน CAA ในคำพูดง่ายๆ

เว็บไซต์ที่ปลอดภัยทุกแห่งมีใบรับรอง — สิ่งที่อยู่เบื้องหลัง padlock ในเบราว์เซอร์และ “https” ที่ด้านหน้าของที่อยู่ของคุณ ใบรับรองเหล่านั้นออกโดยบริษัทเฉพาะทางที่เรียกว่า certificate authorities (CA): ชื่อเช่น Let’s Encrypt, DigiCert, Sectigo, Google Trust Services เมื่อเบราว์เซอร์ของคุณเห็นใบรับรองที่ถูกต้อง มันแสดง padlock และบอกลูกค้าของคุณว่าการเชื่อมต่อเป็นของแท้และปลอดภัย

นี่คือส่วนที่เจ้าของธุรกิจส่วนใหญ่ไม่เคยได้รับแจ้ง: ตามค่าเริ่มต้น certificate authority หลายร้อยแห่งทั่วโลกแต่ละแห่งได้รับอนุญาตให้ออกใบรับรองสำหรับโดเมนของคุณ — ไม่ว่าคุณจะเคยได้ยินชื่อพวกมันหรือไม่ ระเบียน CAA (Certification Authority Authorization) คือบันทึกหนึ่งบรรทัดที่คุณเพิ่มในการตั้งค่า DNS ของโดเมนที่บอกว่า “เฉพาะผู้ให้บริการเหล่านี้เท่านั้นที่ได้รับอนุญาตให้ออกใบรับรองสำหรับฉัน” certificate authority ที่ถูกกฎหมายทุกแห่งจำเป็นต้องตรวจสอบบันทึกนั้นก่อนออก — และปฏิเสธถ้าพวกมันไม่อยู่ในรายการของคุณ

มันคือความแตกต่างระหว่างประตูด้านหน้าที่ไม่ล็อคที่ใครก็ตามสามารถเดินผ่านได้ และประตูที่มีเฉพาะคนที่คุณเลือกเท่านั้นที่ถือกุญแจ และมันไม่มีค่าใช้จ่ายในการเพิ่ม

สิ่งนี้อาจทำให้คุณสูญเสียอะไร

ความเสี่ยงที่ระเบียน CAA ปิดคือการแอบอ้างที่น่าเชื่อ เมื่อนักต้มตุ๋นสามารถรับใบรับรองจริงสำหรับสำเนาเว็บไซต์ของคุณ สัญญาณเตือนปกติจะหายไป — ไม่มี padlock ที่เสียหาย ไม่มีแบนเนอร์ “ไม่ปลอดภัย” ไม่มีข้อผิดพลาดใบรับรอง ทุกอย่างดูถูกต้อง ซึ่งเป็นเหตุผลที่ทำให้มันอันตราย

• สำเนาปลอมที่ไร้ที่ติ นักต้มตุ๋นลงทะเบียนที่อยู่ที่ดูเหมือน (หรือ compromise เส้นทางไปยังลูกค้าของคุณ) รับใบรับรองจริง และสร้างโคลนที่สมบูรณ์แบบของหน้า login หรือ checkout ของคุณ — พร้อม padlock ลูกค้าป้อนรหัสผ่านและหมายเลขบัตรตามปกติ คุณได้ยินเกี่ยวกับมันเป็น chargebacks รายงานการฉ้อโกง และสายโทรศัพท์ที่โกรธ

• แคมเปญ phishing ในชื่อของคุณ ผู้โจมตีส่งอีเมล “กรุณายืนยันบัญชีของคุณ” ที่ลิงก์ไปยังโคลนที่มีใบรับรองของเว็บไซต์ของคุณ เพราะหน้าดูปลอดภัยเต็มรูปแบบ คนตกหลุมพรางมากขึ้น การทำความสะอาด — การแจ้งลูกค้า การคืนเงิน ชั่วโมง support การชี้แจงสาธารณะที่น่าอึดอัด — ทั้งหมดตกที่คุณแม้ว่าเซิร์ฟเวอร์จริงของคุณจะไม่ถูกแตะต้อง

• ดีลที่หยุดชะงักบน checklist ทีมความปลอดภัยหรือการจัดซื้อของลูกค้าขนาดใหญ่สแกนโดเมนของคุณก่อนเซ็นสัญญา “ไม่มีระเบียน CAA” แสดงขึ้นเป็นรายการสีแดงหรือสีเหลืองอำพันข้างชื่อของคุณ มันเป็นสิ่งเล็กน้อยในเชิงเทคนิค แต่อ่านว่า “ไม่ครอบคลุมพื้นฐาน” และสามารถชะลอหรือทำลายสัญญาที่คุณจะชนะในกรณีอื่น

• ถูกจับได้จากการละเมิดของคนอื่น certificate authority ที่คุณไม่เคยติดต่อถูก compromise — นี่ไม่ใช่สมมติ; DigiNotar, Comodo และ Symantec ล้วนมีเหตุการณ์ร้ายแรง เพราะคุณไม่เคยจำกัดว่าใครสามารถดำเนินการแทนคุณ ผู้โจมตีสามารถรับใบรับรองที่ถูกต้องสำหรับโดเมนของคุณผ่าน CA ที่อ่อนแอนั้น ระเบียน CAA จะปฏิเสธพวกมัน

• จุดบอด wildcard แม้แต่ธุรกิจที่ระวังตัวเกี่ยวกับเว็บไซต์หลักของตนมักลืม subdomain หากไม่มีกฎ issuewild ผู้โจมตีที่สามารถรับใบรับรอง wildcard จะได้กุญแจสำหรับทุก subdomain ที่คุณจะเคยมีในคราวเดียว

มันคืออะไรจริงๆ และ “ดี” ดูเหมือนอะไร

ระเบียน CAA อยู่ใน DNS ของโดเมนของคุณ — การตั้งค่าเดียวกับที่ชี้โดเมนของคุณไปยังเว็บไซต์และอีเมล แต่ละระเบียนมีสามส่วน: flag, tag และ value tag ที่สำคัญคือ:

• issue — ระบุชื่อ certificate authority ที่ได้รับอนุญาตให้ออกใบรับรองปกติสำหรับโดเมนของคุณ คุณสามารถมีหลายรายการ หนึ่งต่อผู้ให้บริการที่คุณใช้จริง
• issuewild — ควบคุมใบรับรอง wildcard (ใบรับรองหนึ่งใบที่ครอบคลุมทุก subdomain เช่น *.example.com) ถ้าคุณไม่ใช้ wildcard การตั้งค่าที่แนะนำบล็อกพวกมันอย่างสมบูรณ์
• iodef — ที่อยู่ติดต่อเสริมที่คุณจะได้รับการแจ้งเตือนถ้า certificate authority ปฏิเสธคำขอเนื่องจากนโยบาย CAA ของคุณ นี่คือสัญญาณเตือนล่วงหน้าว่ามีคนพยายาม

“ดี” ดูเหมือน: มีระเบียน issue (หรือ issuewild) อย่างน้อยหนึ่งรายการ ระบุชื่อผู้ให้บริการที่คุณใช้จริง โดย wildcard ถูกจำกัดไว้กับผู้ให้บริการที่ระบุชื่อหรือถูกบล็อก โดเมนที่ไม่มีระเบียน CAA เลยถือว่าเป็นประตูที่เปิดอยู่อย่างที่มันเป็น

สิ่งนี้ส่งผลต่อเกรดของฉันไหม? ใช่ ระเบียน CAA ที่หายไปเป็นรายการที่ให้คะแนนและถูกทำเครื่องหมายด้วยความรุนแรงปานกลาง — มันเป็นช่องว่างจริง ไม่ใช่แค่ nice-to-have เพราะมันปล่อยให้เส้นทางการแอบอ้างจริงเปิดอยู่ การเพิ่มระเบียนปิดช่องว่างและล้างการค้นพบ

วิธีแก้ไข (ฟรี ~5 นาที)

ส่งส่วนนี้ให้ผู้ที่จัดการโดเมนหรือเว็บไซต์ของคุณ — การแก้ไขฟรี มันเป็นการเปลี่ยนแปลง DNS เล็กน้อย ไม่ใช่การสร้างใหม่

ขั้นตอนที่ 1 — ค้นหาว่าคุณใช้ certificate authority ใดจริงๆ นี่คือขั้นตอนเดียวที่ควรทำให้ถูกต้อง เพราะการแสดงรายการผู้ให้บริการที่ผิดสามารถบล็อกการต่ออายุครั้งต่อไปของคุณ กรณีทั่วไป:

• Let’s Encrypt — ใช้โดย host และ control panel หลายตัว (cPanel, Plesk) → letsencrypt.org
• Cloudflare (ถ้ามันออก edge certificate ของคุณ) → letsencrypt.org, digicert.com, comodoca.com, pki.goog และ ssl.com (Cloudflare ใช้ back-end CA หลายตัว; แสดงรายการที่ dashboard แสดง หรือชุดเต็มของมัน เพื่อให้การต่ออายุไม่เสียหาย)
• Google Workspace / Google Trust Services → pki.goog
• DigiCert → digicert.com
• Sectigo / Comodo → sectigo.com (และ comodoca.com)
• Microsoft 365 / Azure — Microsoft มักใช้ DigiCert สำหรับใบรับรองที่จัดการ → digicert.com (ยืนยันใน portal ของคุณ)

ถ้าไม่แน่ใจ ดูใบรับรองปัจจุบันในเบราว์เซอร์ (คลิก padlock → รายละเอียดใบรับรอง → “ออกโดย”) เพื่อดูว่าใครออกมัน

ขั้นตอนที่ 2 — เข้าสู่ระบบ DNS provider ของคุณ นี่คือที่ที่ระเบียนของโดเมนของคุณอยู่ — มักจะเป็น registrar, web host หรือ Cloudflare ของคุณ หาส่วนระเบียน DNS และเลือกเพิ่มระเบียนใหม่ประเภท CAA (บาง interface ระบุว่าประเภท 257)

ขั้นตอนที่ 3 — เพิ่มระเบียน issue สำหรับผู้ให้บริการแต่ละรายที่คุณใช้ สำหรับ Let’s Encrypt ตัวอย่างเช่น:

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

เพิ่มบรรทัด issue หนึ่งบรรทัดต่อผู้ให้บริการที่ถูกกฎหมาย DNS dashboard ส่วนใหญ่ให้ช่องแยกสำหรับ flag (0), tag (issue) และ value (โดเมนของ CA) ดังนั้นคุณไม่ต้องพิมพ์ทั้งบรรทัดด้วยมือ

ขั้นตอนที่ 4 — ควบคุมใบรับรอง wildcard ถ้าคุณไม่ได้ใช้ wildcard บล็อกพวกมันอย่างสมบูรณ์เพื่อให้ไม่มีใครสามารถรับอันหนึ่งอย่างเงียบๆ:

example.com.   CAA   0 issuewild ";"

ถ้าคุณใช้ wildcard ระบุชื่อผู้ให้บริการแทน: 0 issuewild "letsencrypt.org"

ขั้นตอนที่ 5 — (แนะนำ) เพิ่มที่อยู่การแจ้งเตือน เพื่อให้คุณได้รับแจ้งเมื่อ CA ปฏิเสธความพยายาม — สัญญาณเตือนล่วงหน้าของคุณว่ามีคนพยายาม:

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

ขั้นตอนที่ 6 — บันทึกและยืนยัน รัน dig CAA example.com (หรือใช้เครื่องมือ DNS lookup ออนไลน์ใดๆ) และยืนยันว่าระเบียนของคุณปรากฏขึ้น การเปลี่ยนแปลงอาจใช้เวลาตั้งแต่สองสามนาทีไปจนถึงสองสามชั่วโมงในการแพร่กระจายทั่วอินเทอร์เน็ต ใบรับรองที่มีอยู่และการต่ออายุทั้งหมดทำงานต่อเนื่องตลอดเวลา — CAA ควบคุมเฉพาะการออกใหม่

บันทึกแพลตฟอร์มด่วน: ใน Cloudflare, DNS → Records → Add record → ประเภท CAA ใน Google Workspace คุณจัดการ DNS ที่ registrar (หรือ Cloud DNS ถ้าคุณใช้) — เพิ่มระเบียน CAA ที่นั่นด้วย pki.goog ใน Microsoft 365 CAA ไม่ได้ตั้งค่าใน M365 admin centre; เพิ่มมันที่ใดก็ตามที่ DNS ของโดเมนของคุณโฮสต์ ระบุชื่อ CA ที่จัดการใบรับรอง (มักจะเป็น DigiCert) ในhost ทั่วไป (GoDaddy, Namecheap, Blacknight ฯลฯ) มันอยู่ใน DNS panel เดียวกับที่ระเบียน A และ MX ของคุณอยู่

ข้อผิดพลาดทั่วไป

• แสดงรายการ CA ที่ผิด — หรือลืมหนึ่งตัว ความเสี่ยงในโลกจริงที่ใหญ่ที่สุดไม่ใช่ความปลอดภัย มันคือการบล็อกการต่ออายุของตัวเอง ถ้าคุณใช้ผู้ออกมากกว่าหนึ่งราย (เช่น หนึ่งสำหรับเว็บไซต์หลักและอีกหนึ่งเบื้องหลัง Cloudflare) แสดงรายการทั้งหมด ถ้าไม่แน่ใจ แสดงรายการสองสามรายที่คุณไว้วางใจมากกว่าน้อยเกินไป
• ตั้งค่า issue แต่ไม่สนใจ wildcard โดเมนที่จำกัดใบรับรองปกติแต่ไม่พูดอะไรเกี่ยวกับ wildcard ยังปล่อยให้เส้นทาง wildcard ที่มีพลังมากกว่าเปิดอยู่ ตั้งค่า issuewild ด้วยเสมอ — ไม่ว่าจะเป็นผู้ให้บริการของคุณหรือ ";" เพื่อบล็อกมัน
• วาง CAA บนชื่อที่ผิด CAA ถูกอ่านโดย certificate authority สำหรับชื่อที่แน่นอนที่กำลังรับรอง โดยเดินขึ้นไปตาม tree การตั้งค่าที่ด้านบนของโดเมนของคุณ (apex เช่น example.com) เป็นการกระทำที่ถูกต้อง — มันครอบคลุม subdomain ตามค่าเริ่มต้นเว้นแต่ subdomain ตั้งค่าของตัวเอง
• สมมติว่าแพลตฟอร์มของคุณทำมันแล้ว Cloudflare, Google และ Microsoft จัดการใบรับรองแต่ไม่เพิ่มระเบียน CAA ให้คุณ เว้นแต่คุณเพิ่มมัน โดเมนของคุณยังเปิดอยู่
• ถือว่าเสร็จแล้วครั้งเดียวโดยไม่ monitoring การย้าย DNS ในภายหลัง การเปลี่ยน registrar หรือการ “ทำความสะอาด” ระเบียนสามารถทำให้การป้องกัน CAA ของคุณหายไปอย่างเงียบๆ ควรตรวจสอบว่ามันยังคงอยู่หลังจากการเปลี่ยนแปลง DNS ใดๆ

ชั้นเทคนิค (ส่งให้ผู้ดูแลระบบ IT ของคุณ)

CAA ถูกกำหนดใน RFC 8659 และบังคับใช้ภายใต้ CA/Browser Forum Baseline Requirements — CA ที่ถูกเชื่อถือสาธารณะทุกแห่งจำเป็นต้องตรวจสอบ CAA ในเวลาออก ระเบียนมีรูปแบบ <flags> <tag> <value> โดยมี tag issue, issuewild และ iodef นโยบาย issue หรือ issuewild ที่ไม่ว่างเปล่าคือสิ่งที่ทำให้การตรวจสอบนี้ผ่าน การมี iodef เพียงอย่างเดียวไม่ผ่าน (มันเป็น reporting ไม่ใช่ authorization)

baseline ที่ดีที่ apex:

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

บันทึกสำหรับผู้ implement:

• CAA tree-climbing: CA ประเมิน CAA จาก FQDN ที่ขอขึ้นไปยัง apex โดยหยุดที่ชื่อแรกที่มีชุดระเบียน CAA ระเบียนที่ apex ดังนั้นปกป้อง subdomain ทั้งหมดเว้นแต่ subdomain เผยแพร่ของตัวเอง ซึ่งสามารถทำได้ — มีประโยชน์ถ้า subdomain เฉพาะใช้ผู้ออกที่ต่างกัน
• value ; ใน issuewild หมายถึง “ไม่มี CA อาจออก wildcard” — การปฏิเสธอย่างชัดเจน ใช้มันเมื่อใดก็ตามที่ wildcard ไม่ได้เป็นส่วนหนึ่งของ setup ของคุณ
• flag 0 คือ issuer-critical flag; 0 (non-critical) ถูกต้องสำหรับการใช้งานปกติ หลีกเลี่ยงการตั้ง critical bit เว้นแต่คุณเข้าใจมันอย่างเต็มที่ เนื่องจาก critical tag ที่เข้าใจผิดสามารถทำให้ CA ที่สอดคล้องปฏิเสธการออก
• ผู้ออกหลายราย: ระเบียน issue หลายรายการได้รับอนุญาตและเป็นการบวก — แสดงรายการ CA ทุกตัวที่ถูกกฎหมายใน stack ของคุณ (รวมถึง back-end CA ที่ CDN/edge provider ของคุณใช้) เพื่อป้องกันความล้มเหลวในการต่ออายุ
• การ pair กับ DNSSEC: CAA บอก CA ว่าใครอาจออก; DNSSEC หยุดคำตอบ CAA เองจากการถูกปลอมแปลงระหว่างการส่ง พวกมันเสริมกัน — สำหรับโดเมนที่มีมูลค่าสูง รันทั้งสอง

ตั้งค่าบนโฮสต์ของคุณ

ทีละขั้นตอนสำหรับผู้ให้บริการยอดนิยม:

• ตั้งค่า CAA บน GoDaddy
• ตั้งค่า CAA บน Namecheap
• ตั้งค่า CAA บน Cloudflare
• ตั้งค่า CAA บน AWS Route 53

คำถามที่พบบ่อย