लेखक: Matt Connor 2026-07-14 · अपडेट किया गया: 2026-08-23

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

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

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 के रूप में उपलब्ध हो। किसी भी स्थिति में, केवल एक ही चुनें: दो बार इंस्टॉल करने का मतलब है कि दो renewal timers एक ही /etc/letsencrypt tree पर पॉइंट कर रहे हैं, और जो आप भूल जाएंगे, वही समस्या का कारण बनेगा।

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

केवल DNS-01 के माध्यम से। *.example.com जैसे wildcard के लिए कोई एक hostname नहीं होता जहाँ से challenge file प्राप्त की जा सके, इसलिए --nginx, --webroot और --standalone काम नहीं करेंगे। अपने DNS provider के लिए plugin इंस्टॉल करें, एक 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 certificates जारी करता है। Certbot के अपस्ट्रीम दस्तावेज़ आपको snap का उपयोग करने का सुझाव देते हैं; दोनों में अंतर बहुत कम है, snap अपस्ट्रीम releases को ट्रैक करता है, जबकि आर्काइव पैकेज वही ट्रैक करता है जो LTS के साथ आया था और जिसे security fixes मिलते हैं।

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

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 पैकेज को हटा दें।

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

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

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

Port 80 सार्वजनिक इंटरनेट से पहुंच योग्य होना चाहिए, न कि केवल आपके लैपटॉप से। एक ufw नियम, क्लाउड-प्रदाता का सिक्योरिटी ग्रुप, या VPS-console का फायरवॉल जो केवल 443 खोलता है, वह issuance और उसके साथ भविष्य के हर renewal को बाधित करता है।
DNS को पहले से ही इस बॉक्स पर पॉइंट करना चाहिए। वैलिडेशन सर्वर बाहर से अपनी खुद की lookup करता है; आपकी /etc/hosts प्रविष्टियां और ब्राउज़र कैश का उसके लिए कोई अर्थ नहीं है।
यदि आप AAAA रिकॉर्ड प्रकाशित करते हैं, तो IPv6 को पहले आजमाया जाता है। जब IPv6 कनेक्शन पूरी तरह विफल हो जाता है तो Let's Encrypt IPv4 पर पुनः प्रयास करता है, लेकिन एक पुराना AAAA रिकॉर्ड जो ऐसे होस्ट पर लक्षित हो जो कनेक्शन स्वीकार करता है और कुछ और सर्व करता है, तो आपको एक कठिन विफलता (hard failure) मिलती है।

Redirects की अनुमति है: वैलिडेशन एक HTTP redirect का पालन करके HTTPS पर जाता है और उसे इस बात की परवाह नहीं होती कि दूसरे छोर पर सर्टिफिकेट गायब है, समाप्त हो गया है या self-signed है। वह जो नहीं करेगा, वह यह है कि पोर्ट 80 के अलावा कहीं और से शुरुआत करना। Certbot में कोई TLS-ALPN-01 कार्यान्वयन नहीं है, इसलिए "बस 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 उस स्थिति में start होने से मना कर देता है जब ssl_certificate किसी ऐसी फाइल को पॉइंट कर रहा हो जो मौजूद नहीं है, और Certbot तब तक validate नहीं कर सकता जब तक nginx down हो। इसलिए पहले साइट को port 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/ बॉक्स के बाहर से जवाब दे रहा है, और फिर issue कमांड दें। इसके बाद:

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 ब्लॉक को challenge request को निगलने से रोकता है। इस location को port 80 पर बनाए रखने का मतलब है कि बाकी साइट के HTTPS-only हो जाने के बाद भी renewals काम करते रहेंगे।

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

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

nginx को live/ पर पॉइंट करें, कभी भी archive/ पर नहीं। live/ सिमलिनक्स हर renewal पर अपडेट होते हैं; 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 दिनों के लिए वैध होते हैं। Certbot तब नवीनीकरण करता है जब 30 दिन से कम समय शेष रहता है। यह आपको 30 दिनों की एक विंडो देता है, जिसमें नवीनीकरण विफल होने पर उसे ठीक करना एक छोटी समस्या है, न कि कोई बड़ी रुकावट। Let's Encrypt अब समाप्ति की चेतावनी वाले ईमेल नहीं भेजता है, कोई भी आपको याद दिलाने नहीं आएगा, इसलिए निगरानी की जिम्मेदारी अब आपकी है।

अपने इंस्टॉलेशन के साथ आए टाइमर की जाँच करें:

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

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

डिस्क पर फ़ाइल को नवीनीकृत करने से अपने आप कुछ नहीं बदलता है, 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 खुशी-खुशी एक नया सर्टिफिकेट होने की रिपोर्ट देता है। स्टार्टअप पर सर्टिफिकेट पढ़ने वाली किसी भी अन्य चीज़ को भी उसी हुक की आवश्यकता होती है, जैसे कि Docker, TLS और बैकअप के साथ Nextcloud VPS इंस्टॉलेशन जैसा कंटेनरीकृत ऐप, जिसे यहाँ अपना स्वयं का रीस्टार्ट या रिलोड स्टेप जोड़ने की आवश्यकता होती है।

Renewal का परीक्षण करना

sudo certbot renew --dry-run

यह Let's Encrypt के staging environment के विरुद्ध पूर्ण challenge चलाता है: समान code path, समान firewall, समान DNS, कोई rate-limit लागत नहीं, और disk पर कुछ भी नहीं लिखा जाता। यदि यह आज सफल होता है, तो 60 दिनों में होने वाला unattended renewal भी सफल होगा, बशर्ते कि सर्वर के नीचे की स्थिति में कोई बदलाव न हो।

Dry run यह सिद्ध नहीं करता कि आपका reload hook काम कर रहा है, क्योंकि Certbot के विभिन्न versions में इसका व्यवहार अलग होता है। इस हिस्से का परीक्षण मैन्युअल रूप से करें: hook script को सीधे निष्पादित करें, पुष्टि करें कि 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' के साथ पुष्टि करें कि कौन सा process 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 serve नहीं हो रहा है। अनुरोध किसी अन्य server block में चला गया (जाँचें कि default_server का स्वामी कौन है), या -w को दिया गया directory वह नहीं है जिसे nginx serve कर रहा है। /var/www/example.com/.well-known/acme-challenge/test पर एक फ़ाइल रखें और उसे बाहर से fetch करें; यदि वह 404 error देती है, तो समस्या certificate के साथ नहीं थी।

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

too many certificates already issued for: example.com, यह एक rate limit है, और debugging के दौरान लोग अक्सर इसका सामना करते हैं। Let's Encrypt प्रति सप्ताह पाँच duplicate certificates (समान नामों का सेट) की सीमा तय करता है, और प्रति पंजीकृत domain प्रति सप्ताह 50 नए certificates की अनुमति देता है; समय बीतने के अलावा इसे ठीक करने का कोई अन्य तरीका नहीं है। --dry-run के साथ staging environment पर debug करें।

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

open() "/etc/letsencrypt/options-ssl-nginx.conf" failed, यह फ़ाइल nginx plugin package के साथ आती है। 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 चुनना है यह आपका निर्णय है, और Nginx, Caddy और Traefik की तुलना मुख्य रूप से इस बात पर निर्भर करती है कि आप proxy से कितना certificate और per-app कॉन्फ़िगरेशन का काम करवाना चाहते हैं।

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

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

यह सब एक ऐसी मशीन के लिए है जिसे आप नियंत्रित करते हैं, जिसमें एक public IP है और port 80 दुनिया के लिए खुला है, यानी एक VPS। ऊपर बताई गई प्रक्रिया इनमें से किसी पर भी समान रूप से लागू होती है।

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

FAQ

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

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

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

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 के रूप में उपलब्ध हो। किसी भी स्थिति में, केवल एक ही चुनें: दो बार इंस्टॉल करने का मतलब है कि दो renewal timers एक ही /etc/letsencrypt tree पर पॉइंट कर रहे हैं, और जो आप भूल जाएंगे, वही समस्या का कारण बनेगा।

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

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

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

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 होता है। इसमें कोई rate-limit cost नहीं लगती और disk पर कुछ भी नहीं लिखा जाता, इसलिए इसके पास होने का मतलब है कि network का हिस्सा सही है। हालाँकि, यह पूरी तरह से साबित नहीं करता कि आपका deploy hook चलेगा। इसे अलग से टेस्ट करें: hook script को मैन्युअल रूप से चलाएं और sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf की जाँच करें।

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

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

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

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

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

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

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

Renewal का परीक्षण करना

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

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

FAQ

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

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

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

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

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

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