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

เหตุใด wildcard certificate จึงต้องใช้ DNS-01

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

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

นี่คือบท wildcard ของคู่มือ Certbot ของเรา สำหรับ certificate แบบ single-hostname ทั่วไป การตั้งค่าเว็บเซิร์ฟเวอร์ และกฎของพอร์ต 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 ด้วยเช่นกัน

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

คลังซอฟต์แวร์ของ 24.04 มีแพ็กเกจ plugin สำหรับผู้ให้บริการเพียงไม่กี่ราย เช่น Cloudflare, Route 53, DigitalOcean และอินเทอร์เฟซ RFC 2136 ทั่วไป รัน apt search certbot-dns เพื่อดูรายการ หากไม่มีผู้ให้บริการของคุณ นี่คือกรณีเดียวที่เราแนะนำให้เปลี่ยนจาก apt: ให้ติดตั้ง Certbot และ plugin ผ่าน 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 plugin จะเชื่อมต่อกับ Certbot ที่เป็น snap เท่านั้น ไม่สามารถขยายขีดความสามารถของตัวที่เป็น apt ได้ นี่คือเหตุผลว่าทำไมการติดตั้งทั้งสองแบบจึงห้ามอยู่ร่วมกัน และหากโฮสต์ DNS ของคุณไม่มี API เลย คุณมีทางเลือกที่ทำได้จริง 3 ทาง: คุณสามารถย้าย DNS ของโดเมนไปยังผู้ให้บริการที่มี API, คุณสามารถรัน name server ของตนเองและชี้ plugin rfc2136 ไปที่นั่น หรือคุณสามารถใช้โฮสต์ DNS ปัจจุบันต่อไปและเพิ่ม CNAME แบบครั้งเดียวจาก _acme-challenge.example.com ไปยัง validation zone ที่มี API เช่น บริการ acme-dns ที่โฮสต์ไว้ หรือเซิร์ฟเวอร์ acme-dns ที่คุณรันเอง Let's Encrypt จะติดตาม CNAME นั้นระหว่างการตรวจสอบ ดังนั้น TXT record จะอยู่ใน zone ที่มอบหมายไว้ และ zone หลักของคุณจะไม่ต้องเปลี่ยนแปลงอีกเลย

การต่ออายุ: ทดสอบทันที ไม่ต้องรอ 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 certificate ด้วย HTTP-01 ได้หรือไม่?

ไม่ได้ HTTP-01 พิสูจน์การควบคุม hostname เดียว เพราะเซิร์ฟเวอร์ตรวจสอบจะดึงไฟล์ token จากชื่อนั้นโดยตรง แต่ wildcard ครอบคลุมทุกชื่อระดับแรกภายใต้โดเมน Let's Encrypt จึงกำหนดให้ใช้การตรวจสอบแบบ DNS-01 สำหรับกรณีนี้ และตัวตรวจสอบ --nginx, --apache, --webroot และ --standalone ทั้งหมดล้วนทำงานบนพื้นฐาน HTTP เส้นทางเดียวที่ทำได้คือการสร้าง TXT record ที่ _acme-challenge.example.com (หรือใน zone ที่ถูกมอบหมายผ่าน CNAME) โดยใส่ด้วยตนเองหรือใช้ DNS plugin

Wildcard certificate ครอบคลุมถึง root domain หรือไม่?

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

เหตุใด wildcard certificate ของฉันจึงไม่ต่ออายุโดยอัตโนมัติ?

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

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

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

Wildcard certificate มีความปลอดภัยน้อยกว่า certificate ปกติหรือไม่?

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