Certbot Wildcard Certificate DNS-01 कैसे बनाएं

Wildcard certificate के लिए DNS-01 क्यों आवश्यक है

एक wildcard certificate किसी domain के सभी first-level subdomains को कवर करता है: *.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 पर नियंत्रण साबित करता है, वही hostname जिससे validation server ने file प्राप्त की है। Wildcard domain के अंतर्गत आने वाले हर संभावित नाम का दावा करता है, और पूरे namespace के लिए एकमात्र सार्वजनिक record DNS ही है।

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

यह हमारे Certbot guides का wildcard chapter है। साधारण single-hostname certificates, web server configuration और port 80 rules को Certbot with nginx on Ubuntu 24.04 और Certbot with Apache on Ubuntu 24.04 में कवर किया गया है।

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

जब Certbot *.example.com के लिए request भेजता है, तो Let's Encrypt एक random token के साथ उत्तर देता है। Certbot उस token को आपके ACME (automatic certificate management environment) account key के साथ जोड़ता है, परिणाम को SHA-256 के साथ hash करता है, और एक छोटा text value बनाता है। वह value _acme-challenge.example.com पर एक TXT record के रूप में होनी चाहिए। इसके बाद Let's Encrypt अपने infrastructure से आपके domain के authoritative name servers को query करता है। यदि पढ़ा गया record अपेक्षित value से मेल खाता है, तो आपने सिद्ध कर दिया है कि आपका zone पर नियंत्रण है। zone पर नियंत्रण होने का अर्थ है कि उसके अंतर्गत आने वाले सभी names पर आपका नियंत्रण है।

अधिकांश failures के दो मुख्य कारण हैं:

• एक ही certificate पर example.com और *.example.com को request करने का मतलब है दो अलग-अलग challenges, और दोनों TXT records एक ही name, _acme-challenge.example.com पर स्थित होते हैं। दोनों का एक ही समय पर मौजूद होना आवश्यक है। दूसरा record जोड़ना सही तरीका है; पहले record को दूसरे से replace करने पर पहला challenge fail हो जाएगा।
• Validation आपके authoritative servers को पढ़ता है, लेकिन provider control panels को नया record उन तक पहुँचाने में एक मिनट या उससे अधिक समय लग सकता है। Validation चलाने से पहले बाहर से check करें:

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

जब यह command Certbot द्वारा मांगी गई value print करती है, तब validation सफल हो सकता है। यदि यह कुछ भी print नहीं करती है, तो प्रतीक्षा करें और इसे पुन: चलाएं।

एक बार मैन्युअल मोड में देखें: manual mode

Manual mode में आपको DNS को स्वयं एडिट करना होता है। इसे automate करने से पहले mechanism को समझने का यह सबसे अच्छा तरीका है:

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

Wildcard के आस-पास के quotes यह सुनिश्चित करते हैं कि आपकी shell * को filename pattern न समझे। Certertbot निर्देशों के साथ रुक जाएगा:

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

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

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 दिनों के बाद बेकार हो जाएगा। Certbot renewal timer दिन में दो बार unattended तरीके से चलता है, और उस समय नया value paste करने के लिए कोई keyboard पर मौजूद नहीं होता। इसलिए, manually जारी किया गया certificate इस error के साथ renewal में fail हो जाता है:

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

The plugin route: certbot-dns-cloudflare on Ubuntu 24.04

DNS plugin आपके DNS provider के API credentials का उपयोग करता है। यह certificate issuance और renewal के दौरान TXT record की प्रक्रिया खुद पूरा करता है। यहाँ Cloudflare का उदाहरण दिया गया है क्योंकि अधिकांश उपयोगकर्ताओं को इसी plugin की आवश्यकता होती है, और यह Ubuntu में उपलब्ध है।

हमारे Certbot guides Ubuntu 24.04 पर apt packages का उपयोग करने की सलाह देते हैं, और Cloudflare के लिए भी यही नियम लागू होता है:

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

Versions के बारे में एक महत्वपूर्ण जानकारी। 24.04 archive में यह plugin version 2.0.0 के साथ आता है और Certbot 2.9.0 के साथ; apt policy python3-certbot-dns-cloudflare आपके version को दर्शाता है। यह mismatch कोई समस्या पैदा नहीं करता है। Scoped API tokens काम करेंगे, क्योंकि 24.04 में underlying python3-cloudflare library version 2.11.1 है, जो token support के लिए आवश्यक 2.3.1 से अधिक है। पुराने Ubuntu releases में यह library tokens के लिए बहुत पुरानी थी, इसलिए इंटरनेट पर apt plugin द्वारा Global API Key के उपयोग के बारे में चेतावनियाँ मिलती हैं। 24.04 में वे अब लागू नहीं होती हैं।

Cloudflare dashboard में, Global API Key के बजाय एक scoped API token बनाएँ: My Profile, फिर API Tokens, फिर Create Token, और केवल Zone / DNS / Edit permission चुनें। इसे केवल उसी एक zone तक सीमित रखें जिसके लिए आप certificate जारी कर रहे हैं। इसे एक ऐसी file में रखें जिसे केवल 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 file mode की जाँच करता है और यदि file अन्य users के लिए readable है, तो 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 records बनाता है, propagation के लिए कुछ समय प्रतीक्षा करता है, validation पूरा होने देता है, और फिर records को हटा देता है। यदि आपके zone के name servers बदलावों को पहचानने में देरी करते हैं, तो --dns-cloudflare-propagation-seconds 60 का उपयोग करके प्रतीक्षा समय बढ़ाएँ। Certificate /etc/letsencrypt/live/example.com/ में सुरक्षित होता है, और आप nginx या Apache को fullchain.pemfullchain.pem और privkey.pemprivkey.pem पर ठीक वैसे ही point करते हैं जैसे base guides में दिखाया गया है, deploy hook के साथ।

यदि आपके provider का plugin apt में नहीं है

24.04 archive में केवल कुछ ही providers के plugins उपलब्ध हैं। इनमें Cloudflare, Route 53, DigitalOcean और generic RFC 2136 interface शामिल हैं। list देखने के लिए apt search certbot-dns चलाएँ। यदि आपका provider सूची में नहीं है, तो हमारा 'apt-first' सुझाव बदल जाता है: इसके बजाय snap से Certbot और plugin install करें। पहले 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 plugin केवल snap Certbot से ही जुड़ सकता है; यह apt वाले plugin को extend नहीं कर सकता। इसीलिए दोनों installs का एक साथ होना गलत है। यदि आपका DNS host कोई API प्रदान नहीं करता है, तो आपके पास दो विकल्प हैं: domain के DNS को किसी ऐसे provider पर move करें जिसके पास API हो, या अपना खुद का name server चलाएँ और rfc2136 plugin को उसकी ओर point करें।

Renewal: इसे 60 दिनों के बजाय अभी परखें

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

sudo certbot renew --dry-run

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

Jab aapko wildcard ki zaroorat nahi hai

Wildcard un subdomains ke liye sahi tool hai jin ki sankhya bahut zyada hai, ya jinhe aap predict nahi kar sakte. Baaki sabhi cases ke liye ise default ke roop mein istemal karna galat hai.

• Ek subdomain, ya kuch gine-chune subdomains ke liye: ek normal SAN (subject alternative name) certificate zyada saral hai. certbot --nginx -d example.com -d www.example.com -d app.example.com plain HTTP-01 ke madhyam se 100 names tak cover karta hai, aur server par koi DNS API credential rakhne ki zaroorat nahi padti.
• Wildcard sirf ek label ko match karta hai. *.example.com bare example.com ko cover nahi karta, isliye upar diye gaye commands dono ki request karte hain, aur yeh a.b.example.com ko bhi cover nahi karta; uske liye *.b.example.com ki zaroorat hogi.
• Har subdomain ke peeche ek private key hoti hai. Agar woh machine compromise ho jati hai, toh wildcard dwara cover kiye gaye sabhi names ek saath prabhavit ho jate hain.
• Agar Traefik aapke containers ke liye TLS (transport layer security) terminate karta hai, toh aapko Certbot ki bilkul zaroorat nahi hai: Traefik DNS-01 ke madhyam se khud wildcard certificates request karta hai, jisme wahi provider token istemal hota hai.

Wildcard ka sahi upyog wahan hota hai: per-customer ya per-app subdomains ke liye jinhe aap certificates reissue karne ki tulna mein zyada tezi se banana chahte hain, aur un internal hosts ke liye jinme public port 80 nahi hota, jaise ki aise services jo sirf a WireGuard VPN ke madhyam se pahunchne yogya hain. DNS-01 kabhi bhi us host se connect nahi karta jiska certificate liya ja raha hai, isliye ek puri tarah se private machine bhi publicly trusted certificate rakh sakti hai.

FAQ

क्या Certbot HTTP-01 के साथ wildcard certificate जारी कर सकता है?

नहीं। HTTP-01 केवल एक hostname के नियंत्रण को सिद्ध करता है, क्योंकि validation server उसी सटीक नाम से एक token file प्राप्त करता है। Wildcard डोमेन के अंतर्गत आने वाले हर नाम को कवर करता है, इसलिए 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 value की आवश्यकता होती है, और unattended timer के पास इसे paste करने का कोई तरीका नहीं है, इसलिए renewal An authentication script must be provided with --manual-auth-hook when using the manual plugin non-interactively error के साथ रुक जाता है। Certificate को certbot-dns-cloudflare जैसे DNS plugin के साथ reissue करें, या --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 के साथ चेक करें और manual run जारी रखने से पहले अपेक्षित value के आने का इंतज़ार करें। यदि validation यह रिपोर्ट करता है कि record नहीं मिला, तो plugin के propagation option, जैसे कि --dns-cloudflare-propagation-seconds 60, के माध्यम से built-in wait बढ़ाएं।

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

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