Certbot के साथ DNS-01 challenge का उपयोग कैसे करें

Wildcard certificate को DNS-01 की आवश्यकता क्यों होती है

Wildcard certificate किसी domain के हर first-level subdomain को कवर करता है: *.example.com का मिलान app.example.com, blog.example.com और एक label गहरे किसी भी अन्य नाम से होता है। Let’s Encrypt केवल DNS-01 challenge के माध्यम से ही wildcard certificates जारी करता है, इसलिए Certbot को _acme-challenge.example.com पर एक TXT record publish करके domain के DNS पर नियंत्रण साबित करना होता है। HTTP-01 challenge इसके लिए योग्य नहीं है, क्योंकि एक token file serve करना केवल एक hostname पर नियंत्रण साबित करता है, जिससे validation server ने file fetch की थी। Wildcard उस domain के अंतर्गत हर संभावित नाम के बारे में एक दावा है, और एकमात्र public record जो पूरे namespace का प्रतिनिधित्व करता है, वह स्वयं DNS है।

यह एक आवश्यकता इस पृष्ठ पर बाकी सब कुछ निर्धारित करती है। DNS-01 को पास करने के लिए आपको domain के zone में TXT records बनाने में सक्षम होना चाहिए, या तो मैन्युअल रूप से या अपने DNS provider के API (application programming interface) के माध्यम से। मैन्युअल तरीका एक बार काम करता है और फिर renewal के समय विफल हो जाता है, जिसका ठोस कारण नीचे दिखाया गया है। API मार्ग, एक Certbot DNS plugin के माध्यम से, बिना किसी मानवीय हस्तक्षेप के renew होता है, और यही वह setup है जिसे आपको अंततः अपनाना चाहिए।

यह हमारी Certbot guides का wildcard अध्याय है। सामान्य single-hostname certificates, web server configuration और port 80 के नियमों को Ubuntu 24.04 पर Nginx के साथ Certbot और Ubuntu 24.04 पर Apache के साथ Certbot में कवर किया गया है।

_acme-challenge TXT record कैसे काम करता है

जब 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 संपादन स्वयं करना पड़ता है। इसे automate करने से पहले तंत्र को समझने का यह सबसे अच्छा तरीका है:

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

Wildcard के चारों ओर लगे quotes आपके shell को * को filename pattern के रूप में उपयोग करने से रोकते हैं। Certbot निर्देशों के साथ रुक जाता है:

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

अपने DNS प्रदाता के पैनल में वह TXT record बनाएँ, ऊपर दिए गए dig command के साथ पुष्टि करें कि वह दिखाई दे रहा है, और उसके बाद ही Enter दबाएँ। चूँकि यह run bare domain और wildcard दोनों के लिए अनुरोध करता है, इसलिए Certbot दो बार संकेत देगा; issuance पूरा होने तक दोनों records को लगा रहने दें। सफलता मिलने पर अंत में ये परिचित पंक्तियाँ दिखाई देंगी:

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

Manual mode स्वयं renew क्यों नहीं हो सकता

प्रत्येक renewal एक नया challenge और नया token लेकर आता है, इसलिए TXT value हर बार बदल जाती है। आज जो record आपने paste किया है, वह 60 दिनों बाद बेकार हो जाएगा। Renewal timer दिन में दो बार Certbot को unattended तरीके से चलाता है, और उस समय नई value paste करने के लिए कोई मौजूद नहीं होता। इसलिए, manually जारी किया गया certificate इस त्रुटि के साथ renew होने में विफल हो जाता है:

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 scripts लिखकर पूरा कर सकते हैं जो आपके DNS provider के API को call करें, लेकिन उस स्थिति में आप वास्तव में हाथ से DNS plugin को फिर से बना रहे होंगे। Manual mode का उपयोग केवल प्रक्रिया को समझने के लिए करें, या किसी ऐसे domain के लिए करें जिसका DNS आप अभी automate नहीं कर सकते। ऐसी स्थिति में 90 दिन पूरे होने से काफी पहले का reminder set करें, क्योंकि Let's Encrypt अब expiry emails नहीं भेजता है। अन्य सभी कार्यों के लिए, plugin का ही उपयोग करें।

प्लगइन मार्ग: Ubuntu 24.04 पर certbot-dns-cloudflare

DNS प्लगइन आपके DNS प्रदाता के लिए API क्रेडेंशियल रखता है और जारी करने के समय तथा हर नवीनीकरण (renewal) पर TXT रिकॉर्ड की पूरी प्रक्रिया स्वयं पूरी करता है। यहाँ Cloudflare का उदाहरण दिया गया है क्योंकि अधिकांश लोगों को इसी प्रदाता प्लगइन की आवश्यकता होती है और यह Ubuntu में पैकेज के रूप में उपलब्ध है।

हमारी Certbot मार्गदर्शिकाएँ Ubuntu 24.04 पर apt पैकेज का उपयोग करने की सलाह देती हैं, और Cloudflare के लिए भी यही दृष्टिकोण सही है:

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

संस्करणों के बारे में एक स्पष्ट जानकारी। 24.04 आर्काइव में यह प्लगइन Certbot 2.9.0 के साथ संस्करण 2.0.0 पर उपलब्ध है; apt policy python3-certbot-dns-cloudflare आपका संस्करण दिखाता है। यह विसंगति हानिकारक नहीं है, और scoped API टोकन काम करते हैं, क्योंकि 24.04 में अंतर्निहित python3-cloudflare लाइब्रेरी 2.11.1 है, जो टोकन समर्थन के लिए आवश्यक 2.3.1 से अधिक है। पुराने Ubuntu रिलीज़ में वह लाइब्रेरी टोकन के लिए बहुत पुरानी थी, जिसके कारण ऑनलाइन मिलने वाली उन चेतावनियों का जन्म हुआ जिनमें apt प्लगइन द्वारा Global API Key के उपयोग के लिए मजबूर करने की बात कही गई है। 24.04 पर वे अब लागू नहीं होतीं।

Cloudflare डैशबोर्ड में Global API Key के बजाय एक scoped API टोकन बनाएँ: 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'

प्लगइन API के माध्यम से TXT रिकॉर्ड बनाता है, थोड़े समय के लिए propagation delay की प्रतीक्षा करता है, सत्यापन (validation) पूरा होने देता है, और फिर रिकॉर्ड को हटा देता है। यदि आपके ज़ोन के नाम सर्वर (name servers) परिवर्तनों को स्वीकार करने में धीमे हैं, तो --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-first सलाह में बदलाव आता है: इसके बजाय snap से Certbot और प्लगइन इंस्टॉल करें, और पहले apt Certbot को हटा दें ताकि दो renewal timers कभी भी /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 प्लगइन केवल snap Certbot से जुड़ता है; यह apt वाले को विस्तारित नहीं कर सकता, इसीलिए दोनों इंस्टॉलेशन एक साथ नहीं होने चाहिए। और यदि आपका DNS होस्ट कोई API प्रदान नहीं करता है, तो आपके पास व्यावहारिक विकल्प यह है कि आप डोमेन के DNS को किसी ऐसे प्रदाता पर ले जाएँ जिसके पास API हो, या अपना स्वयं का name server चलाएँ और उस पर rfc2136 प्लगइन को पॉइंट करें।

नवीनीकरण: अभी जांचें, 60 दिनों में नहीं

Certbot यह रिकॉर्ड करता है कि प्रत्येक certificate को /etc/letsencrypt/renewal/example.com.conf में कैसे जारी किया गया था, जिसमें authenticator = dns-cloudflare और credentials path शामिल हैं, इसलिए मानक twice-daily timer आपकी सहायता के बिना इसे renew कर देता है। staging environment के विरुद्ध पूरी प्रक्रिया का पूर्वाभ्यास करें:

sudo certbot renew --dry-run

एक सफल परिणाम का अर्थ है कि credential काम कर रहा है और validation पूरी तरह से संपन्न हो गया है; 60 दिनों में होने वाला वास्तविक नवीनीकरण भी इसी मार्ग का अनुसरण करेगा। आज दो follow-up कार्य करना उचित है। पहला, disk पर मौजूद renewed certificate तब तक कुछ नहीं बदलता जब तक web server उसे reload न कर ले, इसलिए nginx और Apache guides में वर्णित deploy hook को कॉन्फ़िगर करें। दूसरा, credentials file को सावधानी से रखें: जो कोई भी इसे पढ़ सकता है, वह आपकी DNS zone को edit कर सकता है, जो आपके mail को redirect करने या स्वयं DNS-01 challenges को पास करने के लिए पर्याप्त है। इसे /root के अंतर्गत mode 600 पर रखें, token को एक zone तक सीमित करें, और यदि आपको कभी leak का संदेह हो तो इसे rotate करें।

जब आपको wildcard की आवश्यकता न हो

Wildcard कई subdomains के लिए, या ऐसे subdomains के लिए जिन्हें आप पहले से नहीं जान सकते, एक सही उपकरण है। बाकी सभी स्थितियों के लिए यह डिफ़ॉल्ट विकल्प के रूप में गलत है।

• एक subdomain, या कुछ गिने-चुने ज्ञात subdomains: एक सामान्य 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 रखने की आवश्यकता नहीं होती।
• एक wildcard ठीक एक label से मेल खाता है। *.example.com bare example.com को कवर नहीं करता है, यही कारण है कि ऊपर दिए गए commands दोनों का अनुरोध करते हैं, और यह a.b.example.com को भी कवर नहीं करता है; उसके लिए *.b.example.com की आवश्यकता होगी।
• हर subdomain के पीछे एक private key होती है। यदि वह मशीन जिस पर यह key मौजूद है, breached हो जाती है, तो wildcard द्वारा कवर किए गए सभी नाम एक साथ प्रभावित हो जाते हैं।
• यदि Traefik आपके containers के लिए TLS (transport layer security) terminate करता है, तो आपको Certbot की बिल्कुल भी आवश्यकता नहीं है: Traefik स्वयं DNS-01 के माध्यम से wildcard certificates का अनुरोध करता है, जिसमें उसी प्रकार के provider token का उपयोग होता है।

Wildcard वास्तव में तब उपयोगी होता है जब: प्रति-ग्राहक या प्रति-app subdomains इतनी तेजी से बनाए जाते हैं कि आप बार-बार certificates reissue नहीं करना चाहते, और ऐसे internal hosts जिनके पास public port 80 नहीं है, जैसे कि वे services जो केवल एक WireGuard VPN के माध्यम से ही पहुंच योग्य हैं। DNS-01 कभी भी उस host से connect नहीं होता जिसे certify किया जा रहा है, इसलिए एक पूरी तरह से private मशीन भी publicly trusted certificate रख सकती है।

FAQ

क्या Certbot HTTP-01 का उपयोग करके wildcard certificate जारी कर सकता है?

नहीं। HTTP-01 केवल एक hostname पर नियंत्रण सिद्ध करता है, क्योंकि validation सर्वर उस सटीक नाम से एक 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 पर दोनों नाम request करें। यह दो challenges बनाता है, और दोनों TXT records एक ही _acme-challenge.example.com नाम पर स्थित होते हैं, इसलिए पहले record को हटाए बिना दूसरा record जोड़ें।

मेरा wildcard certificate अपने आप renew क्यों नहीं होता है?

क्योंकि इसे --manual के साथ जारी किया गया था। प्रत्येक renewal के लिए एक बिल्कुल नए TXT मान की आवश्यकता होती है, और unattended timer के पास इसे पेस्ट करने का कोई तरीका नहीं है, इसलिए renewal An authentication script must be provided with --manual-auth-hook when using the manual plugin non-interactively त्रुटि के साथ रुक जाता है। certificate को certbot-dns-cloudflare जैसे DNS plugin के साथ पुनः जारी करें, या --manual-auth-hook और --manual-cleanup-hook scripts प्रदान करें जो आपके provider के API के माध्यम से record को edit करती हैं।

_acme-challenge TXT record को दिखाई देने में कितना समय लगता है?

यह आपके DNS provider पर निर्भर करता है: कुछ सेकंड से लेकर कई मिनट तक। Validation आपके zone के authoritative servers को पढ़ता है, इसलिए dig +short TXT _acme-challenge.example.com @1.1.1.1 के साथ जाँच करें और मैन्युअल run जारी रखने से पहले अपेक्षित मान के दिखाई देने तक प्रतीक्षा करें। plugin के साथ, यदि validation यह रिपोर्ट करता है कि record नहीं मिला, तो plugin के propagation option के माध्यम से इन-बिल्ट प्रतीक्षा समय बढ़ाएं, उदाहरण के लिए --dns-cloudflare-propagation-seconds 60।

क्या wildcard certificate सामान्य certificate की तुलना में कम सुरक्षित है?

cryptography समान है। अंतर परिचालन संबंधी हैं: एक private key हर subdomain को कवर करती है, इसलिए एक compromise का प्रभाव अधिक होता है, और automation के लिए आवश्यक DNS API credential स्वयं एक संवेदनशील secret है जो सर्वर पर संग्रहीत होता है। यदि आप केवल कुछ ज्ञात subdomains चलाते हैं, तो एक SAN certificate दोनों चिंताओं से बचाता है, और यही वह स्थिति है जब यह गाइड wildcard को छोड़ने की सलाह देती है।