Certbot wildcard certificate DNS-01 எப்படி பெறுவது

ஒரு வைல்டுகார்டு சான்றிதழுக்கு DNS-01 ஏன் தேவை

ஒரு வைல்டுகார்டு சான்றிதழ் ஒரு டொமைனின் அனைத்து முதல்நிலை சப்டொமைன்களையும் உள்ளடக்கும்: *.example.com என்பது app.example.com, blog.example.com, மற்றும் ஒரு லேபிள் ஆழத்தில் உள்ள வேறு எந்தப் பெயரையும் பொருந்தும். Let's Encrypt வைல்டுகார்டு சான்றிதழ்களை DNS-01 சவால் வழியாக மட்டுமே வழங்குகிறது. எனவே, _acme-challenge.example.com இல் ஒரு TXT ரெக்கார்டை வெளியிடுவதன் மூலம் டொமைனின் DNS கட்டுப்பாட்டை Certbot நிரூபிக்க வேண்டும். HTTP-01 சவால் தகுதியாகாது. ஏனெனில், ஒரு டோக்கன் கோப்பை வழங்குவது ஒரு ஹோஸ்ட்பெயரின் கட்டுப்பாட்டை மட்டுமே நிரூபிக்கிறது. அது வாலிடேஷன் சர்வர் கோப்பை எடுத்த அதே ஹோஸ்ட்பெயர் ஆகும். வைல்டுகார்டு என்பது டொமைனுக்கு கீழ் உள்ள ஒவ்வொரு சாத்தியமான பெயரைப் பற்றிய கோரிக்கையாகும். முழு நேம்ஸ்பேஸையும் பிரதிநிதித்துவப்படுத்தும் ஒரே பொது ரெக்கார்டு DNS ஆகும்.

அந்த ஒரு தேவையே இந்தப் பக்கத்தில் உள்ள மற்ற அனைத்தையும் தீர்மானிக்கிறது. DNS-01 ஐ நிறைவேற்ற, டொமைனின் ஜோனில் TXT ரெக்கார்டுகளை உருவாக்கும் திறன் நீங்கள் கொண்டிருக்க வேண்டும். இதை கைமுறையாகவோ அல்லது உங்கள் DNS வழங்குநரின் API (application programming interface) வழியாகவோ செய்யலாம். கைமுறை வழி ஒரு முறை வேலை செய்கிறது. பின்னர் புதுப்பித்தலின் போது தோல்வியடைகிறது. இதற்கு கீழே காட்டப்பட்டுள்ள ஒரு குறிப்பிட்ட காரணம் உள்ளது. ஒரு Certbot DNS ப்ளகஇன் வழியாக செல்லும் API வழி, கவனிப்பு இல்லாமலேயே புதுப்பிக்கிறது. இதுவே நீங்கள் இறுதியாக அமைத்துக் கொள்ள வேண்டிய அமைப்பாகும்.

இது எங்கள் Certbot வழிகாட்டிகளின் வைல்டுகார்டு அத்தியாயம் ஆகும். சாதாரண ஒற்றை-ஹோஸ்ட்பெயர் சான்றிதழ்கள், வெப் சர்வர் கட்டமைப்பு மற்றும் port 80 விதிகள் Ubuntu 24.04 இல் nginx உடன் Certbot மற்றும் Ubuntu 24.04 இல் Apache உடன் Certbot ஆகியவற்றில் கொடுக்கப்பட்டுள்ளன.

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

Certbot *.example.com ஐக் கோரும்போது, Let's Encrypt ஒரு குறிப்பிலட்ட டோக்கனை வழங்குகிறது. Certbot அந்த டோக்கனை உங்கள் ACME (automatic certificate management environment) கணக்கு விசையுடன் இணைக்கிறது, இந்த முடிவை SHA-256 கொண்டு ஹாஷ் செய்கிறது, மேலும் ஒரு சிறிய உரை மதிப்பை உருவாக்குகிறது. அந்த மதிப்பு _acme-challenge.example.com இல் TXT பதிவாக இருக்க வேண்டும். பின்னர் Let's Encrypt தனது சொந்த உள்கட்டமைப்பிலிருந்து உங்கள் டொமைனின் அதிகாரப்பூர்வ பெயர் சேவையகங்களை வினவுகிறது. அது படிக்கும் பதிவு அது எதிர்பார்க்கும் மதிப்புடன் பொருந்தினால், நீங்கள் அந்த மண்டலத்தை கட்டுப்படுத்துகிறீர்கள் என்பதை நிரூபித்துள்ளீர்கள், மேலும் மண்டலத்தின் கட்டுப்பாடு அதற்கு கீழ் உள்ள ஒவ்வொரு பெயரின் கட்டுப்பாடாகவும் ஏற்றுக்கொள்ளப்படுகிறது.

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

• ஒரே சான்றிதழில் example.com மற்றும் *.example.com ஐக் கோருவது என்பது இரண்டு தனித்தனி சவால்கள் என்பதாகும், மேலும் இரண்டு TXT பதிவுகளும் ஒரே பெயரில், அதாவது _acme-challenge.example.com இல் இருக்கும். இரண்டும் ஒரே நேரத்தில் இருக்க வேண்டும். இரண்டாவது பதிவைச் சேர்ப்பது சரியானது; முதல் பதிவை இரண்டாவது பதிவுடன் மாற்றுவது முதல் சவாலைத் தோல்வியடையச் செய்கிறது.
• சரிபார்ப்பு உங்கள் அதிகாரப்பூர்வ சேவையகங்களைப் படிக்கிறது, ஆனால் வழங்குநர் கட்டுப்பாட்டு பேனல்கள் ஒரு புதிய பதிவை அவற்றிற்குத் தள்ள ஒரு நிமிடம் அல்லது அதற்கு மேல் எடுக்கலாம். சரிபார்ப்பை இயக்க அனுமதிப்பதற்கு முன்பு வெளியிலிருந்து சரிபார்க்கவும்:

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

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

ஒரு முறை இயங்குவதைக் காண்க: manual mode

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

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

வைல்டுகார்டைச் சுற்றியுள்ள மேற்கோள் குறியீடுகள் *-ஐ கோப்புப் பெயர் வடிவமாக உங்கள் shell கருதாமல் தடுக்கின்றன. Certbot வழிமுறைகளுடன் இடைநிறுத்தப்படுகிறது:

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

அந்த TXT record-ஐ உங்கள் DNS வழங்குநரின் பேனலில் உருவாக்கவும். மேற்கே உள்ள dig கட்டளையால் அது தெரிவதை உறுதிப்படுத்தவும். பிறகு மட்டும் Enter அழுத்தவும். இந்த இயக்கம் அடிப்படை domain மற்றும் வைல்டுகார்டு இரண்டையும் கேட்பதால், Certbot இருமுறை கேட்கிறது. வழங்கல் முடியும் வரை இரண்டு record-களையும் இடத்தில் வைத்திருக்கவும். வெற்றி பழக்கமான வரிகளுடன் முடிகிறது:

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

கைமுறை முறைமை தானாகப் புதுப்பித்துக்கொள்ள முடியாததற்கான காரணம்

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

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 வழங்குநரின் API-ஐ அழைக்கும் --manual-auth-hook scripts-ஐ எழுதுவதன் மூலம் இந்தத் தேவையை நீங்கள் பூர்த்தி செய்யலாம். ஆனால் அந்தக் கட்டத்தில் நீங்கள் ஒரு DNS plugin-ஐ கைமுறையாக மீண்டும் உருவாக்குகிறீர்கள். செயல்முறையைக் கற்றுக்கொள்ள கைமுறை முறைமையைப் பயன்படுத்துங்கள். அல்லது, நீங்கள் இன்னும் DNS-ஐ தானியக்கமாக்க முடியாத ஒரு domain-ல் உண்மையான ஒரு முறை பயன்பாட்டிற்குப் பயன்படுத்துங்கள். 90-வது நாளுக்கு முன்பே ஒரு நினைவூட்டலை அமைக்கவும். ஏனெனில் Let's Encrypt இனி காலாவதி மின்னஞ்சல்களை அனுப்புவதில்லை. மற்ற அனைத்திற்கும் ஒரு plugin-ஐப் பயன்படுத்துங்கள்.

பிளக்இன் வழி: Ubuntu 24.04 இல் certbot-dns-cloudflare

DNS பிளக்இன் உங்கள் DNS வழங்குநருக்கான API சான்றுகளை வைத்திருக்கும். சான்றிதழ் வழங்கும்போதும், ஒவ்வொரு புதுப்பித்தலின்போதும் இது TXT பதிவை தானாகவே உருவாக்கி அழிக்கும். Cloudflare இங்கே உதாரணமாகக் கொடுக்கப்பட்டுள்ளது. ஏனெனில் பெரும்பாலானவர்களுக்கு இதுவே தேவைப்படும் வழங்குநர் பிளக்இன். மேலும் இது Ubuntu இல் தொகுப்பாகக் கிடைக்கிறது.

Ubuntu 24.04 இல் நமது Certbot வழிகாட்டிகள் apt தொகுப்புகளைப் பரிந்துரைக்கின்றன. 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 உங்கள் பதிப்பைக் காட்டும். இந்த பொருத்தமின்மை பாதிப்பை ஏற்படுத்தாது. வரம்பிடப்பட்ட API டோக்கன்கள் செயல்படும். ஏனெனில் 24.04 இல் உள்ள python3-cloudflare நூலகம் பதிப்பு 2.11.1 ஆகும். இது டோக்கன் ஆதரவுக்குத் தேவையான 2.3.1 பதிப்பை விட உயர்ந்தது. பழைய Ubuntu வெளியீடுகளில் அந்த நூலகம் டோக்கன்களுக்கு ஏற்றதாக இல்லை. ஆகையால் ஆன்லைனில் நீங்கள் காணும் apt பிளக்இன் Global API Key ஐ கட்டாயப்படுத்துகிறது என்ற எச்சரிக்கைகள் இதற்கே காரணம். 24.04 இல் அந்த எச்சரிக்கைகள் பொருந்தாது.

Cloudflare டாஷ்போர்டில் Global API Key க்கு பதிலாக வரம்பிடப்பட்ட API டோக்கனை உருவாக்கவும்: 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 அதன் அனுமதி நிலையை சரிபார்த்து Unsafe permissions on credentials configuration file குறித்து எச்சரிக்கை விடும். இப்போது சான்றிதழை வழங்கவும்:

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

இந்தப் பிளக்இன் API வழியாக TXT பதிவுகளை உருவாக்கும். பரவலுக்காக குறுகிய காத்திருப்பு நேரம் கடக்கும். பின்னர் சரிபார்ப்பு நடைபெறும். அதன்பின் பதிவுகள் மீண்டும் அழிக்கப்படும். உங்கள் zone பெயர் சேவையகங்கள் மாற்றங்களை ஏற்க தாமதமானால், --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-ஐ முதலில் பயன்படுத்தும் எங்கள் ஆலோசனை இங்கு மாறுகிறது: snap-இலிருந்து Certbot மற்றும் செருகுநிரலை நிறுவவும். இரண்டு புதுப்பித்தல் நேரங்களும் /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 செருகுநிரல் snap Certbot உடன் மட்டுமே இணையும். அது apt Certbot-ஐ விரிவுபடுத்த முடியாது. எனவே இரண்டு நிறுவல்களும் ஒன்றாக இருக்கக் கூடாது. உங்கள் DNS வழங்குநர் API-ஐ வழங்கவில்லையென்றால், உங்கள் நடைமுறை வழிகள் இரண்டு மட்டுமே: டொமைனின் DNS-ஐ API கொண்ட வழங்குநரிடம் மாற்றுவது, அல்லது உங்கள் சொந்த பெயர் சேவையகத்தை இயக்கி rfc2136 செருகுநிரலை அதனை நோக்கி அமைப்பது.

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

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

sudo certbot renew --dry-run

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

வைல்டுகார்டு தேவையில்லாத சந்தர்ப்பங்கள்

பல சப்டொமைன்களுக்கு, அல்லது நீங்கள் கணிக்க முடியாத சப்டொமைன்களுக்கு வைல்டுகார்டு சரியான கருவி. மற்ற அனைத்திற்கும் இது தவறான இயல்புநிலை.

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

வைல்டுகார்டு உண்மையில் பயனுள்ளதாக இருக்கும் இடங்கள்: நீங்கள் சான்றிதழ்களை மறுவழங்குவதை விட வேகமாக உருவாக்கப்படும் ஒவ்வொரு வாடிக்கையாளருக்கும் அல்லது ஒவ்வொரு செயலிக்குமான சப்டொமைன்கள், மற்றும் பொதுவான port 80 இல்லாத உள் ஹோஸ்ட்கள், உதாரணமாக ஒரு WireGuard VPN வழியாக மட்டுமே அணுகக்கூடிய சேவைகள். DNS-01 சான்றிதழ் பெறும் ஹோஸ்டுடன் எப்போதும் இணையாது. எனவே முழுமையாக தனியார் கணினியும் பொதுவாக நம்பகமான சான்றிதழை வைத்திருக்க முடியும்.

FAQ

Certbot HTTP-01 ஐப் பயன்படுத்தி wildcard சான்றிதழை வழங்க முடியுமா?

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

ஒரு wildcard சான்றிதழ் root டொமைனை உள்ளடக்குமா?

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

எனது wildcard சான்றிதழ் தானாக புதுப்பிக்கப்படாதது ஏன்?

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

_acme-challenge TXT record தோன்ற எவ்வளவு நேரம் ஆகும்?

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

ஒரு wildcard சான்றிதழ் சாதாரண சான்றிதழை விட குறைவாக பாதுகாப்பானதா?

க்ரிப்டோகிராஃபி ஒன்றே. வேறுபாடுகள் செயல்பாட்டு ரீதியானவை: ஒரு private key ஒவ்வொரு subdomain ஐயும் உள்ளடக்கியது, எனவே ஒரு தீங்கு மேலும் பரவலாக செல்கிறது, மேலும் ஆட்டோமேஷன் தேவைப்படும் DNS API credential தானே சேவையகத்தில் சேமிக்கப்பட்ட ஒரு முக்கியமான ரகசியம். நீங்கள் சில அறிந்த subdomains மட்டுமே இயக்கினால், ஒரு SAN சான்றிதழ் இரண்டு கவலைகளையும் தவிர்க்கிறது, இதுதான் இந்த வழிகாட்டி wildcard ஐ தவிர்க்க பரிந்துரைக்கும் சரியான நேரம்.