द्वारे Matt Connor 2026-07-14 · अपडेटेड 2026-08-29

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 द्वारे सुरक्षा पॅचेस मिळवते आणि यासाठी 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' रन करा. शेलने वाइल्डकार्डचा विस्तार (globbing) करू नये म्हणून ते अवतरण चिन्हात (quotes) लिहा.

Ubuntu 24.04 वर Certbot इंस्टॉल करण्यासाठी apt किंवा snap पद्धतीचा वापर करा. या मार्गदर्शिकेत certbot --nginx कमांड आणि पोर्ट 80 रिन्यूअल टाइमआउटच्या समस्या सोडवण्याची माहिती दिली आहे.

Certbot इंस्टॉल करा: apt किंवा snap

Ubuntu 24.04 वर, sudo apt install certbot python3-certbot-nginx तुम्हाला एक कार्यक्षम Certbot देते, जे अधिकृत आणि सार्वजनिकरित्या विश्वसनीय Let's Encrypt प्रमाणपत्रे जारी करते. Certbot चे अधिकृत डॉक्युमेंटेशन तुम्हाला snap वापरण्याचा सल्ला देते; या दोन्हीमध्ये सूक्ष्म फरक आहे. snap हे अपस्ट्रीम रिलीजचे अनुसरण करते, तर archive पॅकेज हे LTS सोबत आलेल्या आवृत्तीचे अनुसरण करते आणि त्याला फक्त सुरक्षा सुधारणा (security fixes) मिळतात.

कोणताही एक पर्याय निवडा. 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 पॅकेज काढून टाका.

दोन्ही इंस्टॉल पद्धती त्यानंतर सारख्याच प्रकारे काम करतात. 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 मध्ये त्या नावाचा शोध घेते, सापडलेल्या पत्त्यावर port 80 शी कनेक्शन उघडते आणि http://example.com/.well-known/acme-challenge/<token> ची विनंती करते. तुमचा सर्व्हर Certbot ने डिस्कवर लिहिलेल्या नेमक्या टोकन आशयाने उत्तर देतो. हीच संपूर्ण कार्यपद्धती आहे. याचे तीन परिणाम होतात, जे बहुतेक अयशस्वी इश्यूअन्ससाठी कारणीभूत ठरतात.

Port 80 सार्वजनिक इंटरनेटवरून पोहोचण्यायोग्य असणे आवश्यक आहे, केवळ तुमच्या लॅपटॉपवरून नाही. एखादा ufw नियम, क्लाउड-प्रोव्हायडर सिक्युरिटी ग्रुप किंवा केवळ 443 पोर्ट उघडणारा VPS-console फायरवॉल इश्यूअन्स आणि भविष्यातील प्रत्येक रिन्यूअलमध्ये अडथळा आणतो.
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

जेव्हा तुम्हाला Certbot ला तुमच्या nginx कॉन्फिगरेशनपासून दूर ठेवायचे असते, किंवा तुम्ही टेम्पलेटवरून कॉन्फिगरेशन तयार करत असता, ते git मध्ये ठेवता किंवा Ansible द्वारे पुश करता, तेव्हा --webroot हा पर्याय योग्य ठरतो. Certbot फक्त चॅलेंज फाईल तुम्ही आधीच सर्व्ह करत असलेल्या डिरेक्टरीमध्ये लिहिते.

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

जेव्हा पोर्ट 80 वर कोणतीही सेवा कार्यरत नसते, जसे की मेल सर्व्हर, फक्त 443 वर चालणारे API, किंवा nginx इन्स्टॉल होण्यापूर्वी चालणारी पहिली बूट स्क्रिप्ट, तेव्हा --standalone हा पर्याय योग्य आहे. Certbot काही सेकंदांसाठी स्वतः पोर्ट 80 बाइंड करते. जर nginx आधीच सुरू असेल, तर ही प्रक्रिया अपयशी ठरते, त्यामुळे ती चालवण्यापूर्वी nginx थांबवा:

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

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

प्रमाणपत्र अस्तित्वात असण्यापूर्वी आणि नंतर कार्य करणारा सर्व्हर ब्लॉक

कोंबडी आणि अंड्याचा प्रश्न: जर ssl_certificate अशा फाईलकडे निर्देश करत असेल जी अस्तित्वात नाही, तर Nginx सुरू होण्यास नकार देते आणि Nginx बंद असताना Certbot पडताळणी (validation) करू शकत नाही. त्यामुळे, प्रथम पोर्ट 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-ओन्ली झाल्यावरही नूतनीकरण (renewals) सुरू राहते.

वरील दोन्ही ब्लॉक्स डिस्कवरून फाईल्स सर्व्ह करतात; जर Nginx एखाद्या ॲप्लिकेशनसाठी फ्रंट-एंड म्हणून काम करत असेल, तर location / चे रूपांतर proxy_pass ब्लॉक मध्ये होते आणि रिव्हर्स प्रॉक्सी सर्व्हर ब्लॉक, ओळीनुसार त्या ॲपला आवश्यक असलेल्या हेडर्सची माहिती देते, तर ACME लोकेशन आणि 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/ सिमलिनक्स (symlinks) अपडेट केले जातात; archive/ मधील हार्ड पाथ वापरल्यास तुम्ही अशा प्रमाणपत्राशी बांधले जाता जे कालबाह्य (expire) होऊ शकते.

Wildcards म्हणजे DNS-01, आणि DNS-01 म्हणजे एक प्लगइन

Wildcard प्रमाणपत्र (*.example.com) HTTP-01 द्वारे प्रमाणित केले जाऊ शकत नाही, कारण फाईल मिळवण्यासाठी कोणताही एकच hostname नसतो. DNS-01 हाच एकमेव मार्ग आहे: तुम्ही एक _acme-challenge.example.com TXT रेकॉर्ड प्रकाशित करून मालकी सिद्ध करता. हे काम स्वयंचलितपणे करण्यासाठी Certbot ला तुमच्या DNS प्रोव्हायडरच्या API क्रेडेंशियल्सची आवश्यकता असते, आणि त्यासाठीच प्रोव्हायडर प्लगइन्स अस्तित्वात आहेत. पूर्ण wildcard प्रमाणपत्र मार्गदर्शिका मध्ये 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-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 सोडवू शकत नाही: ज्या होस्टवर सार्वजनिक पोर्ट 80 उपलब्ध नाही, अंतर्गत सेवा, फक्त VPS वरील self-hosted 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 वर पूर्ण चॅलेंज चालवते: यात तोच कोड पाथ, तोच फायरवॉल, तोच DNS वापरला जातो, कोणतीही रेट-लिमिट लागत नाही आणि डिस्कवर काहीही लिहिले जात नाही. जर हे आज यशस्वी झाले, तर 60 दिवसांनंतर होणारे unattended renewal देखील यशस्वी होईल, अर्थात जर सर्व्हरच्या मूळ रचनेत कोणताही बदल झाला नाही तर.

ड्राय रन (dry run) तुमच्या reload hook ची खात्री देत नाही, कारण Certbot च्या वेगवेगळ्या व्हर्जनमध्ये याचे वर्तन बदलते. या भागाची चाचणी हाताने करा: थेट हुक स्क्रिप्ट कार्यान्वित करा, 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' वापरून पोर्ट कोण वापरत आहे याची खात्री करा.

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 मध्ये गेली आहे (कोणता block default_server चा मालक आहे ते तपासा), किंवा -w ला दिलेली directory ही nginx द्वारे सर्व्ह केली जाणारी directory नाही. /var/www/example.com/.well-known/acme-challenge/test वर एक फाईल ठेवा आणि ती बाहेरून मिळवण्याचा प्रयत्न करा; जर तिथे 404 एरर आला, तर प्रमाणपत्र ही समस्या नव्हती.

DNS problem: NXDOMAIN looking up A for example.com, नाव सार्वजनिकरीत्या resolve होत नाही. नवीन records जे अजून पसरलेले (propagate) नाहीत, किंवा तुमच्या registrar द्वारे सर्व्ह न केल्या जाणाऱ्या zone मधील record.

too many certificates already issued for: example.com, हे rate limit आहे, जे डीबगिंग करताना वारंवार येते. Let's Encrypt एका आठवड्यात पाच डुप्लिकेट प्रमाणपत्रांची मर्यादा घालते (समान नावे), आणि स्वतंत्रपणे प्रति नोंदणीकृत डोमेन प्रति आठवडा 50 नवीन प्रमाणपत्रांची परवानगी देते; वेळ निघून जाण्याशिवाय यावर कोणताही उपाय नाही. --dry-run वापरून staging वर डीबग करा.

nginx: [emerg] cannot load certificate "/etc/letsencrypt/live/example.com/fullchain.pem": No such file or directory, nginx अशा प्रमाणपत्रासाठी कॉन्फिगर केले आहे जे कधीही जारी केलेले नाही, किंवा certbot delete ने काढून टाकले आहे. TLS server block ला comment करा, nginx सुरू करा, प्रमाणपत्र जारी करा आणि नंतर block पुन्हा सुरू करा.

open() "/etc/letsencrypt/options-ssl-nginx.conf" failed, ती फाईल nginx plugin पॅकेजसोबत येते. python3-certbot-nginx नसलेल्या certonly बॉक्सवर, एकतर plugin जोडा किंवा include ओळ काढून त्याऐवजी तुमची स्वतःची ssl_protocols आणि ssl_ciphers सेटिंग्ज वापरा.

मोठ्या प्रमाणावर व्यवस्थापन

एका प्रमाणपत्रावर 100 पर्यंत नावे असू शकतात आणि एकच certbot --nginx -d a.example.com -d b.example.com ... वापरणे आकर्षक वाटते, परंतु एखादा जुना DNS record validation मध्ये अपयशी ठरला तर त्या प्रमाणपत्रावरील इतर सर्व नावेही बंद पडतात. प्रत्येक साइटसाठी स्वतंत्र प्रमाणपत्रे वापरल्यास ती स्वतंत्रपणे निकामी होतात, जे एकापेक्षा जास्त सेवा होस्ट करणाऱ्या सर्व्हरसाठी योग्य असते. काही साइट्सपेक्षा जास्त संख्या झाल्यावर, ACME-aware front door वापरणे फायदेशीर ठरते: Docker Compose अंतर्गत अनेक अॅप्स चालवणारा Traefik reverse proxy स्वतःहून प्रमाणपत्रे मिळवतो आणि नूतनीकरण करतो, ज्यामुळे Certbot ची गरज पूर्णपणे संपते. कोणता proxy वापरावा हा निर्णय तुमचा आहे, आणि Nginx, Caddy आणि Traefik यांची तुलना करताना, तुम्हाला किती प्रमाणपत्र आणि अॅप-स्तरीय कॉन्फिगरेशनचे काम proxy कडून करून घ्यायचे आहे, यावर मुख्यत्वे अवलंबून असते.

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

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

प्रमाणपत्राच्या याच पायऱ्या nginx ऐवजी Apache वर लागू होतात आणि जेव्हा सार्वजनिक प्रमाणपत्र वापरणे शक्य नसते, तेव्हा Ubuntu वरील self-signed certificate अंतर्गत सेवांसाठी वापरता येते.

FAQ

माझी साइट फक्त HTTPS सर्व्ह करत असेल, तर मला पोर्ट 80 उघडे ठेवण्याची गरज आहे का?

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

Ubuntu 24.04 वर nginx साठी मी apt की snap, कोणता 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' रन करा. शेलने वाइल्डकार्डचा विस्तार (globbing) करू नये म्हणून ते अवतरण चिन्हात (quotes) लिहा.

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

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

`certbot renew --dry-run` नूतनीकरण यशस्वी होईल याची खात्री देते का?

बऱ्याच अंशी. हे स्टेजिंग एन्व्हायरमेंटवर प्रत्यक्ष चॅलेंज रन करते, ज्यामध्ये तोच फायरवॉल, तोच DNS आणि तोच कोड पाथ वापरला जातो. यात कोणतीही रेट-लिमिट मर्यादा नसते आणि डिस्कवर काहीही लिहिले जात नाही, त्यामुळे हे पास होणे म्हणजे नेटवर्कचा भाग योग्य असल्याचे दर्शवते. तथापि, तुमचा डिप्लॉय हुक (deploy hook) कार्यान्वित होईलच याची खात्री हे देत नाही. त्याची स्वतंत्रपणे चाचणी करा: हुक स्क्रिप्ट स्वतः हाताने रन करा आणि sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf तपासा.

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

Certbot इंस्टॉल करा: apt किंवा snap

HTTP-01 प्रत्यक्षात काय करते आणि पोर्ट 80 ऐच्छिक का नाही

ऑथेंटिकेटर निवडणे: --nginx, --webroot, --standalone

प्रमाणपत्र अस्तित्वात असण्यापूर्वी आणि नंतर कार्य करणारा सर्व्हर ब्लॉक

Wildcards म्हणजे DNS-01, आणि DNS-01 म्हणजे एक प्लगइन

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

रिन्यूअलची प्रत्यक्ष चाचणी

तुम्हाला प्रत्यक्ष जाणवणाऱ्या त्रुटी

मोठ्या प्रमाणावर व्यवस्थापन

FAQ

माझी साइट फक्त HTTPS सर्व्ह करत असेल, तर मला पोर्ट 80 उघडे ठेवण्याची गरज आहे का?

Ubuntu 24.04 वर nginx साठी मी apt की snap, कोणता Certbot इन्स्टॉल करावा?

Certbot nginx साठी वाइल्डकार्ड प्रमाणपत्र जारी करू शकतो का?

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

certbot renew --dry-run नूतनीकरण यशस्वी होईल याची खात्री देते का?

`certbot renew --dry-run` नूतनीकरण यशस्वी होईल याची खात्री देते का?