วิธีออกใบรับรอง Wildcard ด้วย Certbot ผ่าน DNS-01

เหตุใดใบรับรองแบบ wildcard จึงจำเป็นต้องใช้ DNS-01

ใบรับรองแบบ wildcard ครอบคลุมทุกโดเมนย่อยระดับแรกของโดเมนหลัก: *.example.com จะตรงกับ app.example.com, blog.example.com และชื่ออื่นใดก็ตามที่มีความลึกหนึ่งเลเบล Let's Encrypt ออกใบรับรองแบบ wildcard ผ่านการตรวจสอบแบบ DNS-01 เท่านั้น ดังนั้น Certbot จึงต้องพิสูจน์การควบคุม DNS ของโดเมนด้วยการเผยแพร่ระเบียน TXT ที่ _acme-challenge.example.com การตรวจสอบแบบ HTTP-01 ไม่สามารถใช้ได้ เนื่องจากไฟล์โทเค็นที่ให้บริการนั้นพิสูจน์ได้เพียงการควบคุมโฮสต์เนมเดียว ซึ่งเป็นโฮสต์เนมที่เซิร์ฟเวอร์ตรวจสอบดึงไฟล์ไป ใบรับรองแบบ wildcard เป็นการอ้างสิทธิ์ครอบคลุมทุกชื่อที่เป็นไปได้ภายใต้โดเมนนั้น และระเบียนสาธารณะเพียงอย่างเดียวที่สามารถยืนยันแทนเนมสเปซทั้งหมดได้คือตัว DNS เอง

ข้อกำหนดเพียงข้อเดียวนี้เป็นตัวกำหนดทุกอย่างที่เหลือในหน้านี้ เพื่อให้ผ่านการตรวจสอบแบบ DNS-01 คุณต้องสามารถสร้างระเบียน TXT ในโซนของโดเมนได้ ไม่ว่าจะด้วยตนเองหรือผ่าน API (application programming interface) ของผู้ให้บริการ DNS ของคุณ วิธีการทำด้วยตนเองจะใช้งานได้เพียงครั้งเดียวและจะล้มเหลวเมื่อถึงเวลาต่ออายุ ด้วยเหตุผลที่เป็นรูปธรรมซึ่งแสดงไว้ด้านล่าง ส่วนวิธีการผ่าน API โดยใช้ปลั๊กอิน DNS ของ Certbot จะช่วยให้การต่ออายุเป็นไปโดยอัตโนมัติ ซึ่งเป็นรูปแบบการตั้งค่าที่คุณควรเลือกใช้ในท้ายที่สุด

นี่คือบทเกี่ยวกับ wildcard ในคู่มือ Certbot ของเรา สำหรับใบรับรองแบบโฮสต์เนมเดี่ยวทั่วไป การกำหนดค่าเว็บเซิร์ฟเวอร์ และกฎสำหรับพอร์ต 80 ได้รับการครอบคลุมไว้ใน Certbot กับ nginx บน Ubuntu 24.04 และ Certbot กับ Apache บน Ubuntu 24.04

การทำงานของระเบียน TXT สำหรับ _acme-challenge

เมื่อ Certbot ร้องขอ *.example.com ทาง Let's Encrypt จะตอบกลับด้วยโทเค็นแบบสุ่ม Certbot จะนำโทเค็นนั้นไปรวมกับคีย์บัญชี ACME (automatic certificate management environment) ของคุณ จากนั้นทำการแฮชผลลัพธ์ด้วย SHA-256 เพื่อสร้างค่าข้อความสั้นๆ ค่าดังกล่าวจะต้องปรากฏเป็นระเบียน TXT ที่ _acme-challenge.example.com จากนั้น Let's Encrypt จะสอบถามไปยังเนมเซิร์ฟเวอร์ที่เป็นผู้มีอำนาจ (authoritative name servers) ของโดเมนคุณจากโครงสร้างพื้นฐานของตนเอง หากระเบียนที่อ่านได้ตรงกับค่าที่คาดหวัง ถือว่าคุณได้พิสูจน์แล้วว่าคุณเป็นผู้ควบคุมโซนนั้น และการควบคุมโซนจะถือว่าเป็นการควบคุมชื่อทั้งหมดที่อยู่ภายใต้โซนนั้นด้วย

รายละเอียดสองประการที่มักทำให้เกิดความล้มเหลว:

• การร้องขอ example.com และ *.example.com ในใบรับรองเดียวกันหมายถึงการตรวจสอบสองรายการแยกกัน และระเบียน TXT ทั้งสองรายการจะต้องอยู่ที่ชื่อเดียวกันคือ _acme-challenge.example.com ทั้งสองระเบียนต้องมีอยู่พร้อมกัน การเพิ่มระเบียนที่สองนั้นถูกต้อง แต่การแทนที่ระเบียนแรกด้วยระเบียนที่สองจะทำให้การตรวจสอบรายการแรกล้มเหลว
• การตรวจสอบจะอ่านจากเซิร์ฟเวอร์ที่เป็นผู้มีอำนาจของคุณ แต่แผงควบคุมของผู้ให้บริการอาจใช้เวลาหนึ่งนาทีหรือมากกว่านั้นในการเผยแพร่ระเบียนใหม่ไปยังเซิร์ฟเวอร์เหล่านั้น ให้ตรวจสอบจากภายนอกก่อนที่คุณจะเริ่มการตรวจสอบ:

dig +short TXT _acme-challenge.example.com @1.1.1.1

เมื่อคำสั่งดังกล่าวแสดงค่าที่ Certbot ร้องขอ การตรวจสอบจึงจะสำเร็จ หากไม่แสดงผลลัพธ์ใดๆ ให้รอสักครู่แล้วลองเรียกใช้คำสั่งใหม่อีกครั้ง

ทดสอบการทำงานหนึ่งครั้ง: โหมดกำหนดเอง (manual mode)

โหมดกำหนดเองบังคับให้คุณแก้ไขค่า DNS ด้วยตนเอง ซึ่งเป็นวิธีที่ดีที่สุดในการทำความเข้าใจกลไกการทำงานก่อนที่จะเริ่มใช้งานแบบอัตโนมัติ:

sudo certbot certonly --manual --preferred-challenges dns -d example.com -d '*.example.com'

การใส่เครื่องหมายคำพูดครอบตัว wildcard จะช่วยป้องกันไม่ให้เชลล์ของคุณตีความ * ว่าเป็นรูปแบบชื่อไฟล์ Certbot จะหยุดรอพร้อมแสดงคำแนะนำ:

Please deploy a DNS TXT record under the name:
_acme-challenge.example.com.
with the following value:
Jx9mQ2wLr8vTn5cKp0aYdG3hB7fZs4eN1oiRuXqMk6E

ให้สร้างระเบียน TXT ดังกล่าวในแผงควบคุมของผู้ให้บริการ DNS ของคุณ ตรวจสอบให้แน่ใจว่าระเบียนนั้นมองเห็นได้ด้วยคำสั่ง dig ที่ระบุไว้ข้างต้น แล้วจึงกด Enter เนื่องจากการรันคำสั่งนี้เป็นการร้องขอทั้งโดเมนหลักและ wildcard ตัว Certbot จึงจะแจ้งเตือนสองครั้ง ให้คงระเบียนทั้งสองไว้จนกว่ากระบวนการออกใบรับรองจะเสร็จสิ้น ความสำเร็จจะแสดงด้วยบรรทัดที่คุ้นเคยดังนี้:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem

เหตุใดโหมด manual จึงไม่สามารถต่ออายุใบรับรองด้วยตนเองได้

การต่ออายุทุกครั้งถือเป็นความท้าทายใหม่ที่มาพร้อมกับโทเค็นชุดใหม่ ดังนั้นค่า TXT จึงเปลี่ยนแปลงไปในทุกครั้งที่ดำเนินการ เรคคอร์ดที่คุณคัดลอกมาในวันนี้จะใช้งานไม่ได้อีกใน 60 วัน ตัวตั้งเวลาต่ออายุจะเรียกใช้งาน Certbot แบบอัตโนมัติวันละ 2 ครั้ง และไม่มีผู้ดูแลระบบคอยเฝ้าหน้าจอเพื่อคัดลอกค่าใหม่ไปวาง ดังนั้นใบรับรองที่ออกโดยโหมด manual จึงไม่สามารถต่ออายุได้และจะแสดงข้อผิดพลาดนี้:

Failed to renew certificate example.com with error: The manual plugin is not
working; there may be problems with your existing configuration.
The error was: PluginError('An authentication script must be provided with
--manual-auth-hook when using the manual plugin non-interactively.')

คุณสามารถตอบสนองความต้องการดังกล่าวได้ด้วยการเขียนสคริปต์ --manual-auth-hook เพื่อเรียกใช้งาน API ของผู้ให้บริการ DNS ของคุณ แต่ในจุดนั้นเท่ากับว่าคุณกำลังสร้าง DNS plugin ขึ้นมาใหม่ด้วยตนเอง ให้ใช้โหมด manual เพื่อเรียนรู้ขั้นตอนการทำงาน หรือใช้สำหรับกรณีที่จำเป็นต้องทำเพียงครั้งเดียวบนโดเมนที่คุณยังไม่สามารถทำระบบอัตโนมัติสำหรับ DNS ได้ และควรตั้งการแจ้งเตือนไว้ก่อนถึงวันที่ 90 เนื่องจาก Let's Encrypt ไม่ส่งอีเมลแจ้งเตือนวันหมดอายุอีกต่อไป สำหรับกรณีอื่นๆ ทั้งหมด ให้ใช้ plugin แทน

แนวทางการใช้ปลั๊กอิน: certbot-dns-cloudflare บน Ubuntu 24.04

DNS plugin จะเก็บข้อมูลรับรอง API สำหรับผู้ให้บริการ DNS ของคุณ และดำเนินการจัดการระเบียน TXT ทั้งหมดด้วยตนเอง ทั้งในขั้นตอนการออกใบรับรองและขั้นตอนการต่ออายุ Cloudflare เป็นตัวอย่างที่นำมาใช้ในที่นี้เนื่องจากเป็นปลั๊กอินของผู้ให้บริการที่คนส่วนใหญ่ต้องการใช้งาน และมีแพ็กเกจให้พร้อมใช้งานบน Ubuntu

คู่มือ Certbot ของเราแนะนำให้ใช้แพ็กเกจ apt บน Ubuntu 24.04 และแนวทางนี้ยังคงใช้ได้กับ Cloudflare:

sudo apt update
sudo apt install certbot python3-certbot-dns-cloudflare

ข้อเท็จจริงเกี่ยวกับเวอร์ชัน: คลังซอฟต์แวร์ของ 24.04 มีปลั๊กอินนี้ที่เวอร์ชัน 2.0.0 ควบคู่ไปกับ Certbot 2.9.0 โดย apt policy python3-certbot-dns-cloudflare จะแสดงเวอร์ชันของคุณ ความไม่ตรงกันของเวอร์ชันนี้ไม่มีผลเสีย และการใช้ scoped API token สามารถทำได้ เนื่องจากไลบรารี python3-cloudflare พื้นฐานใน 24.04 เป็นเวอร์ชัน 2.11.1 ซึ่งสูงกว่าเวอร์ชัน 2.3.1 ที่ปลั๊กอินต้องการสำหรับการรองรับ token ใน Ubuntu เวอร์ชันเก่า ไลบรารีดังกล่าวมีเวอร์ชันเก่าเกินกว่าจะรองรับ token ซึ่งเป็นที่มาของคำเตือนที่คุณอาจพบในอินเทอร์เน็ตเกี่ยวกับการที่ปลั๊กอิน apt บังคับให้ใช้ Global API Key แต่สำหรับ 24.04 คำเตือนเหล่านั้นไม่มีผลอีกต่อไป

ในแดชบอร์ดของ Cloudflare ให้สร้าง scoped API token แทนการใช้ Global API Key โดยไปที่ My Profile จากนั้นเลือก API Tokens แล้วเลือก Create Token โดยกำหนดสิทธิ์เพียงรายการเดียวคือ Zone / DNS / Edit และจำกัดขอบเขตไว้เฉพาะโซนที่คุณต้องการออกใบรับรองเท่านั้น จากนั้นบันทึกลงในไฟล์ที่เฉพาะ root เท่านั้นที่อ่านได้:

sudo mkdir -p /root/.secrets
sudo tee /root/.secrets/cloudflare.ini > /dev/null <<'EOF'
dns_cloudflare_api_token = paste_your_scoped_token_here
EOF
sudo chmod 600 /root/.secrets/cloudflare.ini

Certbot จะตรวจสอบโหมดของไฟล์และแจ้งเตือนเกี่ยวกับ Unsafe permissions on credentials configuration file หากไฟล์ดังกล่าวอนุญาตให้ผู้อื่นอ่านได้ จากนั้นให้ดำเนินการออกใบรับรอง:

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cloudflare.ini \
  -d example.com -d '*.example.com'

ปลั๊กอินจะสร้างระเบียน TXT ผ่าน API รอเวลาการแพร่กระจายข้อมูล (propagation delay) สั้นๆ ปล่อยให้กระบวนการตรวจสอบทำงาน แล้วจึงลบระเบียนเหล่านั้นทิ้ง หากเนมเซิร์ฟเวอร์ของโซนคุณมีการอัปเดตข้อมูลช้า ให้เพิ่มระยะเวลารอด้วย --dns-cloudflare-propagation-seconds 60 ใบรับรองจะถูกจัดเก็บไว้ใน /etc/letsencrypt/live/example.com/ และคุณสามารถกำหนดค่า nginx หรือ Apache ให้ชี้ไปยัง fullchain.pem และ privkey.pem ได้ตามที่ระบุไว้ในคู่มือพื้นฐาน รวมถึงการตั้งค่า deploy hook ด้วยเช่นกัน

หากปลั๊กอินของผู้ให้บริการของคุณไม่อยู่ใน apt

คลังซอฟต์แวร์ของ 24.04 มีการจัดทำแพ็กเกจปลั๊กอินไว้สำหรับผู้ให้บริการเพียงไม่กี่รายเท่านั้น ซึ่งรวมถึง Cloudflare, Route 53, DigitalOcean และอินเทอร์เฟซ RFC 2136 แบบทั่วไป ให้รันคำสั่ง apt search certbot-dns เพื่อดูรายการดังกล่าว หากไม่มีผู้ให้บริการของคุณอยู่ในรายการ นี่เป็นกรณีเดียวที่เราจะยกเว้นคำแนะนำที่ให้ใช้ apt เป็นอันดับแรก โดยให้คุณติดตั้ง Certbot และปลั๊กอินผ่านทาง snap แทน และลบ Certbot ที่ติดตั้งผ่าน apt ออกก่อน เพื่อป้องกันไม่ให้ตัวตั้งเวลาการต่ออายุสองตัวทำงานทับซ้อนกันบน /etc/letsencrypt:

sudo apt remove certbot python3-certbot-dns-cloudflare
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
sudo snap set certbot trust-plugin-with-root=ok
sudo snap install certbot-dns-yourprovider

ปลั๊กอินแบบ snap จะเชื่อมต่อกับ Certbot แบบ snap เท่านั้น ไม่สามารถขยายขีดความสามารถของตัวที่ติดตั้งผ่าน apt ได้ ซึ่งเป็นเหตุผลว่าทำไมการติดตั้งทั้งสองแบบจึงไม่สามารถอยู่ร่วมกันได้ และหากผู้ให้บริการ DNS ของคุณไม่มี API ให้ใช้งานเลย ทางเลือกที่เป็นไปได้ในทางปฏิบัติคือการย้าย DNS ของโดเมนไปยังผู้ให้บริการที่มี API หรือการรัน name server ของคุณเองแล้วชี้ปลั๊กอิน rfc2136 ไปที่เซิร์ฟเวอร์นั้น

การต่ออายุ: ทดสอบทันที ไม่ต้องรอ 60 วัน

Certbot จะบันทึกวิธีการออกใบรับรองแต่ละรายการไว้ใน /etc/letsencrypt/renewal/example.com.conf ซึ่งรวมถึง authenticator = dns-cloudflare และพาธของข้อมูลรับรอง ดังนั้นตัวตั้งเวลามาตรฐานที่ทำงานวันละ 2 ครั้งจะทำการต่ออายุให้โดยที่คุณไม่ต้องดำเนินการใดๆ ให้ทดสอบกระบวนการทั้งหมดกับสภาพแวดล้อม staging:

sudo certbot renew --dry-run

หากผลลัพธ์ผ่าน หมายความว่าข้อมูลรับรองใช้งานได้และการตรวจสอบความถูกต้องเสร็จสมบูรณ์ตั้งแต่ต้นจนจบ การต่ออายุจริงในอีก 60 วันข้างหน้าจะใช้เส้นทางเดียวกันนี้ มีสิ่งที่ควรดำเนินการเพิ่มเติม 2 ประการในวันนี้ ประการแรก ใบรับรองที่ต่ออายุแล้วในดิสก์จะไม่มีผลจนกว่าเว็บเซิร์ฟเวอร์จะโหลดใหม่ ดังนั้นให้ตั้งค่า deploy hook ตามที่อธิบายไว้ในคู่มือของ nginx และ Apache ประการที่สอง ให้ดูแลไฟล์ข้อมูลรับรองอย่างเคร่งครัด ผู้ที่สามารถอ่านไฟล์นี้ได้จะสามารถแก้ไข DNS zone ของคุณได้ ซึ่งเพียงพอต่อการเปลี่ยนเส้นทางอีเมลหรือผ่านการตรวจสอบ DNS-01 ด้วยตนเอง ให้ตั้งค่าโหมดเป็น 600 ภายใต้ /root จำกัดขอบเขตของโทเค็นไว้เพียงหนึ่งโซน และหมุนเวียนโทเค็นหากคุณสงสัยว่ามีการรั่วไหลเกิดขึ้น

เมื่อคุณไม่จำเป็นต้องใช้ wildcard

Wildcard เป็นเครื่องมือที่เหมาะสมสำหรับโดเมนย่อยจำนวนมาก หรือโดเมนย่อยที่คุณไม่สามารถคาดการณ์ล่วงหน้าได้ แต่มันไม่ใช่ค่าเริ่มต้นที่เหมาะสมสำหรับกรณีอื่นทั้งหมด

• สำหรับหนึ่งโดเมนย่อยหรือโดเมนย่อยจำนวนหนึ่งที่ทราบชื่อชัดเจน: การใช้ใบรับรอง SAN (subject alternative name) ปกติจะง่ายกว่า certbot --nginx -d example.com -d www.example.com -d app.example.com รองรับชื่อได้สูงสุด 100 ชื่อผ่าน HTTP-01 แบบปกติ และไม่ต้องเก็บข้อมูลรับรอง DNS API ไว้บนเซิร์ฟเวอร์
• Wildcard จะจับคู่กับ label ได้เพียงหนึ่งระดับเท่านั้น *.example.com ไม่ครอบคลุมถึง example.com แบบเปล่าๆ ซึ่งเป็นเหตุผลว่าทำไมคำสั่งข้างต้นจึงร้องขอทั้งสองอย่าง และมันก็ไม่ครอบคลุมถึง a.b.example.com ด้วยเช่นกัน กรณีนั้นจำเป็นต้องใช้ *.b.example.com
• กุญแจส่วนตัว (private key) หนึ่งชุดจะถูกใช้สำหรับทุกโดเมนย่อย หากเครื่องที่เก็บกุญแจนี้ถูกบุกรุก ทุกชื่อที่ wildcard ครอบคลุมจะได้รับผลกระทบพร้อมกันทั้งหมด
• หาก Traefik ทำหน้าที่ยุติการเชื่อมต่อ TLS (transport layer security) ให้กับคอนเทนเนอร์ของคุณ คุณไม่จำเป็นต้องใช้ Certbot เลย: Traefik ร้องขอใบรับรอง wildcard ด้วยตัวเองผ่าน DNS-01 โดยใช้โทเค็นของผู้ให้บริการประเภทเดียวกัน

กรณีที่ wildcard มีประโยชน์อย่างแท้จริงคือ: โดเมนย่อยสำหรับลูกค้าแต่ละรายหรือแอปพลิเคชันแต่ละตัวที่ถูกสร้างขึ้นเร็วกว่าที่คุณต้องการออกใบรับรองใหม่ และโฮสต์ภายในที่ไม่มีพอร์ต 80 สาธารณะ เช่น บริการที่เข้าถึงได้ผ่าน WireGuard VPN เท่านั้น เนื่องจาก DNS-01 ไม่จำเป็นต้องเชื่อมต่อกับโฮสต์ที่กำลังขอใบรับรอง ดังนั้นแม้แต่เครื่องที่เป็นส่วนตัวโดยสมบูรณ์ก็สามารถถือใบรับรองที่ได้รับความเชื่อถือในระดับสาธารณะได้

FAQ

Certbot สามารถออกใบรับรองแบบ wildcard ด้วยวิธี HTTP-01 ได้หรือไม่?

ไม่ได้ วิธี HTTP-01 ใช้พิสูจน์การควบคุมชื่อโฮสต์เพียงชื่อเดียว เนื่องจากเซิร์ฟเวอร์ตรวจสอบจะดึงไฟล์โทเค็นจากชื่อนั้นโดยตรง แต่ใบรับรองแบบ wildcard ครอบคลุมทุกชื่อภายใต้โดเมนนั้น Let's Encrypt จึงกำหนดให้ใช้การตรวจสอบแบบ DNS-01 สำหรับใบรับรองประเภทนี้ และตัวตรวจสอบ --nginx, --apache, --webroot และ --standalone ทั้งหมดทำงานบนพื้นฐานของ HTTP วิธีเดียวที่ทำได้คือการสร้างระเบียน TXT ที่ _acme-challenge.example.com โดยการเพิ่มด้วยตนเองหรือใช้ปลั๊กอิน DNS

ใบรับรองแบบ wildcard ครอบคลุมถึงโดเมนหลัก (root domain) หรือไม่?

ไม่ครอบคลุม ใบรับรองแบบ wildcard จะจับคู่กับป้ายชื่อ (label) ได้เพียงระดับเดียว ดังนั้น *.example.com จะครอบคลุม www.example.com แต่ไม่รวมถึง example.com ที่เป็นโดเมนเปล่า และไม่รวมถึง a.b.example.com คุณควรขอใบรับรองสำหรับทั้งสองชื่อพร้อมกันโดยใช้ -d example.com -d '*.example.com' ซึ่งจะสร้างการตรวจสอบสองรายการ และระเบียน TXT ทั้งสองจะอยู่ที่ชื่อ _acme-challenge.example.com เดียวกัน ดังนั้นให้เพิ่มระเบียนที่สองโดยไม่ต้องลบระเบียนแรกออก

ทำไมใบรับรองแบบ wildcard ของฉันถึงไม่ต่ออายุโดยอัตโนมัติ?

เนื่องจากใบรับรองถูกออกด้วย --manual การต่ออายุแต่ละครั้งต้องใช้ค่า TXT ใหม่เสมอ และตัวตั้งเวลาทำงานอัตโนมัติไม่มีวิธีใส่ค่าดังกล่าวได้ การต่ออายุจึงหยุดลงพร้อมกับข้อผิดพลาด An authentication script must be provided with --manual-auth-hook when using the manual plugin non-interactively ให้ทำการออกใบรับรองใหม่โดยใช้ปลั๊กอิน DNS เช่น certbot-dns-cloudflare หรือจัดเตรียมสคริปต์ --manual-auth-hook และ --manual-cleanup-hook เพื่อแก้ไขระเบียนผ่าน API ของผู้ให้บริการของคุณ

ระเบียน TXT แบบ _acme-challenge ต้องใช้เวลานานเท่าใดจึงจะปรากฏ?

ขึ้นอยู่กับผู้ให้บริการ DNS ของคุณ ซึ่งอาจใช้เวลาตั้งแต่ไม่กี่วินาทีไปจนถึงหลายนาที กระบวนการตรวจสอบจะอ่านข้อมูลจากเซิร์ฟเวอร์ที่เป็น authoritative ของโซนคุณ ดังนั้นให้ตรวจสอบด้วย dig +short TXT _acme-challenge.example.com @1.1.1.1 และรอจนกว่าค่าที่คาดหวังจะปรากฏขึ้นก่อนที่จะดำเนินการต่อในโหมด manual หากใช้ปลั๊กอิน ให้เพิ่มระยะเวลารอคอยผ่านตัวเลือก propagation ของปลั๊กอิน เช่น --dns-cloudflare-propagation-seconds 60 หากผลการตรวจสอบแจ้งว่าไม่พบระเบียนดังกล่าว

ใบรับรองแบบ wildcard มีความปลอดภัยน้อยกว่าใบรับรองปกติหรือไม่?

ในด้านการเข้ารหัสลับนั้นเหมือนกันทุกประการ ความแตกต่างอยู่ที่การปฏิบัติงาน: กุญแจส่วนตัว (private key) หนึ่งชุดจะครอบคลุมทุกโดเมนย่อย ดังนั้นหากถูกบุกรุกจะส่งผลกระทบในวงกว้างกว่า และข้อมูลรับรอง DNS API ที่จำเป็นสำหรับการทำงานอัตโนมัติถือเป็นความลับที่สำคัญซึ่งจัดเก็บไว้บนเซิร์ฟเวอร์ หากคุณใช้งานโดเมนย่อยเพียงไม่กี่ชื่อที่ทราบแน่ชัด การใช้ใบรับรองแบบ SAN จะช่วยหลีกเลี่ยงข้อกังวลทั้งสองประการนี้ ซึ่งเป็นเหตุผลที่คู่มือนี้แนะนำให้ข้ามการใช้ wildcard ในกรณีดังกล่าว