Certbot மூலம் Wildcard Certificate பெறுவது எப்படி?

Wildcard certificate-க்கு ஏன் DNS-01 தேவைப்படுகிறது

Wildcard certificate என்பது ஒரு domain-ன் அனைத்து முதல்-நிலை (first-level) subdomain-களையும் உள்ளடக்கும்: *.example.com என்பது app.example.com, blog.example.com மற்றும் ஒரு label ஆழம் கொண்ட பிற பெயர்கள் அனைத்திற்கும் பொருந்தும். Let's Encrypt, wildcard certificate-களை DNS-01 challenge மூலம் மட்டுமே வழங்குகிறது. எனவே, _acme-challenge.example.com-ல் ஒரு TXT record-ஐ பதிவிடுவதன் மூலம், அந்த domain-ன் DNS-ஐ கட்டுப்படுத்தும் அதிகாரம் தன்னிடம் உள்ளதை Certbot நிரூபிக்க வேண்டும். HTTP-01 challenge இதற்குப் பொருந்தாது; ஏனெனில், ஒரு token file-ஐ வழங்குவது அந்த குறிப்பிட்ட hostname-ஐ மட்டுமே கட்டுப்படுத்துவதை நிரூபிக்கும், validation server அந்த hostname-லிருந்துதான் கோப்பை பெற்றிருக்கும். Wildcard என்பது ஒரு domain-ன் கீழ் உள்ள அனைத்து சாத்தியமான பெயர்களுக்கும் உரிமைகோருவதாகும்; முழு namespace-க்கும் பொறுப்பான ஒரே பொதுவான record DNS மட்டுமே.

இந்த ஒரு தேவைதான் இந்தப் பக்கத்தில் உள்ள மற்ற அனைத்தையும் தீர்மானிக்கிறது. DNS-01 challenge-ஐ முடிக்க, நீங்கள் உங்கள் domain-ன் zone-ல் TXT record-களை உருவாக்க வேண்டும். இதை நீங்கள் நேரடியாகவோ அல்லது உங்கள் DNS provider-ன் API (application programming interface) மூலமாகவோ செய்யலாம். நேரடியாகச் செய்யும் முறை ஒருமுறை வேலை செய்யும், ஆனால் renewal-ன் போது தோல்வியடையும்; இதற்கான தெளிவான காரணம் கீழே கொடுக்கப்பட்டுள்ளது. Certbot DNS plugin மூலம் API-ஐப் பயன்படுத்தும் முறை, தானாகவே (unattended) புதுப்பித்துக்கொள்ளும்; இதுவே நீங்கள் கடைசியாக அமைக்க வேண்டிய முறையாகும்.

இது எங்கள் Certbot வழிகாட்டிகளின் wildcard அத்தியாயமாகும். சாதாரண single-hostname certificate-கள், web server configuration மற்றும் port 80 விதிகள் ஆகியவை Certbot with nginx on Ubuntu 24.04 மற்றும் Certbot with Apache on Ubuntu 24.04 ஆகியவற்றில் விளக்கப்பட்டுள்ளன.

_acme-challenge TXT record எவ்வாறு செயல்படுகிறது

Certbot *.example.com-ஐ கோரும்போது, Let's Encrypt ஒரு சீரற்ற (random) token-ஐ வழங்குகிறது. Certbot அந்த token-ஐ உங்கள் ACME (automatic certificate management environment) account key-உடன் இணைத்து, SHA-256 மூலம் hash செய்து, ஒரு சிறிய text மதிப்பை உருவாக்குகிறது. அந்த மதிப்பு _acme-challenge.example.com-ல் ஒரு TXT record-ஆக இருக்க வேண்டும். அதன் பிறகு, Let's Encrypt தனது சொந்த உள்கட்டமைப்பிலிருந்து உங்கள் domain-ன் authoritative name servers-ஐ வினவுகிறது (query). அது வாசிக்கும் record, அது எதிர்பார்க்கும் மதிப்புடன் ஒத்துப்போனால், நீங்கள் அந்த zone-ஐக் கட்டுப்படுத்துகிறீர்கள் என்பது உறுதியாகிறது. அந்த zone-ன் மீதான கட்டுப்பாடு, அதன் கீழ் உள்ள அனைத்து பெயர்களின் மீதான கட்டுப்பாடாகவும் ஏற்றுக்கொள்ளப்படுகிறது.

இரண்டு விவரங்கள் பெரும்பாலான தோல்விகளுக்குக் காரணமாகின்றன:

• ஒரே certificate-ல் example.com மற்றும் *.example.com ஆகியவற்றை கோருவது என்பது இரண்டு தனித்தனி சவால்களைக் குறிக்கிறது. இரண்டு TXT record-களும் ஒரே பெயரான _acme-challenge.example.com-ல் அமையும். இவை இரண்டும் ஒரே நேரத்தில் இருக்க வேண்டும். இரண்டாவது record-ஐச் சேர்ப்பது சரியானது; முதலாவதை நீக்கிவிட்டு இரண்டாவதைச் சேர்ப்பது முதல் சவாலைத் தோல்வியடையச் செய்யும்.
• Validation உங்கள் authoritative servers-ஐ வாசிக்கும். ஆனால், provider control panels ஒரு புதிய record-ஐ அவற்றிற்குப் பரப்புவதற்கு ஒரு நிமிடம் அல்லது அதற்கு மேல் எடுத்துக்கொள்ளலாம். validation தொடங்குவதற்கு முன்பே வெளியிலிருந்து சரிபார்க்கவும்:

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

அது Certbot கேட்ட மதிப்பை அச்சிடும்போது, validation வெற்றிபெற முடியும். அது எதையும் அச்சிடவில்லை என்றால், காத்திருந்து மீண்டும் இயக்கவும்.

செயல்பாட்டை ஒருமுறை பார்த்தல்: manual mode

Manual mode-ல் DNS மாற்றங்களை நீங்களே செய்ய வேண்டும். தானியங்கி முறைக்குச் செல்லும் முன், இதன் செயல்பாட்டைப் புரிந்துகொள்ள இதுவே சிறந்த வழி:

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

Wildcard-ஐச் சுற்றியுள்ள மேற்கோள் குறிகள் (quotes), *-ஐ ஒரு filename pattern-ஆக உங்கள் shell கருதுவதைத் தடுக்கின்றன. Certbot வழிமுறைகளுடன் காத்திருக்கும்:

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

உங்கள் DNS provider-ன் panel-ல் அந்த TXT record-ஐ உருவாக்கவும். மேலே உள்ள dig கட்டளையைப் பயன்படுத்தி அது தெரிகிறதா என்பதை உறுதிப்படுத்தவும். அதன் பிறகு Enter அழுத்தவும். இந்த run-ல் bare domain மற்றும் wildcard ஆகிய இரண்டிற்கும் கோரப்படுவதால், Certbot இருமுறை கேட்கும்; certificate வழங்கப்படும் வரை இரண்டு record-களையும் அப்படியே வைத்திருக்கவும். வெற்றி பெற்றால், வழக்கமான இந்த வரிகள் தோன்றும்:

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

manual mode ஏன் தானாகவே புதுப்பிக்க முடியாது

ஒவ்வொரு புதுப்பித்தலும் ஒரு புதிய token-ஐக் கொண்ட புதிய சவாலாகும், எனவே TXT மதிப்பு ஒவ்வொரு முறையும் மாறும். இன்று நீங்கள் பதிவிட்ட record 60 நாட்களில் பயனற்றதாகிவிடும். புதுப்பித்தல் டைமர் Certbot-ஐ ஒரு நாளைக்கு இரண்டு முறை தானாகவே இயக்குகிறது, அந்த நேரத்தில் புதிய மதிப்பை உள்ளிட யாரும் இருக்க மாட்டார்கள். எனவே, manual mode-ல் பெறப்பட்ட certificate இந்த குறிப்பிட்ட பிழையுடன் புதுப்பித்தலில் தோல்வியடையும்:

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.')

உங்கள் DNS provider-ன் API-ஐ அழைக்கும் --manual-auth-hook scripts-ஐ எழுதுவதன் மூலம் அந்தத் தேவையை நீங்கள் பூர்த்தி செய்யலாம், ஆனால் அந்த நிலையில் நீங்கள் ஒரு DNS plugin-ஐ நீங்களே மீண்டும் உருவாக்குகிறீர்கள் என்று அர்த்தம். செயல்முறையைப் புரிந்துகொள்ள அல்லது DNS-ஐ இன்னும் automate செய்ய முடியாத ஒரு domain-க்கு ஒருமுறை மட்டும் பயன்படுத்துவதற்கு manual mode-ஐப் பயன்படுத்தவும். 90-வது நாளுக்கு முன்பே ஒரு நினைவூட்டலை (reminder) அமைத்துக்கொள்ளுங்கள், ஏனெனில் Let's Encrypt இப்போது காலாவதி மின்னஞ்சல்களை அனுப்புவதில்லை. மற்ற அனைத்துத் தேவைகளுக்கும், ஒரு plugin-ஐப் பயன்படுத்தவும்.

Ubuntu 24.04-ல் certbot-dns-cloudflare plugin வழிமுறை

DNS plugin என்பது உங்கள் DNS வழங்குநருக்கான API credential-ஐப் பாதுகாத்து, சான்றிதழ் வழங்கல் மற்றும் ஒவ்வொரு முறை புதுப்பிக்கும்போதும் தேவைப்படும் TXT record தொடர்பான அனைத்து வேலைகளையும் தானாகவே செய்யும். பெரும்பாலான பயனர்களுக்குத் தேவைப்படும் வழங்குநர் plugin என்பதால், Cloudflare இங்கே உதாரணமாகக் காட்டப்பட்டுள்ளது; இது Ubuntu-வில் தொகுப்பாக (package) கிடைக்கிறது.

Ubuntu 24.04-ல் apt packages-ஐப் பயன்படுத்தவே எங்கள் Certbot வழிகாட்டிகள் பரிந்துரைக்கின்றன, Cloudflare-க்கும் அதே அணுகுமுறையே பொருந்தும்:

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

பதிப்புகள் குறித்த ஒரு தெளிவான குறிப்பு: 24.04 archive-ல் இந்த plugin 2.0.0 பதிப்பிலும், Certbot 2.9.0 பதிப்பிலும் உள்ளது; apt policy python3-certbot-dns-cloudflare மூலம் உங்களுடையதைச் சரிபார்க்கலாம். இந்த பதிப்பு வேறுபாடு எந்தப் பாதிப்பையும் ஏற்படுத்தாது. 24.04-ல் உள்ள அடிப்படை python3-cloudflare library 2.11.1 பதிப்பில் இருப்பதால், scoped API tokens சரியாகச் செயல்படும் (token ஆதரவிற்கு 2.3.1 பதிப்பு தேவை). பழைய Ubuntu பதிப்புகளில் இந்த library மிகவும் பழமையானதாக இருந்ததால், apt plugin-ஐப் பயன்படுத்தும்போது Global API Key-ஐ மட்டுமே பயன்படுத்த வேண்டும் என்ற எச்சரிக்கைகள் இணையத்தில் காணப்பட்டன. 24.04-ல் அந்த சிக்கல்கள் இல்லை.

Cloudflare dashboard-ல் Global API Key-க்கு பதிலாக, scoped API token-ஐ உருவாக்கவும்: My Profile என்பதற்குச் சென்று, பின் API Tokens, பிறகு Create Token என்பதைத் தேர்ந்தெடுக்கவும். இதில் Zone / DNS / Edit என்ற அனுமதியை மட்டும் வழங்கி, நீங்கள் சான்றிதழ் பெற விரும்பும் குறிப்பிட்ட zone-க்கு மட்டும் அதை வரையறுக்கவும். இதை 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 அதன் mode-ஐச் சரிபார்த்து Unsafe permissions on credentials configuration file குறித்து எச்சரிக்கும். இப்போது சான்றிதழைப் பெறவும்:

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

இந்த plugin API மூலம் TXT record-களை உருவாக்கி, அவை பரவுவதற்குச் சிறிது நேரம் காத்திருந்து, சரிபார்ப்பு முடிந்ததும் அந்த record-களை நீக்கிவிடும். உங்கள் zone-ன் name servers மாற்றங்களை ஏற்க தாமதமானால், --dns-cloudflare-propagation-seconds 60 மூலம் காத்திருப்பு நேரத்தை அதிகரிக்கவும். சான்றிதழ் /etc/letsencrypt/live/example.com/-ல் சேமிக்கப்படும். அடிப்படை வழிகாட்டிகளில் உள்ளவாறே, deploy hook-உடன் சேர்த்து fullchain.pem மற்றும் privkey.pem ஆகியவற்றை nginx அல்லது Apache-ல் குறிப்பிடவும்.

உங்கள் provider-ன் plugin apt-ல் இல்லை என்றால்

24.04 archive-ல் ஒரு சில providers-க்கான plugins மட்டுமே தொகுக்கப்பட்டுள்ளன; அவற்றில் Cloudflare, Route 53, DigitalOcean மற்றும் பொதுவான RFC 2136 interface ஆகியவை அடங்கும். பட்டியலைப் பார்க்க apt search certbot-dns-ஐ இயக்கவும். உங்கள் provider பட்டியலில் இல்லை என்றால், apt-ஐ முதலில் பயன்படுத்த வேண்டும் என்ற எங்கள் அறிவுரைக்கு விதிவிலக்காக, Certbot மற்றும் plugin-ஐ snap மூலம் நிறுவவும். இரண்டு renewal timers-ம் /etc/letsencrypt-க்காக மோதிக்கொள்ளாமல் இருக்க, apt Certbot-ஐ முதலில் நீக்கிவிடவும்:

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, snap Certbot-உடன் மட்டுமே இணையும்; அது apt பதிப்பை நீட்டிக்க முடியாது. இதனால்தான் இரண்டு நிறுவல்களும் ஒரே நேரத்தில் இருக்கக்கூடாது. உங்கள் DNS host எந்த API-யையும் வழங்கவில்லை என்றால், domain-ன் DNS-ஐ API வசதி கொண்ட provider-க்கு மாற்றுவது அல்லது நீங்களே ஒரு name server-ஐ இயக்கி, அதில் rfc2136 plugin-ஐ point செய்வது மட்டுமே நடைமுறைக்குச் சாத்தியமான வழிகள்.

புதுப்பித்தல்: 60 நாட்களுக்குப் பிறகு அல்ல, இப்போதே சரிபார்க்கவும்

ஒவ்வொரு certificate-ம் எவ்வாறு வழங்கப்பட்டது என்பதை Certbot /etc/letsencrypt/renewal/example.com.conf-ல் பதிவு செய்கிறது. இதில் authenticator = dns-cloudflare மற்றும் credentials path ஆகியவையும் அடங்கும். எனவே, தினசரி இருமுறை இயங்கும் standard timer, உங்கள் உதவியின்றி அதைத் தானாகவே புதுப்பிக்கும். staging environment-ஐப் பயன்படுத்தி முழு செயல்முறையையும் ஒத்திகை பார்க்கவும்:

sudo certbot renew --dry-run

இந்தச் சோதனை வெற்றி பெற்றால், credential சரியாக வேலை செய்கிறது மற்றும் validation முழுமையாக நிறைவடைகிறது என்று அர்த்தம்; 60 நாட்களுக்குப் பிறகு நடக்கும் உண்மையான புதுப்பித்தலும் இதே பாதையில்தான் நடக்கும். இன்று இரண்டு கூடுதல் நடவடிக்கைகளை மேற்கொள்வது அவசியம். முதலாவதாக, disk-ல் உள்ள certificate புதுப்பிக்கப்பட்டாலும், web server அதை reload செய்யும் வரை எந்த மாற்றமும் ஏற்படாது. எனவே, nginx மற்றும் Apache வழிகாட்டிகளில் விவரிக்கப்பட்டுள்ள deploy hook-ஐ இணைக்கவும். இரண்டாவதாக, credentials கோப்பைக் கவனமாகக் கையாளவும்: அதைப் படிக்கக்கூடிய எவரும் உங்கள் DNS zone-ஐத் திருத்த முடியும். இது உங்கள் மின்னஞ்சலைத் திசைதிருப்ப அல்லது அவர்களாகவே DNS-01 சவால்களைப் பூர்த்தி செய்யப் போதுமானது. இதை /root-ன் கீழ் mode 600-ல் வைத்திருக்கவும், token-ஐ ஒரு zone-க்கு மட்டும் கட்டுப்படுத்தவும், கசிவு ஏற்பட்டதாகச் சந்தேகித்தால் உடனடியாக அதை மாற்றவும் (rotate).

Wildcard தேவைப்படாத சூழல்கள்

பல subdomain-களுக்கு அல்லது முன்கூட்டியே கணிக்க முடியாத subdomain-களுக்கு wildcard ஒரு சிறந்த கருவியாகும். ஆனால், மற்ற அனைத்து சூழல்களுக்கும் இது இயல்பான தேர்வாக இருக்கக்கூடாது.

• ஒரு subdomain அல்லது சில குறிப்பிட்ட subdomain-கள் மட்டுமே இருந்தால்: சாதாரண SAN (subject alternative name) certificate பயன்படுத்துவது எளிமையானது. certbot --nginx -d example.com -d www.example.com -d app.example.com மூலம் plain HTTP-01 வழியாக 100 பெயர்கள் வரை பெறலாம், மேலும் எந்தவொரு DNS API credential-ஐயும் server-ல் சேமிக்க வேண்டிய அவசியமில்லை.
• ஒரு wildcard சரியாக ஒரு label-ஐ மட்டுமே பொருந்தும். *.example.com என்பது example.com-ஐ உள்ளடக்காது, அதனால்தான் மேலே உள்ள கட்டளைகள் இரண்டையும் கோருகின்றன. மேலும் இது a.b.example.com-ஐயும் உள்ளடக்காது; அதற்கு *.b.example.com தேவைப்படும்.
• அனைத்து subdomain-களுக்கும் ஒரே ஒரு private key மட்டுமே பயன்படுத்தப்படுகிறது. அந்த key இருக்கும் machine breached செய்யப்பட்டால், wildcard மூலம் பாதுகாக்கப்படும் அனைத்து பெயர்களும் ஒரே நேரத்தில் பாதிக்கப்படும்.
• உங்கள் container-களுக்கு Traefik மூலம் TLS (transport layer security) termination செய்யப்பட்டால், Certbot-ன் தேவை உங்களுக்கு இல்லை: Traefik தானே DNS-01 வழியாக wildcard certificates-ஐப் பெற்றுக்கொள்ளும், இதற்கு அதே வகையான provider token-ஐப் பயன்படுத்தலாம்.

Wildcard எப்போது உண்மையான பயனைத் தருகிறது என்றால்: நீங்கள் certificates-ஐ மீண்டும் மீண்டும் புதுப்பிக்கும் வேகத்தை விட, வாடிக்கையாளர் அல்லது application வாரியான subdomain-கள் வேகமாக உருவாக்கப்படும்போது, மற்றும் WireGuard VPN வழியாக மட்டுமே அணுகக்கூடிய internal hosts போன்ற public port 80 இல்லாத சூழல்களில் இது பயனுள்ளது. DNS-01 சரிபார்ப்பு முறை சான்றிதழ் பெறப்படும் host-உடன் நேரடியாகத் தொடர்பு கொள்ளாது, எனவே முற்றிலும் private-ஆன machine கூட publicly trusted certificate-ஐ வைத்திருக்க முடியும்.

FAQ

HTTP-01 மூலம் Certbot-ஆல் wildcard certificate-ஐ வழங்க முடியுமா?

முடியாது. HTTP-01 ஒரு குறிப்பிட்ட hostname-ன் கட்டுப்பாட்டை மட்டுமே உறுதிப்படுத்துகிறது, ஏனெனில் validation server அந்த குறிப்பிட்ட பெயரிலிருந்து ஒரு token file-ஐப் பெறுகிறது. ஒரு wildcard அந்த domain-ன் கீழ் உள்ள அனைத்து பெயர்களையும் உள்ளடக்கும் என்பதால், Let's Encrypt அதற்கு DNS-01 challenge-ஐக் கோருகிறது. மேலும், --nginx, --apache, --webroot மற்றும் --standalone ஆகிய authenticators அனைத்தும் HTTP-ஐ அடிப்படையாகக் கொண்டவை. இதற்கு ஒரே வழி _acme-challenge.example.com-ல் TXT record-ஐ உருவாக்குவது மட்டுமே; இதை நீங்களாகவோ அல்லது DNS plugin மூலமாகவோ செய்யலாம்.

Wildcard certificate root domain-ஐ உள்ளடக்குமா?

இல்லை. Wildcard சரியாக ஒரு label-ஐ மட்டுமே பொருந்தும். எனவே, *.example.com என்பது www.example.com-ஐ உள்ளடக்கும், ஆனால் bare example.com-ஐயோ அல்லது a.b.example.com-ஐயோ உள்ளடக்காது. -d example.com -d '*.example.com'-ஐப் பயன்படுத்தி ஒரே certificate-ல் இரண்டு பெயர்களையும் கோரலாம். இது இரண்டு சவால்களை (challenges) உருவாக்கும்; இரண்டு TXT record-களும் ஒரே _acme-challenge.example.com பெயரில் அமையும் என்பதால், முதல் record-ஐ நீக்காமல் இரண்டாவது record-ஐச் சேர்க்கவும்.

எனது wildcard certificate ஏன் தானாகப் புதுப்பிக்கப்படவில்லை?

ஏனெனில் அது --manual மூலம் வழங்கப்பட்டது. ஒவ்வொரு புதுப்பித்தலுக்கும் புதிய TXT மதிப்பு தேவைப்படுகிறது. தானியங்கி timer-ஆல் அதை உள்ளிட முடியாது என்பதால், An authentication script must be provided with --manual-auth-hook when using the manual plugin non-interactively பிழையுடன் புதுப்பித்தல் நின்றுவிடும். certbot-dns-cloudflare போன்ற DNS plugin-ஐப் பயன்படுத்தி certificate-ஐ மீண்டும் வழங்கவும், அல்லது உங்கள் provider-ன் API மூலம் record-ஐ மாற்றும் --manual-auth-hook மற்றும் --manual-cleanup-hook scripts-ஐ வழங்கவும்.

_acme-challenge TXT record தோன்றுவதற்கு எவ்வளவு காலம் ஆகும்?

இது உங்கள் DNS provider-ஐப் பொறுத்தது: சில நொடிகள் முதல் பல நிமிடங்கள் வரை ஆகலாம். Validation உங்கள் zone-ன் authoritative servers-ஐ வாசிக்கும். எனவே, dig +short TXT _acme-challenge.example.com @1.1.1.1 மூலம் சரிபார்த்து, manual run-ஐத் தொடரும் முன் எதிர்பார்க்கப்படும் மதிப்பு தோன்றும் வரை காத்திருக்கவும். Plugin-ஐப் பயன்படுத்தும் போது, validation-ல் record காணப்படவில்லை என்று பிழை வந்தால், plugin-ன் propagation option மூலம் காத்திருப்பு நேரத்தை அதிகரிக்கவும் (உதாரணமாக --dns-cloudflare-propagation-seconds 60).

சாதாரண certificate-ஐ விட wildcard certificate பாதுகாப்பு குறைவானதா?

Cryptography அடிப்படையில் இரண்டும் ஒன்றுதான். செயல்பாட்டு ரீதியாகவே மாற்றங்கள் உள்ளன: ஒரு private key அனைத்து subdomain-களையும் உள்ளடக்கும் என்பதால், ஒரு breach ஏற்பட்டால் பாதிப்பு அதிகமாக இருக்கும். மேலும், automation-க்குத் தேவைப்படும் DNS API credential-ஐ server-ல் சேமிப்பது ஒரு பாதுகாப்பு அபாயமாகும். நீங்கள் சில குறிப்பிட்ட subdomain-களை மட்டுமே இயக்கினால், SAN certificate இந்த இரண்டு சிக்கல்களையும் தவிர்க்கும். அத்தகைய சூழலில் wildcard-ஐத் தவிர்ப்பதே இந்த வழிகாட்டியின் பரிந்துரை.