लेखक: Matt Connor 2026-10-10 · अपडेट किया गया: 2026-10-21

Ubuntu 24.04 पर Nginx के लिए Certbot कैसे इंस्टॉल करें

Q: Ubuntu 24.04 पर nginx के लिए मुझे apt या snap में से कौन सा Certbot install करना चाहिए?

apt का उपयोग करें। sudo apt install certbot python3-certbot-nginx आपको Ubuntu 24.04 पर Certbot 2.9.0 देता है, जो इस गाइड की सभी आवश्यकताओं के लिए पर्याप्त है। यह unattended-upgrades के माध्यम से security patches प्राप्त करता है और इसके लिए snapd की आवश्यकता नहीं होती। snap को केवल तभी चुनें यदि आपको सबसे नया release तुरंत चाहिए या कोई ऐसा DNS plugin चाहिए जो विशेष रूप से केवल snap के रूप में उपलब्ध हो। किसी भी स्थिति में, केवल एक ही चुनें: दो installs का मतलब है दो renewal timers जो एक ही /etc/letsencrypt tree की ओर इशारा कर रहे हैं, और जिसे आप भूल जाएंगे, वही समस्या का कारण बनेगा।

Q: क्या Certbot nginx के लिए wildcard certificate जारी कर सकता है?

केवल DNS-01 के माध्यम से। *.example.com जैसे wildcard के लिए कोई एक hostname नहीं होता जहाँ से challenge file fetch की जा सके, इसलिए --nginx, --webroot और --standalone सभी विकल्प काम नहीं करते। अपने DNS provider के लिए plugin install करें, एक root-only credentials file में scoped API token रखें, और certbot certonly --dns-cloudflare -d example.com -d '*.example.com' चलाएँ। shell द्वारा globbing से बचने के लिए wildcard को quotes में रखें।

Ubuntu 24.04 पर Certbot इंस्टॉल करने के लिए sudo apt install certbot python3-certbot-nginx का उपयोग करें। apt और snap के बीच चुनाव और पोर्ट 80 रिन्यूअल टाइमआउट की जानकारी यहाँ है।

Certbot इंस्टॉल करें: apt या snap

Ubuntu 24.04 पर, sudo apt install certbot python3-certbot-nginx आपको एक कार्यशील Certbot देता है जो वास्तविक, सार्वजनिक रूप से विश्वसनीय Let's Encrypt सर्टिफिकेट जारी करता है। Certbot के अपस्ट्रीम दस्तावेज़ आपको snap का उपयोग करने का सुझाव देते हैं; दोनों में अंतर बहुत कम है, snap अपस्ट्रीम रिलीज़ को ट्रैक करता है, जबकि आर्काइव पैकेज LTS के साथ आने वाले वर्ज़न को ट्रैक करता है और सुरक्षा अपडेट प्राप्त करता है।

किसी एक को चुनें। Certbot की दो प्रतियों का मतलब है कि एक ही /etc/letsencrypt ट्री पर दो रिन्यूअल टाइमर सेट हो जाएंगे, और जिसे आप भूल जाएंगे, वही आपको परेशानी में डालेगा।

apt का तरीका:

sudo apt update
sudo apt install certbot python3-certbot-nginx

यह /usr/bin/certbot, nginx प्लगइन, एक certbot.service + certbot.timer जोड़ी, और एक /etc/cron.d/certbot एंट्री इंस्टॉल करता है जो systemd के तहत कोई कार्य नहीं करती (no-op)।

snap का तरीका:

sudo apt remove certbot python3-certbot-nginx
sudo snap install core && sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

snap अपना स्वयं का टाइमर, snap.certbot.renew.timer, साथ लाता है। snap इंस्टॉल करने से पहले apt पैकेज को हटा दें।

दोनों इंस्टॉलेशन के बाद एक समान व्यवहार करते हैं, सिवाय इसके कि वे रिन्यूअल का निर्णय कब लेते हैं (नीचे 'Renewal' अनुभाग में वर्णित)। Certbot 2.x डिफ़ॉल्ट रूप से ECDSA (P-256) कीज़ का उपयोग करता है, केवल उन क्लाइंट्स के लिए --key-type rsa पास करें जो ECDSA का समर्थन नहीं करते हैं। सभी स्टेट /etc/letsencrypt के अंतर्गत रहते हैं: archive/ में वास्तविक की और सर्टिफिकेट फाइलें होती हैं, live/ वर्तमान फाइलों के लिए सिम्बॉलिक लिंक (symlinks) रखता है, renewal/ में प्रति सर्टिफिकेट एक कॉन्फ़िगरेशन फाइल होती है, और accounts/ में आपकी ACME अकाउंट की होती है।

HTTP-01 वास्तव में क्या करता है, और पोर्ट 80 वैकल्पिक क्यों नहीं है

HTTP-01 challenge एक callback है। आप Let's Encrypt से example.com को कवर करने वाले certificate का अनुरोध करते हैं; यह public DNS में नाम को resolve करता है, उसे मिलने वाले पते पर port 80 के लिए एक connection खोलता है, और http://example.com/.well-known/acme-challenge/<token> का अनुरोध करता है। आपका सर्वर उस सटीक token सामग्री के साथ उत्तर देता है जिसे Certbot ने अभी-अभी डिस्क पर लिखा है। यही पूरी प्रक्रिया है। इसके तीन परिणाम निकलते हैं, और वे अधिकांश विफल issuances के लिए जिम्मेदार हैं।

Port 80 को public internet से पहुंच योग्य होना चाहिए, न कि केवल आपके लैपटॉप से। एक ufw नियम, cloud-provider security group, या VPS-console firewall जो केवल 443 को खोलता है, वह issuance और भविष्य के हर renewal को बाधित कर देता है।
DNS को पहले से ही इस बॉक्स की ओर इशारा करना चाहिए। validation सर्वर बाहर से अपना स्वयं का lookup करता है; आपकी /etc/hosts entries और browser cache का उसके लिए कोई अर्थ नहीं है।
यदि आप AAAA record प्रकाशित करते हैं, तो IPv6 को पहले आजमाया जाता है। Let's Encrypt केवल तभी IPv4 पर पुनः प्रयास करता है जब IPv6 connection का समय समाप्त हो जाता है। एक refused IPv6 connection को पुनः प्रयास नहीं किया जाता है, और एक पुराना AAAA record जो किसी ऐसे host की ओर इशारा करता है जो connection को accept करता है और कुछ और serve करता है, वह आपको एक hard failure देता है।

Redirects की अनुमति है: validation एक HTTP redirect का पालन करके HTTPS पर जाता है और उसे इस बात की परवाह नहीं होती कि दूसरे छोर पर certificate गायब है, expired है या self-signed है। वह जो नहीं करेगा, वह यह है कि वह port 80 के अलावा कहीं और से शुरू नहीं करेगा। Certbot में कोई TLS-ALPN-01 implementation नहीं है, इसलिए "बस 443 का उपयोग करें" कोई विकल्प नहीं है।

Authenticator का चयन: --nginx, --webroot, --standalone

--nginx सही डिफ़ॉल्ट है जब nginx पहले से चल रहा हो और डोमेन को सर्व कर रहा हो। Certbot आपके कॉन्फ़िगरेशन को पार्स करता है, एक अस्थायी चैलेंज लोकेशन इंजेक्ट करता है, nginx को रीलोड करता है, वैलिडेट करता है, और फिर TLS डायरेक्टिव्स को आपके सर्वर ब्लॉक में लिख देता है। इसमें कोई डाउनटाइम नहीं होता।

sudo certbot --nginx -d example.com -d www.example.com

स्क्रिप्टेड, एक नए बॉक्स के लिए:

sudo certbot --nginx \
  -d example.com -d www.example.com \
  --agree-tos -m ops@example.com --no-eff-email \
  --redirect --non-interactive

--webroot तब सही है जब आप नहीं चाहते कि Certbot आपके nginx कॉन्फ़िगरेशन को छुए, जैसे कि जब आप इसे किसी टेम्पलेट से जनरेट करते हैं, git में रखते हैं, या Ansible के साथ पुश करते हैं। Certbot केवल चैलेंज फ़ाइल को उस डायरेक्टरी में लिखता है जिसे आप पहले से सर्व कर रहे हैं।

sudo certbot certonly --webroot -w /var/www/example.com \
  -d example.com -d www.example.com \
  --deploy-hook "systemctl reload nginx"

--standalone तब सही है जब पोर्ट 80 पर कुछ भी लिसन नहीं कर रहा हो: जैसे कि मेल सर्वर, कोई API जो केवल 443 पर बात करती है, या पहली बार बूट होने वाली स्क्रिप्ट जो nginx के अस्तित्व में आने से पहले चलती है। Certbot कुछ सेकंड के लिए खुद पोर्ट 80 को बाइंड कर लेता है। यदि nginx चल रहा है, तो यह विफल हो जाएगा, इसलिए रन के दौरान इसे रोक दें:

sudo certbot certonly --standalone -d mail.example.com \
  --pre-hook "systemctl stop nginx" \
  --post-hook "systemctl start nginx"

ये हुक सर्टिफिकेट के रिन्यूअल कॉन्फ़िगरेशन में रिकॉर्ड हो जाते हैं, इसलिए रिन्यूअल के समय वही स्टॉप/स्टार्ट प्रक्रिया बिना किसी मानवीय हस्तक्षेप के पूरी हो जाती है।

एक सर्वर ब्लॉक जो सर्टिफिकेट होने से पहले और बाद में काम करता है

चिकन-एंड-एग (अंडे और मुर्गी) वाली समस्या: nginx उस स्थिति में स्टार्ट होने से मना कर देता है जब ssl_certificate किसी ऐसी फाइल की ओर इशारा करता हो जो मौजूद नहीं है, और Certbot तब तक वैलिडेट नहीं कर सकता जब तक nginx डाउन हो। इसलिए साइट को पहले पोर्ट 80 पर चालू करें।

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    root /var/www/example.com;
    index index.html;

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/example.com;
        default_type "text/plain";
        try_files $uri =404;
    }

    location / {
        try_files $uri $uri/ =404;
    }
}

sudo nginx -t && sudo systemctl reload nginx चलाएं, सुनिश्चित करें कि curl -I http://example.com/ बॉक्स के बाहर से जवाब दे रहा है, और फिर सर्टिफिकेट जारी करें। इसके बाद:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/example.com;
        default_type "text/plain";
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    root /var/www/example.com;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

लंबा ACME प्रीफिक्स पहले ही location / को मात दे देता है, इसलिए return 301 कभी भी चैलेंज रिक्वेस्ट नहीं देख पाता। ^~ मॉडिफायर अन्य जगहों पर उपयोगी होता है: एक बार जब वह प्रीफिक्स मैच हो जाता है, तो nginx regex लोकेशन्स को पूरी तरह छोड़ देता है, इसलिए बाद में जोड़ा गया कोई नियम जैसे कि location ~ /\. { deny all; } चैलेंज को ब्लॉक नहीं कर सकता। इस लोकेशन को पोर्ट 80 पर रखने का मतलब है कि बाकी साइट के HTTPS-ओनली हो जाने के बाद भी रिन्यूअल काम करते रहेंगे।

ऊपर दिए गए दोनों ब्लॉक डिस्क से फाइल सर्व करते हैं; यदि nginx किसी एप्लिकेशन के सामने है, तो location / एक proxy_pass ब्लॉक बन जाता है और रिवर्स प्रॉक्सी सर्वर ब्लॉक, लाइन-दर-लाइन उन हेडर को कवर करता है जिनकी उस ऐप को आवश्यकता है, जबकि ACME लोकेशन और TLS डायरेक्टिव बिल्कुल वैसे ही रहते हैं।

HTTP/2 सिंटैक्स आपके nginx वर्जन पर निर्भर करता है। Ubuntu 24.04 में nginx 1.24 आता है, जिसे यह इनलाइन चाहिए होता है, listen 443 ssl http2;, और यदि आप इसे अलग http2 on; डायरेक्टिव देते हैं तो यह स्टार्ट होने में विफल हो जाता है। Debian 13 में nginx 1.26 आता है, जिसे http2 on; चाहिए और वह केवल चेतावनी देता है कि इनलाइन फॉर्म अब पुराना (deprecated) हो चुका है। पहले nginx -v की जांच करें।

nginx को live/ पर पॉइंट करें, कभी भी archive/ पर नहीं। live/ सिमलिनक्स (symlinks) हर रिन्यूअल पर दोबारा पॉइंट किए जाते हैं; archive/ में हार्ड पाथ आपको एक ऐसे सर्टिफिकेट से बांध देता है जो समय के साथ एक्सपायर हो जाएगा।

Wildcard का अर्थ है DNS-01, और DNS-01 का अर्थ है एक plugin

Wildcard certificate (*.example.com) को HTTP-01 के माध्यम से validate नहीं किया जा सकता है, क्योंकि इसमें file fetch करने के लिए कोई एक single hostname नहीं होता है। DNS-01 ही एकमात्र रास्ता है: आप एक _acme-challenge.example.com TXT record publish करके अपना control साबित करते हैं। इसे unattended तरीके से करने के लिए Certbot को आपके DNS provider के API credentials की आवश्यकता होती है, और इसी उद्देश्य के लिए provider plugins मौजूद हैं। Wildcard certificate की पूरी प्रक्रिया में TXT record की कार्यप्रणाली और manual mode में renewal की समस्या को समझाया गया है; नीचे इसका संक्षिप्त Cloudflare संस्करण दिया गया है।

sudo snap set certbot trust-plugin-with-root=ok
sudo snap install certbot-dns-cloudflare

apt path पर इसके बजाय sudo apt install python3-certbot-dns-cloudflare का उपयोग करें। Credentials को केवल root द्वारा access की जा सकने वाली file में रखें:

# /root/.secrets/cloudflare.ini
# then: sudo chmod 600 /root/.secrets/cloudflare.ini
dns_cloudflare_api_token = your_scoped_token_here

Token को केवल उस एक zone पर DNS-edit अधिकारों तक सीमित रखें। यह आपके DNS की एक key है; इसे उसी तरह सुरक्षित रखें।

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

Wildcard को quote करें ताकि आपका shell इसे glob न करे। DNS-01 उन समस्याओं को भी हल करता है जिन्हें HTTP-01 नहीं कर सकता: ऐसे hosts के लिए certificates जिनके पास public port 80 नहीं है, कोई internal service, केवल VPS पर self-hosted WireGuard VPN के माध्यम से पहुँच योग्य box, या private interface पर स्थित admin panel।

नवीनीकरण: 90 दिन, टाइमर और डिप्लॉय हुक

Let’s Encrypt सर्टिफिकेट 90 दिनों के लिए वैध होते हैं। apt पैकेज (Certbot 2.9.0) तब नवीनीकरण करता है जब 30 दिनों से कम समय शेष रहता है। snap वर्तमान Certbot को ट्रैक करता है, जो संस्करण 4.1 के बाद से ACME Renewal Info (ARI) के माध्यम से Let’s Encrypt से नवीनीकरण के लिए सुझाया गया समय भी मांगता है और पहले नवीनीकरण कर सकता है; Let’s Encrypt सर्टिफिकेट के लिए इसका सामान्यतः अर्थ उसके जीवनकाल का लगभग दो-तिहाई हिस्सा होता है। किसी भी स्थिति में, आपको लगभग 30 दिनों की विंडो मिलती है जिसमें एक विफल नवीनीकरण को ठीक करना एक छोटी समस्या है, न कि आउटेज। अगले वर्ष से नवीनीकरण अधिक बार होने की अपेक्षा रखें: Let’s Encrypt का डिफ़ॉल्ट प्रोफ़ाइल 10 फरवरी, 2027 को 64-दिवसीय सर्टिफिकेट पर और 16 फरवरी, 2028 को 45-दिवसीय सर्टिफिकेट पर स्थानांतरित हो जाएगा। Let’s Encrypt अब समाप्ति-चेतावनी ईमेल नहीं भेजता है, कोई भी आपको याद दिलाने नहीं आएगा, इसलिए निगरानी अब आपकी जिम्मेदारी है।

अपने इंस्टॉलेशन द्वारा प्रदान किए गए टाइमर की जाँच करें:

systemctl list-timers 'certbot*' 'snap.certbot*'
sudo certbot certificates

certbot renew, /etc/letsencrypt/renewal/ में मौजूद प्रत्येक कॉन्फ़िगरेशन को देखता है, जो अभी नवीनीकरण के लिए देय नहीं हैं उन्हें छोड़ देता है, और बाकी को उस कॉन्फ़िगरेशन में सहेजे गए विकल्पों का उपयोग करके नवीनीकृत करता है। ये मूल रन के फ्लैग होते हैं, जब तक कि आपने उन्हें बाद में certbot reconfigure के साथ न बदला हो। इसीलिए पहला रन महत्वपूर्ण है: यही वह रन है जो रिकॉर्ड किया जाता है।

डिस्क पर फ़ाइल को नवीनीकृत करने से अपने आप कुछ नहीं बदलता है, nginx पुराने सर्टिफिकेट को मेमोरी से सर्व करना जारी रखता है जब तक कि उसे रिलोड करने के लिए न कहा जाए। एक बार डिप्लॉय हुक सेट करें:

sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh >/dev/null <<'EOF'
#!/bin/sh
set -e
nginx -t && systemctl reload nginx
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

renewal-hooks/deploy/ में कोई भी निष्पादन योग्य (executable) फ़ाइल किसी भी सफल नवीनीकरण के बाद चलती है। --deploy-hook फ्लैग एक सर्टिफिकेट के लिए वही काम करता है, और renew_hook = ... को उसके नवीनीकरण कॉन्फ़िगरेशन में संग्रहीत करता है। certbot --nginx आपके लिए रिलोड करता है; --webroot और --standalone सेटअप ऐसा नहीं करते हैं। हुक का न होना ही वह कारण है कि साइट एक एक्सपायर्ड सर्टिफिकेट सर्व करती है जबकि certbot certificates खुशी-खुशी एक नया सर्टिफिकेट रिपोर्ट करता है। स्टार्टअप पर सर्टिफिकेट पढ़ने वाली किसी भी अन्य चीज़ को भी उसी हुक की आवश्यकता होती है, एक कंटेनरीकृत ऐप जैसे कि Nextcloud VPS install with Docker, TLS and backups को भी यहाँ अपना रीस्टार्ट या रिलोड स्टेप सेट करने की आवश्यकता होती है।

वास्तविक renewal का परीक्षण

sudo certbot renew --dry-run

यह Let's Encrypt के staging environment के विरुद्ध पूर्ण challenge चलाता है: समान code path, समान firewall, समान DNS, और आपकी production rate limits के विरुद्ध कुछ भी count नहीं होता (staging की अपनी, कहीं अधिक उदार सीमाएँ हैं), और कोई भी certificate disk पर save नहीं होता। यदि यह आज सफल होता है, तो 60 दिनों में होने वाला unattended renewal भी सफल होगा, बशर्ते कि सर्वर के नीचे कुछ भी न बदले।

Dry run यह साबित नहीं करता कि आपका reload hook चलता है, क्योंकि Certbot के version के आधार पर व्यवहार अलग हो सकता है। उस हिस्से का परीक्षण मैन्युअल रूप से करें: hook script को सीधे execute करें, पुष्टि करें कि systemctl reload nginx सफल होता है, और sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf की जाँच करें।

वे त्रुटियाँ जिनका आपको वास्तव में सामना करना पड़ेगा

Could not bind to IPv4 or IPv6., --standalone जबकि nginx पहले से ही port 80 का उपयोग कर रहा है। --nginx या --webroot का उपयोग करें, या रन के दौरान nginx को रोक दें। sudo ss -lntp | grep ':80' के साथ पुष्टि करें कि port का उपयोग कौन कर रहा है।

Timeout during connect (likely firewall problem), Let's Encrypt port 80 तक नहीं पहुँच सका। बाहर की ओर जाँच करें: sudo ufw status (इसे sudo ufw allow 'Nginx Full' के साथ खोलें), फिर VPS प्रदाता का अपना firewall, और अंत में DNS। अपने सर्वर के बाहर किसी अन्य स्थान से परीक्षण करें: curl -sSv http://example.com/.well-known/acme-challenge/test। एक पुराना AAAA record भी यही संदेश उत्पन्न करता है।

unauthorized :: Invalid response from http://example.com/.well-known/acme-challenge/xyz: 404, port 80 पहुँच योग्य है, लेकिन token सर्व नहीं हो रहा है। अनुरोध किसी भिन्न server block में चला गया है (जाँचें कि default_server का स्वामी कौन है), या -w को दिया गया directory वह नहीं है जिसे nginx सर्व कर रहा है। /var/www/example.com/.well-known/acme-challenge/test पर एक फ़ाइल रखें और उसे बाहरी रूप से फेच करें; यदि वह 404 त्रुटि देता है, तो समस्या certificate की नहीं थी।

DNS problem: NXDOMAIN looking up A for example.com, नाम सार्वजनिक रूप से resolve नहीं हो रहा है। यह नए records के कारण हो सकता है जो अभी तक propagate नहीं हुए हैं, या ऐसे record के कारण जो उस zone में है जिसे आपका registrar सर्व नहीं कर रहा है।

too many certificates (5) already issued ..., एक rate limit, जिसका सामना लोग लूप में डिबगिंग करते समय करते हैं। संदेश सीमा का नाम बताता है और retry after समय पर समाप्त होता है। Let's Encrypt डुप्लिकेट certificates (नामों का बिल्कुल समान सेट) को प्रति सप्ताह पाँच तक सीमित करता है, और इसके लिए कोई override उपलब्ध नहीं है, इसलिए केवल समय ही इसे अनब्लॉक कर सकता है। इसके अलावा, यह प्रति registered domain प्रति सप्ताह 50 नए certificates की अनुमति देता है; उस सीमा को override का अनुरोध करके बढ़ाया जा सकता है। मौजूदा certificate के समान नामों के सेट के लिए अनुरोध को renewal माना जाता है और यह इस सीमा से मुक्त है, और ARI के माध्यम से समन्वित renewals हर सीमा से मुक्त हैं। --dry-run के साथ staging वातावरण पर डिबग करें।

nginx: [emerg] cannot load certificate "/etc/letsencrypt/live/example.com/fullchain.pem": No such file or directory, nginx को ऐसे certificate के लिए कॉन्फ़िगर किया गया है जो कभी जारी नहीं हुआ, या जिसे certbot delete के साथ हटा दिया गया है। TLS server block को comment out करें, nginx शुरू करें, certificate जारी करें, और फिर block को restore करें।

open() "/etc/letsencrypt/options-ssl-nginx.conf" failed, वह फ़ाइल nginx plugin पैकेज के साथ आती है। python3-certbot-nginx के बिना किसी certonly बॉक्स पर, या तो plugin जोड़ें या include लाइन को अपनी ssl_protocols और ssl_ciphers सेटिंग्स से बदलें।

बड़े पैमाने पर इसका प्रबंधन

एक certificate में 100 नाम तक हो सकते हैं, और एक ही certbot --nginx -d a.example.com -d b.example.com ... का उपयोग करना आकर्षक लगता है, लेकिन यदि एक भी पुराना DNS record validation में विफल हो जाता है, तो उस certificate पर मौजूद अन्य सभी नाम भी काम करना बंद कर देते हैं। प्रत्येक साइट के लिए अलग certificate रखने पर वे स्वतंत्र रूप से विफल होते हैं, जो कि एक ऐसे सर्वर के लिए बेहतर है जहाँ कई चीजें होस्ट की जा रही हों। कुछ साइटों से अधिक होने पर, एक ACME-aware front door का उपयोग करना फायदेमंद होता है: एक Docker Compose के तहत कई apps चलाने वाला Traefik reverse proxy स्वयं certificates का अनुरोध और नवीनीकरण (renew) करता है, और Certbot की आवश्यकता पूरी तरह समाप्त हो जाती है। कौन सा proxy front door के लिए उपयुक्त है, यह आपका निर्णय है, और Nginx की तुलना Caddy और Traefik से करना मुख्य रूप से इस बात पर निर्भर करता है कि आप proxy से कितना certificate और प्रति-app कॉन्फ़िगरेशन का काम करवाना चाहते हैं।

/etc/letsencrypt का पूरा बैकअप लें, sudo tar -czf letsencrypt-$(date +%F).tar.gz -C /etc letsencrypt का उपयोग करें, और symlinks को सुरक्षित रखें। उस डायरेक्टरी ट्री में accounts/ होता है, जो आपकी ACME account key है, जिसे आप दोबारा बिल्कुल वैसा ही नहीं बना सकते। एक नए VPS पर जाने की प्रक्रिया सरल है: -a के साथ ट्री को rsync करें, Certbot इंस्टॉल करें, DNS को अपडेट करें, और स्विच करने से पहले certbot renew --dry-run चलाएं।

सर्वर को रीबिल्ड करने या नए LTS पर जाने पर renewal timer आपके साथ नहीं जाता है। किसी भी माइग्रेशन, स्नैपशॉट रिस्टोर, या डिस्ट्रो अपग्रेड के बाद, systemctl list-timers 'certbot*' और एक --dry-run चलाएं। इसे न करने पर 89 दिन बाद, रात के 3 बजे, साइट बंद हो सकती है, जबकि सभी को लग रहा था कि certificate अपने आप renew हो रहा है।

ऊपर दिए गए HTTP-01 रूट्स एक ऐसी मशीन मानते हैं जिसे आप नियंत्रित करते हैं, जिसमें एक public IP और port 80 दुनिया के लिए खुला हो, यानी एक VPS; DNS-01 के लिए इसकी आवश्यकता नहीं होती है। इनकी कार्यप्रणाली किसी भी स्थिति में समान रहती है।

वही certificate चरण nginx के बजाय Apache पर लागू होते हैं, और जब public certificate का विकल्प न हो, तो Ubuntu पर self-signed certificate आंतरिक सेवाओं के लिए काम आता है।

FAQ

क्या मुझे port 80 खुला रखने की आवश्यकता है यदि मेरी साइट केवल HTTPS serve करती है?

हाँ, HTTP-01 challenge के लिए यह आवश्यक है। Let’s Encrypt हमेशा port 80 पर अपना validation request शुरू करता है, और Certbot में कोई TLS-ALPN-01 implementation नहीं है। इसलिए, यदि firewall केवल 443 खुला रखता है, तो यह पहली बार certificate जारी होने और उसके बाद के हर unattended renewal को ब्लॉक कर देगा। port 80 से HTTPS पर redirect करना ठीक है, validation इसका पालन कर लेता है। port 80 को पूरी तरह से छोड़ने का एकमात्र तरीका DNS-01 है, जिसे या तो provider plugin के साथ या Certbot के --manual --preferred-challenges dns के साथ इस्तेमाल किया जा सकता है। इसमें आपको स्वयं TXT record जोड़ना पड़ता है और renewal तब तक automatic नहीं होता जब तक आप --manual-auth-hook script प्रदान न करें।

Ubuntu 24.04 पर nginx के लिए मुझे apt या snap में से कौन सा Certbot install करना चाहिए?

apt का उपयोग करें। sudo apt install certbot python3-certbot-nginx आपको Ubuntu 24.04 पर Certbot 2.9.0 देता है, जो इस गाइड की सभी आवश्यकताओं के लिए पर्याप्त है। यह unattended-upgrades के माध्यम से security patches प्राप्त करता है और इसके लिए snapd की आवश्यकता नहीं होती। snap को केवल तभी चुनें यदि आपको सबसे नया release तुरंत चाहिए या कोई ऐसा DNS plugin चाहिए जो विशेष रूप से केवल snap के रूप में उपलब्ध हो। किसी भी स्थिति में, केवल एक ही चुनें: दो installs का मतलब है दो renewal timers जो एक ही /etc/letsencrypt tree की ओर इशारा कर रहे हैं, और जिसे आप भूल जाएंगे, वही समस्या का कारण बनेगा।

क्या Certbot nginx के लिए wildcard certificate जारी कर सकता है?

केवल DNS-01 के माध्यम से। *.example.com जैसे wildcard के लिए कोई एक hostname नहीं होता जहाँ से challenge file fetch की जा सके, इसलिए --nginx, --webroot और --standalone सभी विकल्प काम नहीं करते। अपने DNS provider के लिए plugin install करें, एक root-only credentials file में scoped API token रखें, और certbot certonly --dns-cloudflare -d example.com -d '*.example.com' चलाएँ। shell द्वारा globbing से बचने के लिए wildcard को quotes में रखें।

सफल renewal के बाद भी nginx पुराना certificate क्यों serve करता है?

nginx certificate को memory में रखता है और disk पर मौजूद नई file को तब तक नहीं पहचानता जब तक उसे reload न किया जाए। certbot --nginx आपके लिए reload करता है, लेकिन --webroot और --standalone runs ऐसा नहीं करते। इसलिए, renewal सफल हो सकता है जबकि browser अभी भी expiring certificate ही दिखाता रहे। /etc/letsencrypt/renewal-hooks/deploy/ में एक executable script डालें जो nginx -t && systemctl reload nginx चलाती हो, और यह हर सफल renewal के बाद अपने आप चल जाएगी।

क्या `certbot renew --dry-run` यह साबित करता है कि renewal काम करेगा?

ज्यादातर मामलों में, हाँ। यह staging environment के खिलाफ वास्तविक challenge चलाता है, जिसमें वही firewall, वही DNS और वही code path होता है। यह आपके production rate limits को प्रभावित नहीं करता और disk पर कोई certificate save नहीं करता, इसलिए इसके पास होने का मतलब है कि network का हिस्सा सही है। हालाँकि, यह पूरी तरह से यह साबित नहीं करता कि आपका deploy hook चलेगा। इसे अलग से test करें: hook script को manually चलाएँ और sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf की जाँच करें।

क्या यह लेख उपयोगी था?

#certbot #lets-encrypt #nginx #tls #ubuntu #systemd