Certbot wildcard certificate DNS-01 कसे मिळवावे

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 प्रकाशित करून domain च्या DNS वर नियंत्रण असल्याचे सिद्ध करावे लागते. HTTP-01 challenge वापरता येत नाही, कारण token file सर्व्ह करणे हे फक्त एकाच hostname वर नियंत्रण असल्याचे सिद्ध करते, जे validation server ने फाईल fetch केली आहे ते hostname. Wildcard हे domain अंतर्गत असलेल्या प्रत्येक संभाव्य नावासाठीचे दावेकरण आहे, आणि संपूर्ण namespace साठी फक्त DNS हाच एकमेव सार्वजनिक record आहे.

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

हे आमच्या Certbot मार्गदर्शिकांमधील wildcard प्रकरण आहे. सामान्य 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 साठी विनंती करते, तेव्हा Let's Encrypt एक रँडम (random) टोकन देते. Certbot त्या टोकनला तुमच्या ACME (automatic certificate management environment) अकाउंट की सोबत जोडते, त्याचे SHA-256 ने हॅश करते आणि एक लहान टेक्स्ट व्हॅल्यू तयार करते. ती व्हॅल्यू _acme-challenge.example.com वर TXT record म्हणून असणे आवश्यक आहे. त्यानंतर Let's Encrypt त्याच्या स्वतःच्या इन्फ्रास्ट्रक्चरवरून तुमच्या डोमेनच्या authoritative name servers कडून माहिती विचारते. जर वाचलेला record अपेक्षित व्हॅल्यूशी जुळला, तर तुम्ही त्या zone वर तुमचे नियंत्रण असल्याचे सिद्ध होते. zone वरील नियंत्रण म्हणजे त्याखालील सर्व नावांवर तुमचे नियंत्रण असल्याचे मानले जाते.

बहुतेक वेळा खालील दोन कारणांमुळे त्रुटी (failures) येतात:

• एकाच certificate साठी example.com आणि *.example.com विनंती करणे म्हणजे दोन वेगळी challenges आहेत, आणि दोन्ही TXT records एकाच _acme-challenge.example.com नावावर असतात. दोन्ही records एकाच वेळी अस्तित्वात असणे आवश्यक आहे. दुसरा record जोडणे योग्य आहे; परंतु पहिल्या record च्या जागी दुसरा record ठेवल्यास पहिली challenge अयशस्वी होते.
• 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 स्वतः एडिट करावा लागतो. प्रक्रिया स्वयंचलित (automate) करण्यापूर्वी ती समजून घेण्यासाठी हा सर्वोत्तम मार्ग आहे:

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

Wildcard च्या भोवतीचे quotes * ला filename pattern म्हणून treat करण्यापासून तुमच्या shell ला रोखतात. Certertbot सूचनांसह थांबते:

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

तुमच्या DNS provider च्या पॅनेलमध्ये तो TXT record तयार करा, वरील dig कमांड वापरून तो दिसत असल्याची खात्री करा, आणि त्यानंतरच Enter दाबा. या प्रक्रियेत bare domain आणि wildcard दोन्हीसाठी विचारले जाते, म्हणून Certbot दोनदा prompt देईल; प्रमाणपत्र (issuance) पूर्ण होईपर्यंत दोन्ही records तसाच ठेवा. प्रक्रिया यशस्वी झाल्यावर खालील ओळी दिसतील:

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

manual mode स्वतःहून renew का होऊ शकत नाही

प्रत्येक वेळी renewal साठी नवीन token लागते, त्यामुळे TXT value प्रत्येक वेळी बदलते. तुम्ही आज पेस्ट केलेली record 60 दिवसांनंतर निरुपयोगी ठरेल. Certbot चा renewal timer दिवसातून दोनदा unattended पद्धतीने चालतो. नवीन value पेस्ट करण्यासाठी कोणीही उपलब्ध नसते, त्यामुळे manually जारी केलेले certificate या त्रुटीमुळे (error) 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.')

तुमच्या DNS provider च्या API ला कॉल करणारे --manual-auth-hook scripts लिहून तुम्ही ही आवश्यकता पूर्ण करू शकता, परंतु तसे केल्यास तुम्ही स्वतःहून DNS plugin तयार करत आहात. प्रक्रिया समजून घेण्यासाठी किंवा ज्या domain चे DNS तुम्ही अजून automate करू शकत नाही अशा ठिकाणी फक्त एकदाच (one-off) manual mode वापरा. 90 दिवस पूर्ण होण्यापूर्वीच रिमाइंडर सेट करा, कारण Let's Encrypt आता expiry emails पाठवत नाही. इतर सर्व कामांसाठी, plugin वापरा.

plugin मार्ग: Ubuntu 24.04 वरील certbot-dns-cloudflare

DNS plugin तुमच्या DNS provider साठी API credential वापरते आणि certificate issuance व renewal च्या वेळी स्वतःहून TXT record प्रक्रिया पूर्ण करते. Cloudflare हे येथे एक उदाहरण आहे, कारण बहुतेक लोकांना या provider plugin ची आवश्यकता असते आणि ते Ubuntu मध्ये उपलब्ध आहे.

आमच्या Certbot मार्गदर्शकांनुसार Ubuntu 24.04 वर apt packages वापरण्याची शिफारस केली जाते, आणि Cloudflare साठी देखील हेच लागू आहे:

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

व्हर्जनबद्दल महत्त्वाची नोंद. 24.04 archive मध्ये हे plugin version 2.0.0 आणि Certbot 2.9.0 सोबत येते; apt policy python3-certbot-dns-cloudflare मध्ये तुमचे व्हर्जन दिसेल. यातील तफावत हानिकारक नाही आणि scoped API tokens काम करतात, कारण 24.04 मधील underlying python3-cloudflare library version 2.11.1 आहे, जी token support साठी आवश्यक असलेल्या 2.3.1 पेक्षा जास्त आहे. जुन्या Ubuntu releases मध्ये ही library tokens साठी खूप जुनी होती, त्यामुळेच तुम्हाला online मध्ये apt plugin द्वारे Global API Key वापरणे अनिवार्य असल्याचे warnings दिसू शकतात. 24.04 मध्ये ते आता लागू होत नाहीत.

Cloudflare dashboard मध्ये, Global API Key ऐवजी scoped API token तयार करा: My Profile, नंतर API Tokens, नंतर Create Token, आणि फक्त एकच permission Zone / DNS / Edit निवडा, जी तुम्ही ज्या zone साठी certificate काढत आहात त्यापुरती मर्यादित असावी. ही माहिती फक्त root वाचू शकेल अशा file मध्ये ठेवा:

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

जर file इतर कोणालाही वाचता येत असेल, तर Certbot mode तपासते आणि Unsafe permissions on credentials configuration file बद्दल warning देते. आता issue करा:

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

Plugin API द्वारे TXT records तयार करते, थोडा propagation delay थांबते, validation पूर्ण होऊ देते आणि नंतर पुन्हा records डिलीट करते. जर तुमच्या zone चे name servers बदल स्वीकारण्यास उशीर करत असतील, तर --dns-cloudflare-propagation-seconds 60 वापरून wait वेळ वाढवा. Certificate /etc/letsencrypt/live/example.com/ मध्ये साठवले जाते, आणि तुम्ही nginx किंवा Apache ला fullchain.pemfullchain.pem आणि privkey.pemprivkey.pem कडे अगदी तशाच प्रकारे निर्देशित करू शकता जसे मूळ guides मध्ये दाखवले आहे, deploy hook सह.

जर तुमच्या provider चा plugin apt मध्ये नसेल तर

24.04 archive मध्ये फक्त काही मोजक्या providers साठी plugins उपलब्ध आहेत, ज्यामध्ये Cloudflare, Route 53, DigitalOcean आणि generic RFC 2136 interface यांचा समावेश आहे. यादी पाहण्यासाठी apt search certbot-dns चालवा. जर तुमचा provider या यादीत नसेल, तर आमचा 'apt-first' सल्ला येथे बदलतो: त्याऐवजी Certbot आणि plugin snap मधून 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 ला विस्तारू शकत नाही, म्हणूनच दोन्ही installs एकत्र नसावेत. आणि जर तुमच्या DNS host कडे API नसेल, तर तुमच्याकडे दोन पर्याय उरतात: डोमेनचे DNS अशा provider कडे हलवणे ज्याच्याकडे API आहे, किंवा स्वतःचा name server चालवणे आणि rfc2136 plugin त्याकडे निर्देशित करणे.

Renewal: 60 दिवसांनंतर नाही, तर आत्ताच याची पडताळणी करा

Certbot /etc/letsencrypt/renewal/example.com.conf मध्ये प्रत्येक प्रमाणपत्र (certificate) कशा प्रकारे जारी केले गेले याची नोंद ठेवते, ज्यामध्ये authenticator = dns-cloudflare आणि credentials path यांचा समावेश असतो. यामुळे standard twice-daily timer कोणत्याही मानवी मदतीशिवाय त्याचे नूतनीकरण (renewal) करू शकतो. संपूर्ण प्रक्रिया staging environment मध्ये तपासून पहा:

sudo certbot renew --dry-run

जर प्रक्रिया यशस्वी झाली, तर याचा अर्थ credentials योग्य आहेत आणि validation पूर्ण झाले आहे; 60 दिवसांनंतर होणारे प्रत्यक्ष नूतनीकरण याच मार्गाने होईल. आज खालील दोन गोष्टी करणे आवश्यक आहे. पहिले, डिस्कवरील नूतनीकरण केलेले प्रमाणपत्र web server reload झाल्याशिवाय प्रभावी होत नाही, म्हणून nginx आणि Apache मार्गदर्शिकांमध्ये वर्णन केलेली deploy hook सेट करा. दुसरे, credentials file सुरक्षित ठेवा: ज्या कोणालाही ते वाचता येते, तो तुमच्या DNS zone मध्ये बदल करू शकतो, ज्यामुळे तुमचे mail redirect करणे किंवा स्वतःचे DNS-01 challenges पूर्ण करणे शक्य आहे. ते /root अंतर्गत mode 600 वर ठेवा, token फक्त एकाच zone साठी मर्यादित ठेवा, आणि जर गळतीची (leak) शंका आली तर ते rotate करा.

जेव्हा तुम्हाला wildcard ची गरज नसते

अनेक subdomains साठी किंवा तुम्ही अंदाज लावू शकत नाही अशा subdomains साठी wildcard हे योग्य साधन आहे. इतर सर्व गोष्टींसाठी ते चुकीचा default पर्याय आहे.

• एक subdomain, किंवा काही मोजके माहित असलेले subdomains: सामान्य SAN (subject alternative name) certificate वापरणे अधिक सोपे आहे. certbot --nginx -d example.com -d www.example.com -d app.example.com HTTP-01 द्वारे 100 नावांपर्यंत कव्हर करते, आणि सर्व्हरवर कधीही DNS API credential ठेवावे लागत नाही.
• wildcard फक्त एकाच label ला मॅच करते. *.example.com हे example.com कव्हर करत नाही, म्हणूनच वरील कमांड्स दोन्हीसाठी विनंती करतात, आणि ते a.b.example.com कव्हर करत नाही; त्यासाठी *.b.example.com आवश्यक आहे.
• प्रत्येक subdomain साठी एक private key असते. जर ती की असलेली मशीन compromised झाली, तर wildcard द्वारे कव्हर केलेली सर्व नावे एकाच वेळी प्रभावित होतात.
• जर Traefik तुमच्या containers साठी TLS (transport layer security) टर्मिनेट करत असेल, तर तुम्हाला Certbot ची अजिबात गरज नाही: Traefik स्वतः DNS-01 द्वारे wildcard certificates विनंती करते, ज्यामध्ये तोच प्रकारचा provider token वापरला जातो.

ज्या ठिकाणी wildcard खरोखर उपयुक्त ठरते: ग्राहकांनुसार किंवा ॲपनुसार तयार होणारे subdomains जे तुम्ही प्रमाणपत्रांचे reissue करण्यापेक्षा वेगाने तयार करू इच्छिता, आणि ज्या internal hosts ला public port 80 उपलब्ध नाही, जसे की a WireGuard VPN द्वारे पोहोचता येणारे services. DNS-01 कधीही ज्या host ला प्रमाणित केले जात आहे त्याच्याशी कनेक्ट होत नाही, त्यामुळे पूर्णपणे private मशीन देखील publicly trusted certificate धारण करू शकते.

FAQ

HTTP-01 वापरून Certbot 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 कव्हर होते, पण केवळ 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 कडे ते पेस्ट करण्याचा मार्ग नसतो, त्यामुळे renewal An authentication script must be provided with --manual-auth-hook when using the manual plugin non-interactively या error सह थांबते. 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 तपासा आणि अपेक्षित value येईपर्यंत प्रतीक्षा करा. जर validation मध्ये record सापडला नाही असे दाखवले, तर plugin च्या propagation option द्वारे (उदा. --dns-cloudflare-propagation-seconds 60) बिल्ट-इन wait वेळ वाढवा.

Wildcard certificate हे सामान्य certificate पेक्षा कमी सुरक्षित असते का?

Cryptography सारखीच असते. फरक केवळ ऑपरेशनल आहे: एकच private key सर्व subdomains साठी वापरली जाते, त्यामुळे compromise झाल्यास त्याचा परिणाम अधिक होतो. तसेच, automation साठी आवश्यक असलेले DNS API credential हे सर्व्हरवर साठवलेले एक संवेदनशील secret असते. जर तुम्ही फक्त काही ठराविक subdomains वापरत असाल, तर SAN certificate वापरणे अधिक सुरक्षित आहे; याच कारणास्तव हा guide wildcard न वापरण्याची शिफारस करतो.