Certbot ने DNS-01 वापरून वाइल्डकार्ड प्रमाणपत्र कसे घ्यावे

वाइल्डकार्ड प्रमाणपत्रासाठी DNS-01 का आवश्यक आहे

वाइल्डकार्ड प्रमाणपत्र डोमेनच्या पहिल्या स्तरावरील प्रत्येक उपडोमेनला लागू होते: *.example.com हे app.example.com, blog.example.com आणि एका लेबलच्या खोलीवरील इतर कोणत्याही नावाशी जुळते. Let's Encrypt वाइल्डकार्ड प्रमाणपत्रे केवळ DNS-01 challenge द्वारे जारी करते. त्यामुळे Certbot ला _acme-challenge.example.com येथे TXT record प्रकाशित करून डोमेनच्या DNS वरील नियंत्रण सिद्ध करावे लागते. HTTP-01 challenge यासाठी पुरेसा ठरत नाही, कारण token file उपलब्ध करून दिल्याने केवळ एका hostname वरील नियंत्रण सिद्ध होते. तो hostname validation server ने file ज्या ठिकाणाहून घेतली तो असतो. वाइल्डकार्ड म्हणजे डोमेनअंतर्गत असलेल्या प्रत्येक संभाव्य नावावरील दावा आहे. संपूर्ण namespace चे प्रतिनिधित्व करणारा एकमेव सार्वजनिक record म्हणजे DNS.

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

हा आमच्या Certbot guides मधील वाइल्डकार्ड अध्याय आहे. नेहमीची single-hostname certificates, web server configuration आणि port 80 rules यांचा समावेश 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 स्वतःच्या पायाभूत सुविधांमधून तुमच्या डोमेनच्या अधिकृत name servers ची चौकशी करते. त्याला वाचलेले रेकॉर्ड अपेक्षित मूल्यासोबत जुळल्यास, तुम्ही zone वर तुमचे नियंत्रण सिद्ध केले आहे असे मानले जाते. त्यामुळे त्या zone अंतर्गत असलेल्या प्रत्येक नावावर तुमचे नियंत्रण आहे हे स्वीकारले जाते.

बहुतेक त्रुटी दोन कारणांमुळे होतात:

• एकाच प्रमाणपत्रासाठी example.com आणि *.example.com ची विनंती केल्यास दोन स्वतंत्र challenges तयार होतात आणि दोन्ही TXT records एकाच नावावर, _acme-challenge.example.com येथे, असतात. दोन्ही records एकाच वेळी अस्तित्वात असणे आवश्यक आहे. दुसरा record जोडणे योग्य आहे; पहिल्या record च्या जागी दुसरा record ठेवल्यास पहिला challenge अयशस्वी होतो.
• Validation तुमच्या authoritative servers कडून वाचले जाते; परंतु provider चे control panels नवीन record त्या servers वर पाठवण्यासाठी एक मिनिट किंवा त्याहून अधिक वेळ घेऊ शकतात. Validation सुरू करण्यापूर्वी बाहेरून तपासा:

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

यातून Certbot ने मागितलेले मूल्य दिसल्यास validation यशस्वी होऊ शकते. काहीही दिसत नसल्यास प्रतीक्षा करा आणि command पुन्हा चालवा.

ते एकदा कार्यरत पाहा: मॅन्युअल मोड

मॅन्युअल मोडमध्ये 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

तुमच्या DNS प्रदात्याच्या पॅनेलमध्ये तो TXT रेकॉर्ड तयार करा. वरील dig कमांड वापरून तो दिसत आहे याची खात्री करा. त्यानंतरच Enter दाबा. या रनमध्ये मूळ डोमेन आणि वाइल्डकार्डसाठी विनंती केली असल्याने Certbot दोनदा सूचना देतो. प्रमाणपत्र जारी होईपर्यंत दोन्ही रेकॉर्ड तसेच ठेवा. यशस्वी प्रक्रिया नेहमीच्या या ओळींसह पूर्ण होते:

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

मॅन्युअल मोड स्वतःचे नूतनीकरण का करू शकत नाही

प्रत्येक नूतनीकरणात नवीन token सह नवीन challenge असते. त्यामुळे TXT मूल्य प्रत्येक वेळी बदलते. तुम्ही आज paste केलेला record 60 दिवसांनी निरुपयोगी ठरतो. नूतनीकरणाचा timer Certbot ला दिवसातून दोनदा unattended पद्धतीने चालवतो. नवीन मूल्य paste करण्यासाठी keyboard वर कोणीही उपलब्ध नसते. त्यामुळे मॅन्युअली जारी केलेल्या 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 ला call करणाऱ्या --manual-auth-hook scripts लिहून तुम्ही ही आवश्यकता पूर्ण करू शकता. परंतु त्या टप्प्यावर तुम्ही DNS plugin स्वतः तयार करत असता. प्रवाह समजून घेण्यासाठी manual mode वापरा. किंवा ज्याच्या DNS चे automation अद्याप करता येत नाही अशा domain साठी खरोखरच एकदाच certificate जारी करायचे असल्यास manual mode वापरा. दिनांक 90 येण्यापूर्वी reminder सेट करा, कारण Let's Encrypt आता expiry emails पाठवत नाही. इतर सर्व बाबतीत plugin वापरा.

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

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

आमच्या 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 मधील अंतर्गत python3-cloudflare library version 2.11.1 आहे. Token support साठी plugin ला आवश्यक असलेल्या 2.3.1 पेक्षा ही आवृत्ती नवीन आहे. जुन्या Ubuntu releases मध्ये ही library tokens साठी खूप जुनी होती. त्यामुळे apt plugin Global API Key वापरण्यास भाग पाडतो, अशा सूचना online आढळतात. Ubuntu 24.04 वर त्या लागू होत नाहीत.

Cloudflare dashboard मध्ये Global API Key ऐवजी scoped API token तयार करा: My Profile, नंतर API Tokens, त्यानंतर Create Token. एकच permission Zone / DNS / Edit द्या आणि तो तुम्ही certificate जारी करत असलेल्या एका zone पुरता मर्यादित ठेवा. तो फक्त 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 साठी थोडा वेळ थांबते, validation चालू देते आणि नंतर records पुन्हा हटवते. तुमच्या zone चे name servers बदल स्वीकारण्यास उशीर करत असल्यास --dns-cloudflare-propagation-seconds 60 वापरून प्रतीक्षा वेळ वाढवा. Certificate /etc/letsencrypt/live/example.com/ मध्ये साठवले जाते. Base guides मध्ये दाखवल्याप्रमाणे nginx किंवा Apache ला fullchain.pem आणि privkey.pem कडे निर्देशित करा. Deploy hook देखील समाविष्ट करा.

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

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

नूतनीकरण: 60 दिवसांनी नव्हे, आत्ताच ते सिद्ध करा

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

sudo certbot renew --dry-run

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

वाइल्डकार्डची आवश्यकता नसताना

अनेक उपडोमेनसाठी किंवा ज्यांचा अंदाज लावता येत नाही अशा उपडोमेनसाठी वाइल्डकार्ड योग्य साधन आहे. इतर सर्व परिस्थितींमध्ये ते डीफॉल्ट पर्याय म्हणून वापरणे योग्य नाही.

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

वाइल्डकार्डचा खरा उपयोग अशा परिस्थितीत होतो जिथे प्रत्येक ग्राहकासाठी किंवा app साठी उपडोमेन तयार करण्याचा वेग प्रमाणपत्रे पुन्हा जारी करण्याच्या वेगापेक्षा जास्त असतो, तसेच सार्वजनिक port 80 नसलेल्या internal hosts साठीही होतो. उदाहरणार्थ, WireGuard VPN द्वारेच उपलब्ध असलेल्या services. DNS-01 प्रमाणित होत असलेल्या host शी कधीही connection करत नाही. त्यामुळे पूर्णपणे private मशीनवरही सार्वजनिकरीत्या trusted प्रमाणपत्र ठेवता येते.

FAQ

Certbot HTTP-01 वापरून wildcard प्रमाणपत्र जारी करू शकते का?

नाही. 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 ठेवणे. तो record स्वहस्ते किंवा DNS plugin द्वारे ठेवता येतो.

Wildcard प्रमाणपत्र root domain ला लागू होते का?

नाही. Wildcard अगदी एका label शी जुळते. त्यामुळे *.example.com हे www.example.com शी जुळते, परंतु bare example.com शी किंवा a.b.example.com शी जुळत नाही. -d example.com -d '*.example.com' वापरून दोन्ही नावे एका प्रमाणपत्रासाठी मागवा. यामुळे दोन challenges तयार होतात. दोन्ही TXT records एकाच _acme-challenge.example.com नावावर असतात. त्यामुळे पहिला record हटवू नका; त्यात दुसरा record जोडा.

माझे wildcard प्रमाणपत्र आपोआप renew का होत नाही?

कारण ते --manual वापरून जारी केले गेले होते. प्रत्येक renewal साठी पूर्णपणे नवीन TXT value आवश्यक असते. Unattended timer कडे ती value ठेवण्याची पद्धत नसते. त्यामुळे renewal An authentication script must be provided with --manual-auth-hook when using the manual plugin non-interactively या error सह थांबते. certbot-dns-cloudflare सारखा DNS plugin वापरून प्रमाणपत्र पुन्हा जारी करा. किंवा तुमच्या provider च्या API द्वारे record संपादित करणाऱ्या --manual-auth-hook आणि --manual-cleanup-hook scripts द्या.

_acme-challenge TXT record दिसण्यासाठी किती वेळ लागतो?

हे तुमच्या DNS provider वर अवलंबून असते. यासाठी काही seconds ते several minutes लागू शकतात. Validation तुमच्या zone चे authoritative servers वाचते. त्यामुळे dig +short TXT _acme-challenge.example.com @1.1.1.1 वापरून तपासा आणि manual run पुढे सुरू करण्यापूर्वी अपेक्षित value दिसेपर्यंत प्रतीक्षा करा. Plugin वापरत असल्यास, validation मध्ये record सापडला नाही असे कळल्यास plugin च्या propagation option द्वारे built-in wait वाढवा. उदाहरणार्थ, --dns-cloudflare-propagation-seconds 60 वापरा.

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

Cryptography समान असते. फरक operational असतात. एकच private key प्रत्येक subdomain साठी वापरली जाते. त्यामुळे compromise झाल्यास त्याचा परिणाम अधिक subdomains वर होऊ शकतो. Automation साठी आवश्यक असलेले DNS API credential हे देखील संवेदनशील secret असते आणि server वर साठवले जाते. तुम्ही फक्त काही निश्चित subdomains चालवत असल्यास, SAN प्रमाणपत्र या दोन्ही समस्या टाळते. म्हणूनच या guide मध्ये wildcard वगळण्याची शिफारस नेमक्या अशा परिस्थितीत केली आहे.