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

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

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

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

Q: क्या Certbot nginx के लिए वाइल्डकार्ड प्रमाणपत्र जारी कर सकता है?

केवल DNS-01 के माध्यम से। *.example.com जैसे वाइल्डकार्ड के पास चुनौती फ़ाइल प्राप्त करने के लिए कोई एकल होस्टनाम नहीं है, इसलिए --nginx, --webroot और --standalone सभी बाहर हैं। अपने DNS प्रदाता के लिए प्लगइन इंस्टॉल करें, एक रूट-केवल क्रेडेंशियल फ़ाइल में एक स्कोप्ड API टोकन डालें, और certbot certonly --dns-cloudflare -d example.com -d '*.example.com' चलाएँ, शेल को ग्लोबिंग से रोकने के लिए वाइल्डकार्ड को उद्धृत करें।

sudo apt install certbot python3-certbot-nginx फिर एक certbot --nginx रन। apt और snap का अंतर, port 80 रिन्यूअल टाइमआउट और ECDSA डिफ़ॉल्ट समेत पूरी जानकारी।

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 के तहत निष्क्रिय रहती है।

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) कुंजियों का उपयोग करता है, --key-type rsa केवल उस क्लाइंट के लिए पास करें जो ECDSA नहीं कर सकता। सारी स्थिति /etc/letsencrypt के अंतर्गत रहती है: archive/ में वास्तविक कुंजी और प्रमाणपत्र फ़ाइलें होती हैं, live/ वर्तमान फ़ाइलों के लिए सिमलिंक करता है, renewal/ में प्रति प्रमाणपत्र एक कॉन्फ़िग फ़ाइल होती है, accounts/ में आपकी ACME खाता कुंजी होती है।

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

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

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

रीडायरेक्ट की अनुमति है: सत्यापन HTTP रीडायरेक्ट का HTTPS पर अनुसरण करता है और इसकी परवाह नहीं करता कि दूसरे छोर पर प्रमाणपत्र गुम है, समाप्त हो चुका है या स्व-हस्ताक्षरित है। यह पोर्ट 80 के अलावा कहीं और से शुरू नहीं करेगा। Certbot के पास TLS-ALPN-01 कार्यान्वयन नहीं है, इसलिए "केवल 443 का उपयोग करें" कोई विकल्प नहीं है।

प्रमाणक का चयन: --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 किसी ऐसी फ़ाइल की ओर इशारा करता है जो मौजूद नहीं है, और जब nginx डाउन है तो Certbot मान्य नहीं कर सकता। पहले साइट को पोर्ट 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 स्थान पर ^~ उपसर्ग अपनी उपयोगिता सिद्ध करता है: यह return 301 ब्लॉक को चुनौती अनुरोध को निगलने से रोकता है। उस स्थान को पोर्ट 80 पर रखने का अर्थ है कि शेष साइट के केवल-HTTPS हो जाने के बाद भी नवीनीकरण कार्य करते रहते हैं।

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

nginx को live/ की ओर इंगित करें, कभी भी archive/ की ओर नहीं। live/ सिमलिंक हर नवीनीकरण पर पुनः इंगित हो जाते हैं; archive/ में एक हार्ड पथ आपको एक ऐसे प्रमाणपत्र से बाँध देता है जो आपके उपयोग के दौरान समाप्त हो जाता है।

वाइल्डकार्ड का मतलब DNS-01 है, और DNS-01 का मतलब एक प्लगइन है

एक वाइल्डकार्ड प्रमाणपत्र (*.example.com) को HTTP-01 के ज़रिए मान्य नहीं किया जा सकता, क्योंकि फ़ाइल लाने के लिए कोई एकल होस्टनाम नहीं है। DNS-01 ही एकमात्र रास्ता है: आप एक _acme-challenge.example.com TXT रिकॉर्ड प्रकाशित करके नियंत्रण सिद्ध करते हैं। Certbot को बिना निगरानी के ऐसा करने के लिए आपके DNS प्रदाता के API क्रेडेंशियल्स की आवश्यकता होती है, और इसीलिए प्रदाता प्लगइन्स मौजूद हैं। पूर्ण वाइल्डकार्ड प्रमाणपत्र वॉकथ्रू TXT रिकॉर्ड की कार्यप्रणाली और मैन्युअल मोड में नवीनीकरण की समस्या को कवर करता है; इसके बाद संक्षिप्त Cloudflare संस्करण दिया गया है।

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

apt पथ पर यह इसके बजाय sudo apt install python3-certbot-dns-cloudflare है। क्रेडेंशियल्स केवल-रूट फ़ाइल में जाते हैं:

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

टोकन का दायरा उस एक ज़ोन पर DNS-संपादन अधिकारों तक सीमित रखें। यह आपके DNS की एक कुंजी है; इसे वैसे ही संभालें।

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

वाइल्डकार्ड को कोट करें ताकि आपका शेल इसे ग्लोब न करे। DNS-01 वह भी हल करता है जो HTTP-01 नहीं कर सकता: ऐसे होस्ट के लिए प्रमाणपत्र जिनका कोई सार्वजनिक पोर्ट 80 नहीं है, एक आंतरिक सेवा, एक मशीन जो केवल VPS पर स्व-होस्टेड WireGuard VPN के ज़रिए पहुँच योग्य है, एक निजी इंटरफ़ेस पर एक व्यवस्थापक पैनल।

नवीनीकरण: 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/ में कोई भी निष्पादन योग्य किसी भी सफल नवीनीकरण के बाद चलता है। --deploy-hook फ़्लैग एक प्रमाणपत्र के लिए वही काम करता है, renew_hook = ... को इसके नवीनीकरण कॉन्फ़िग में संग्रहीत करता है। certbot --nginx आपके लिए रीलोड करता है; --webroot और --standalone सेटअप नहीं करते हैं। एक गुम हुक ठीक यही कारण है कि एक साइट एक समाप्त प्रमाणपत्र परोसती है जबकि certbot certificates खुशी से एक ताज़ा प्रमाणपत्र की रिपोर्ट करता है। कुछ भी जो स्टार्टअप पर प्रमाणपत्र पढ़ता है, वही हुक चाहता है, एक कंटेनरीकृत ऐप जैसे कि Docker, TLS और बैकअप के साथ Nextcloud VPS इंस्टॉल को यहाँ भी अपने स्वयं के पुनरारंभ या रीलोड चरण की आवश्यकता होती है।

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

sudo certbot renew --dry-run

यह Let's Encrypt के स्टेजिंग परिवेश के विरुद्ध पूर्ण चुनौती चलाता है: वही कोड पथ, वही फ़ायरवॉल, वही DNS, कोई दर-सीमा लागत नहीं, डिस्क पर कुछ नहीं लिखा जाता। यदि यह आज सफल होता है, तो 60 दिनों में स्वचालित नवीनीकरण भी सफल होगा, बशर्ते कि सर्वर में कोई अंतर्निहित परिवर्तन न हो।

ड्राई रन यह सिद्ध नहीं करता कि आपका रीलोड हुक सक्रिय होता है, इसका व्यवहार Certbot संस्करण के अनुसार भिन्न होता है। उस भाग का परीक्षण स्वयं करें: हुक स्क्रिप्ट को सीधे निष्पादित करें, पुष्टि करें कि systemctl reload nginx सफल होता है, और sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf की जाँच करें।

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

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

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

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

DNS problem: NXDOMAIN looking up A for example.com, नाम सार्वजनिक रूप से हल नहीं होता है। नए रिकॉर्ड जो प्रसारित नहीं हुए हैं, या एक ऐसे ज़ोन में रिकॉर्ड जिसे आपका रजिस्ट्रार सेवा नहीं दे रहा है।

too many certificates already issued for: example.com, एक दर सीमा, और जिसका सामना लोग लूप में डीबग करते समय करते हैं। Let's Encrypt डुप्लिकेट प्रमाणपत्रों, नामों का बिल्कुल वही सेट, को प्रति सप्ताह पाँच तक सीमित करता है, और अलग से प्रति पंजीकृत डोमेन प्रति सप्ताह 50 नए प्रमाणपत्रों की अनुमति देता है; समय के अलावा कुछ भी किसी को अनब्लॉक नहीं करता है। --dry-run के साथ स्टेजिंग के विरुद्ध डीबग करें।

nginx: [emerg] cannot load certificate "/etc/letsencrypt/live/example.com/fullchain.pem": No such file or directory, nginx एक ऐसे प्रमाणपत्र के लिए कॉन्फ़िगर किया गया है जो कभी जारी नहीं किया गया, या जिसे certbot delete से हटा दिया गया है। TLS सर्वर ब्लॉक को टिप्पणी करें, nginx प्रारंभ करें, जारी करें, ब्लॉक को पुनर्स्थापित करें।

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

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

एक प्रमाणपत्र 100 नामों तक ले जा सकता है, और एक अकेला certbot --nginx -d a.example.com -d b.example.com ... आकर्षक लगता है, जब तक कि एक पुराना DNS रिकॉर्ड सत्यापन में विफल नहीं हो जाता और उस प्रमाणपत्र के बाकी सभी नामों को अपने साथ नीचे नहीं ले जाता। प्रति साइट अलग-अलग प्रमाणपत्र स्वतंत्र रूप से विफल होते हैं, जो कि आप एक ऐसे सर्वर पर चाहते हैं जो कुछ से अधिक चीज़ें होस्ट करता है। कुछ साइटों से आगे बढ़ने पर, एक ACME-सचेत फ्रंट डोर अपनी उपयोगिता सिद्ध करता है: एक Docker Compose के तहत कई ऐप्स चलाने वाला Traefik रिवर्स प्रॉक्सी स्वयं प्रमाणपत्रों का अनुरोध और नवीनीकरण करता है, और Certbot पूरी तरह से तस्वीर से बाहर हो जाता है।

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

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

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

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

FAQ

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

हाँ, HTTP-01 चुनौती के लिए। Let's Encrypt हमेशा अपना सत्यापन अनुरोध पोर्ट 80 पर शुरू करता है, और Certbot में TLS-ALPN-01 का कार्यान्वयन नहीं है, इसलिए केवल 443 खोलने वाला फ़ायरवॉल पहले जारीकरण और उसके बाद के हर स्वचालित नवीनीकरण को रोक देता है। पोर्ट 80 से HTTPS पर रीडायरेक्ट ठीक है, सत्यापन उसका अनुसरण करता है। पोर्ट 80 को पूरी तरह छोड़ने का एकमात्र तरीका प्रदाता प्लगइन के साथ DNS-01 है।

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

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

क्या Certbot nginx के लिए वाइल्डकार्ड प्रमाणपत्र जारी कर सकता है?

केवल DNS-01 के माध्यम से। *.example.com जैसे वाइल्डकार्ड के पास चुनौती फ़ाइल प्राप्त करने के लिए कोई एकल होस्टनाम नहीं है, इसलिए --nginx, --webroot और --standalone सभी बाहर हैं। अपने DNS प्रदाता के लिए प्लगइन इंस्टॉल करें, एक रूट-केवल क्रेडेंशियल फ़ाइल में एक स्कोप्ड API टोकन डालें, और certbot certonly --dns-cloudflare -d example.com -d '*.example.com' चलाएँ, शेल को ग्लोबिंग से रोकने के लिए वाइल्डकार्ड को उद्धृत करें।

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

nginx प्रमाणपत्र को मेमोरी में रखता है और डिस्क पर नई फ़ाइल को तब तक नोटिस नहीं करता जब तक वह पुनः लोड न हो। certbot --nginx आपके लिए पुनः लोड करता है, लेकिन --webroot और --standalone रन नहीं करते, इसलिए नवीनीकरण सफल हो सकता है जबकि ब्राउज़र अभी भी एक समाप्त हो रहा प्रमाणपत्र देखता है। /etc/letsencrypt/renewal-hooks/deploy/ में एक निष्पादन योग्य स्क्रिप्ट डालें जो nginx -t && systemctl reload nginx चलाती है, और यह हर सफल नवीनीकरण के बाद सक्रिय होती है।

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

अधिकतर। यह स्टेजिंग वातावरण के विरुद्ध वास्तविक चुनौती चलाता है, वही फ़ायरवॉल, वही DNS, वही कोड पथ, बिना किसी दर-सीमा लागत के और डिस्क पर कुछ भी लिखे बिना, इसलिए पास होने का मतलब है कि नेटवर्क वाला हिस्सा ठीक है। हालाँकि, यह विश्वसनीय रूप से साबित नहीं करता कि आपका डिप्लॉय हुक सक्रिय होता है। उसका अलग से परीक्षण करें: हुक स्क्रिप्ट को हाथ से चलाएँ और sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf जाँचें।

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