Ubuntu 24.04 वर nginx साठी Certbot कसे install करावे

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 जोडी आणि systemd अंतर्गत काहीही करू नये असा /etc/cron.d/certbot नोंदणी प्रतिष्ठापित करते.

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) की वापरते — ECDSA हाताळू शकणाऱ्या क्लाएंटसाठी फक्त --key-type rsa वापरा. सर्व स्थिती /etc/letsencrypt अंतर्गत असते: archive/ मध्ये वास्तविक की आणि प्रमाणपत्र फायली असतात, live/ वर्तमान फायलींच्या symlinks असतात, 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 नियम, क्लाउड-प्रदात्याचा सुरक्षा गट, किंवा फक्त 443 उघडणारा VPS-कन्सोल फायरवॉल प्रमाणपत्र निर्गमन आणि त्याबरोबर प्रत्येक भविष्यातील नूतनीकरण अयशस्वी करतो.
• DNS आधीच या सर्व्हरकडे निर्देशित केले पाहिजे. पडताळणी सर्व्हर बाहेरून स्वतःचा शोध घेतो; तुमचे /etc/hosts नोंदी आणि ब्राउझर कॅशे त्यास काहीच फरक पडवत नाहीत.
• तुम्ही AAAA रेकॉर्ड प्रकाशित केल्यास, IPv6 आधी वापरले जाते. IPv6 जोडणी पूर्णपणे अयशस्वी झाल्यास Let's Encrypt IPv4 वर पुन्हा प्रयत्न करते — परंतु एखाद्या असे होस्टकडे निर्देशित असलेला जुना 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 वर काहीही ऐकत नसते: मेल सर्व्हर, फक्त 443 बोलणारा API, किंवा nginx अस्तित्वात येण्यापूर्वी चालणारी फर्स्ट-बूट स्क्रिप्ट. Certbot काही सेकंदांसाठी पोर्ट 80 स्वतःला बांधते. जर nginx चालू असेल, तर हे अयशस्वी होते — रनवेळी ते थांबवा:

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

हे हुक सर्टिफिकेटच्या रिन्युअल कॉन्फिगरेशनमध्ये नोंदलेले असतात, म्हणून रिन्युअल वेळी समान स्टॉप/स्टार्ट अनअटेंडेडपणे होतो.

प्रमाणपत्र अस्तित्वात असण्यापूर्वी आणि नंतरही काम करणारा server block

हे एक अडचण आहे: 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 location वरील ^~ प्रीफिक्स उपयुक्त ठरते: ते return 301 block ला challenge विनंती गिळंकृत करण्यापासून थांबवते. ती location पोर्ट 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/ symlinks प्रत्येक नूतनीकरणावर पुन्हा निर्देशित केले जातात; archive/ मधील ठराविक मार्ग तुम्हाला अशा प्रमाणपत्राशी जोडतो जे तुमच्याच डोळ्यासमोर कालबाह्य होईल.

वाइल्डकार्ड म्हणजे DNS-01, आणि DNS-01 म्हणजे प्लगइन

वाइल्डकार्ड प्रमाणपत्र (*.example.com) HTTP-01 द्वारे प्रमाणित करता येत नाही, कारण फाइल घेण्यासाठी एकही एकल hostname नसतो. 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 वाचू शकेल अशा फाइलमध्ये ठेवा:

# /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 शकत नाही: सार्वजनिक port 80 नसलेल्या होस्टसाठी प्रमाणपत्रे — एखादी अंतर्गत सेवा, केवळ VPS वर स्वतःचे WireGuard VPN द्वारे पोहोचता येणारा सर्व्हर, किंवा खाजगी इंटरफेसवरील ॲडमिन पॅनल.

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

Let's Encrypt प्रमाणपत्र 90 दिवसांसाठी वैध असतात. उरलेले दिवस 30 पेक्षा कमी असल्यावर Certbot नूतनीकरण करते. यामुळे तुम्हाला 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 च्या staging environment विरुद्ध संपूर्ण challenge चालवते: समान code path, समान firewall, समान DNS, कोणताही rate-limit खर्च नाही, आणि disk वर काहीही लिहिले जात नाही. जर ते आज यशस्वी झाले, तर 60 दिवसांतील unattended नूतनीकरणही यशस्वी होईल, अपवाद फक्त हा की या दरम्यान प्रणालीत काही बदल झाला नाही.

dry run हे सिद्ध करत नाही की तुमचा reload hook कार्यान्वित होतो — तेथील वर्तन Certbot आवृत्तीनुसार बदलते. तो भाग स्वतः चाचणी करा: hook स्क्रिप्ट थेट कार्यान्वित करा, systemctl reload nginx यशस्वी होते याची खात्री करा, आणि sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf तपासा.

आपल्याला प्रत्यक्षात येणाऱ्या त्रुटी

Could not bind to IPv4 or IPv6. — nginx कडून आधीच port 80 व्यापलेला असताना --standalone. --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 खाते की (account key) असते, जी तुम्ही तशीच पुन्हा तयार करू शकत नाही. नवीन VPS वर स्थलांतर करणे म्हणजे फक्त: ती डिरेक्टरी -a सह rsync करा, Certbot इंस्टॉल करा, DNS रीडायरेक्ट करा आणि बदल करण्यापूर्वी certbot renew --dry-run चालवा.

सर्व्हर पुन्हा तयार केल्यावर किंवा नवीन LTS वर गेल्यावर नूतनीकरण टाइमर तुमच्यासोबत येत नाही. कोणत्याही स्थलांतरानंतर, स्नॅपशॉट रिस्टोअरनंतर किंवा डिस्ट्रो अपग्रेडनंतर systemctl list-timers 'certbot*' आणि एक --dry-run चालवा. हे टाळल्यामुळे 89 दिवसांनी, रात्री 3 वाजता, एक साइट बंद पडते, ज्या प्रमाणपत्राचे नूतनीकरण आपोआप होत आहे असे सर्वांना वाटत असते.

हे सर्व गृहीतक धरते की तुम्हाला एक मशीन नियंत्रित आहे, ज्याला सार्वजनिक IP आणि जगासाठी खुले port 80 आहे — म्हणजेच एक VPS. वरील प्रक्रिया त्यापैकी कोणत्याही मशीनवर तशीच राहते.

प्रमाणपत्राच्या याच स्टेप्स nginx ऐवजी Apache वर लागू होतात. आणि जेव्हा सार्वजनिक प्रमाणपत्र शक्य नसते, तेव्हा Ubuntu वर स्वतःच्या स्वाक्षरीकृत प्रमाणपत्र आंतरिक सेवांसाठी उपयुक्त ठरते.

FAQ

माझी साइट फक्त HTTPS देत असल्यास मला port 80 उघडे ठेवणे आवश्यक आहे का?

होय, HTTP-01 आव्हानासाठी. Let's Encrypt नेहमी port 80 वर त्याची पडताळणी विनंती सुरू करते, आणि Certbot मध्ये TLS-ALPN-01 अंमलबजावणी नाही, म्हणून फक्त 443 उघडे ठेवणारा फायरवॉल पहिली जारीकरण आणि त्यानंतरचे प्रत्येक स्वयंचलित नूतनीकरण दोन्ही अडवतो. port 80 वरून HTTPS वर पाठवणारे redirect चालते — पडताळणी त्याचे अनुसरण करते. port 80 पूर्णपणे वगळण्याचा एकमेव मार्ग म्हणजे provider plugin सह 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 plugin हवे असल्यासच snap निवडा. कोणत्याही परिस्थितीत, फक्त एक निवडा: दोन इंस्टॉलेशन म्हणजे एकाच /etc/letsencrypt झाडाकडे निर्देश करणारे दोन नूतनीकरण timers, आणि विसरलेले इंस्टॉलेशन हे तुम्हाला त्रास देणारे असते.

Certbot nginx साठी wildcard प्रमाणपत्र जारी करू शकते का?

फक्त DNS-01 द्वारे. *.example.com सारख्या wildcard ला आव्हान फाइल घेण्यासाठी एकही एकल hostname नसतो, म्हणून --nginx, --webroot आणि --standalone हे सर्व बाद होतात. तुमच्या DNS provider साठी plugin इंस्टॉल करा, root-only credentials फाइलमध्ये scoped API token ठेवा, आणि certbot certonly --dns-cloudflare -d example.com -d '*.example.com' चालवा, shell त्याचे globbing थांबवण्यासाठी wildcard ला उद्धृत करा.

यशस्वी नूतनीकरणानंतर nginx अजूनही जुने प्रमाणपत्र का देत आहे?

nginx प्रमाणपत्र मेमरीमध्ये ठेवते आणि ते reload होईपर्यंत डिस्कवरील नवीन फाइल लक्षात घेत नाही. certbot --nginx तुम्हाला reload करते, परंतु --webroot आणि --standalone runs करत नाहीत, म्हणून नूतनीकरण यशस्वी होऊ शकते तरी browser ला अजूनही संपणारे प्रमाणपत्र दिसते. /etc/letsencrypt/renewal-hooks/deploy/ मध्ये एक executable स्क्रिप्ट टाका जी nginx -t && systemctl reload nginx चालवते, आणि ती प्रत्येक यशस्वी नूतनीकरणानंतर सुरू होते.

certbot renew --dry-run हे नूतनीकरण काम करेल हे सिद्ध करते का?

बहुतांश वेळा. हे staging environment विरुद्ध खरे आव्हान चालवते — समान फायरवॉल, समान DNS, समान कोड मार्ग — कोणताही rate-limit खर्च न लावता आणि डिस्कवर काहीही न लिहिता, म्हणून यश म्हणजे नेटवर्क भाग योग्य आहे. तरीही, हे तुमचे deploy hook सुरू होते हे विश्वसनीयरित्या सिद्ध करत नाही. ते वेगळे तपासा: hook स्क्रिप्ट स्वतःहून चालवा आणि sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf तपासा.