Ubuntu 24.04 वर Apache साठी Certbot कसे बसवावे

तुम्ही काय तयार करणार आहात

Ubuntu 24.04 वर Apache site तयार केली जाईल. ती HTTPS वर उपलब्ध असेल आणि Certbot द्वारे जारी केलेले, ब्राउझरला विश्वसनीय असलेले विनामूल्य Let's Encrypt प्रमाणपत्र वापरेल. हे प्रमाणपत्र तुम्हाला पुन्हा स्वतंत्रपणे लक्षात ठेवावे लागू नये अशा systemd timer द्वारे आपोआप नूतनीकृत केले जाईल. हे काम करणारी command एका ओळीत आहे. या command पूर्वी काहीतरी चुकीचे झाल्यासच बहुतेक अडचणी निर्माण होतात: ServerName नसलेला vhost, provider firewall मध्ये बंद असलेला port 80 किंवा अजूनही जुन्या server कडे निर्देश करणारे DNS. त्यामुळे या मार्गदर्शकात preconditions वर अधिक भर दिला आहे आणि प्रत्येक चुकीमुळे छापला जाणारा अचूक error string दिला आहे.

व्याप्तीबाबत दोन सूचना. तुमचा web server nginx असल्यास flow ची रचना समान राहते; परंतु plugin आणि configuration वेगवेगळे असतात. अशा वेळी या मार्गदर्शकाची nginx आवृत्ती वापरा. तुम्ही सुरक्षित करत असलेली गोष्ट केवळ internal-only असल्यास, उदाहरणार्थ private address वरील admin panel किंवा इतर कोणीही वापरत नसलेला staging box, तर certificate authority ची अजिबात गरज नाही; self-signed certificate मध्ये कमी configuration लागते आणि ते offline देखील कार्य करते.

पूर्वतयारी आणि Certbot सुरू होण्यापूर्वी ही प्रक्रिया अयशस्वी होण्याचे तीन मार्ग

• Apache तुमची साइट आधीपासून साध्या HTTP वर सेवा देत आहे. Certbot चे Apache plugin विद्यमान साइटमध्ये बदल करते; ते नवीन साइट तयार करत नाही. तुम्ही रिकाम्या VPS पासून सुरुवात करत असाल, तर आधी Ubuntu 24.04 वर LAMP stack तयार करा आणि नंतर येथे परत या. या मार्गदर्शकात त्या stack साठी आवश्यक TLS प्रकरण दिले आहे.
• तुमच्या VPS च्या पत्त्याकडे निर्देश करणारा A record असलेले सार्वजनिक domain. Let's Encrypt चे HTTP-01 challenge म्हणजे त्यांचे validation servers इंटरनेटवरून तुमच्या सर्व्हरशी जोडले जातात: port forward नसलेले NAT केलेले homelab चालणार नाही, .local names चालणार नाहीत आणि bare IPs चालणार नाहीत. dig +short example.com ने तुमचा VPS address परत केला पाहिजे. तुम्ही मागील तासात DNS बदलले असल्यास, certificate जारी करण्यापूर्वी जुन्या record चा TTL संपेपर्यंत प्रतीक्षा करा.
• AAAA record अस्तित्वात असल्यास तो अचूक असला पाहिजे. AAAA record प्रकाशित केलेला असल्यास Let's Encrypt IPv6 ला प्राधान्य देते. त्यामुळे तुमच्या laptop वरून, बहुधा IPv4 वापरून, curl व्यवस्थित काम करत असले तरी जुना AAAA record validation अयशस्वी करू शकतो. अचूक AAAA record प्रकाशित करा किंवा तो अजिबात प्रकाशित करू नका.

Port 80 आणि 443 हे ufw मध्ये तसेच तुमच्या provider च्या network firewall मध्ये खुले असणे आवश्यक आहे. बहुतेक hosting panels मध्ये OS ला दिसत नसलेला दुसरा firewall असतो. HTTP-01 validation विशेषतः port 80 वर होते; ही प्रक्रिया फक्त 443 वर चालवता येत नाही.

sudo ufw allow "Apache Full"
sudo ufw status

वरील सर्व तयारी पूर्ण असल्यास संपूर्ण काम पंधरा मिनिटांत होते; त्यापैकी दहा मिनिटे वाचनासाठी लागतात.

Snap किंवा apt Certbot? 24.04 वर apt आता योग्य पर्याय आहे

वितरणाच्या पॅकेजमध्ये दीर्घकाळ बदल न झाल्यामुळे Certbot काही वर्षांपूर्वी snap वितरणाकडे वळले. Ubuntu 20.04 मध्ये Certbot 0.40 आले आणि त्यानंतर ते बदलले नाही. त्यामुळे प्रकल्पाला पाच वर्षे जुन्या बगचे debugging करणे कंटाळवाणे झाले. 24.04 मध्ये हे कारण उरलेले नाही. Archive मध्ये Certbot 2.9.0 ही सध्याच्या पिढीतील release उपलब्ध आहे आणि unattended-upgrades त्याला अद्ययावत ठेवते. या OS साठी माझी शिफारस: apt वापरा. snapd daemon ची गरज राहत नाही, Apache plugin त्याच transaction मध्ये install होते आणि renewal timer systemd सोबत नेहमीच्या Debian पद्धतीने integrate होतो.

sudo apt update
sudo apt install -y certbot python3-certbot-apache
certbot --version

योग्य परिणाम: certbot 2.9.0. python3-certbot-apache हे तुमच्या Apache configurations वाचून त्यात बदल करणारे plugin आहे. ते नसल्यास certbot --apache The requested apache plugin does not appear to be installed सह अपयशी ठरते.

दोन परिस्थितींमध्ये snap अजूनही योग्य पर्याय आहे: Certbot ची नवीनतम release उपलब्ध होताच त्याच दिवशी हवी असल्यास, किंवा फक्त snap स्वरूपात वितरित होणारा DNS plugin आवश्यक असल्यास. certbot-dns-* पैकी अनेक provider plugins अशा प्रकारे वितरित होतात. तो पर्याय निवडल्यास:

sudo apt remove -y certbot python3-certbot-apache
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

तुम्ही कोणताही पर्याय निवडा, दोन्ही कधीही चालवू नका. दोन installations मुळे /etc/letsencrypt वर दोन renewal schedulers परस्परांशी संघर्ष करतात आणि तुमच्या shell ला PATH मध्ये सापडणारा certbot तुमची certificates व्यवस्थापित करणारा Certbot असेलच असे नाही. वरील apt remove line ही केवळ सजावटीसाठी नाही.

Certbot ने संपादित करावयाचे vhost आधीपासून अस्तित्वात असणे आवश्यक आहे; ServerName हाच मुख्य मुद्दा आहे

certbot --apache प्रत्येक दिलेल्या -d domain शी जुळणारा ServerName किंवा ServerAlias असलेला port-80 virtual host शोधून कार्य करते. त्याद्वारे domain वरील नियंत्रण सिद्ध केले जाते आणि नंतर त्या vhost ची SSL प्रत तयार केली जाते. जुळणारा ServerName नसेल, तर जुळणी होत नाही. Ubuntu सोबत येणाऱ्या default 000-default.conf मध्ये ServerName टिप्पणीच्या स्वरूपात असते. या एकाच टिप्पणी केलेल्या ओळीमुळे या मार्गदर्शकातील एक मोठी command अयशस्वी होण्याची शक्यता सर्वाधिक असते.

म्हणून Certbot वापरण्यापूर्वी site साठी योग्य name-based vhost द्या. /etc/apache2/sites-available/example.com.conf तयार करा:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com
    ErrorLog ${APACHE_LOG_DIR}/example.com-error.log
    CustomLog ${APACHE_LOG_DIR}/example.com-access.log combined
</VirtualHost>

ते enable करा आणि Apache त्याचे parsing करून नाव त्याच्याकडे पाठवतो आहे का ते पडताळा:

sudo a2ensite example.com.conf
sudo apache2ctl configtest
sudo systemctl reload apache2
sudo apache2ctl -S

configtest ने Syntax OK दाखवले पाहिजे. त्यासोबत AH00558: apache2: Could not reliably determine the server's fully qualified domain name देखील दिसत असेल, तर तो तुमच्या vhost विषयी नसून global ServerName विषयीचा इशारा आहे. या प्रकरणात तो निरुपद्रवी आहे आणि echo "ServerName $(hostname -f)" | sudo tee /etc/apache2/conf-available/servername.conf && sudo a2enconf servername && sudo systemctl reload apache2 मुळे तो दिसणार नाही.

-S चे output ही महत्त्वाची पडताळणी आहे. alias www.example.com अंतर्गत port 80 namevhost example.com (/etc/apache2/sites-enabled/example.com.conf:1) सारखी ओळ अपेक्षित आहे. Apache ने प्रत्यक्षात वाचलेली sites-enabled symlink दाखवली जाते; तुम्ही sites-available मध्ये संपादित केलेली file दाखवली जात नाही. port 80 साठी example.com सूचीबद्ध नसेल, तर Certbot देखील ते शोधू शकणार नाही.

प्रमाणपत्र जारी करा: certbot --apache

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

पहिल्यांदा चालवल्यावर तीन गोष्टी विचारल्या जातात: ईमेल पत्ता (हा तुमच्या ACME account साठी आणि CA कडून येणाऱ्या तातडीच्या सूचनांसाठी वापरला जातो; Let's Encrypt आता प्रमाणपत्र कालबाह्य होण्याच्या सूचना पाठवत नाही, त्यामुळे renewal चे monitoring तुमची जबाबदारी आहे), Let's Encrypt च्या अटी मान्य करण्याची संमती, आणि तुमचा ईमेल EFF सोबत share करायचा आहे का हा प्रश्न. आता redirect संबंधी प्रश्न विचारला जात नाही: Certbot 2.0 पासून Apache installer HTTP ला HTTPS कडे default ने redirect करतो, आणि येथे तुम्हाला तेच हवे आहे. Plain HTTP वर content सुरू ठेवणे खरोखर आवश्यक असल्यास --no-redirect द्या.

यशस्वी output असा दिसतो. तो वरवर वाचू नका; काळजीपूर्वक वाचा:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/example.com/privkey.pem
This certificate expires on 2026-10-14.

Deploying certificate
Successfully deployed certificate for example.com to /etc/apache2/sites-available/example.com-le-ssl.conf
Successfully deployed certificate for www.example.com to /etc/apache2/sites-available/example.com-le-ssl.conf
Congratulations! You have successfully enabled HTTPS on https://example.com and https://www.example.com

या message मागे Certbot ने चार गोष्टी केल्या: Apache चे ssl module आधी enabled नसल्यास ते enabled केले, example.com-le-ssl.conf लिहिले — म्हणजे *:443 वर तुमच्या vhost ची प्रत, ज्यामध्ये SSLEngine on आणि प्रमाणपत्राचे paths आहेत — ते enabled केले, आणि मूळ port-80 vhost मध्ये RewriteRule block जोडला, जो प्रत्येक विनंतीला HTTPS कडे 301 redirect करतो. तुमची मूळ vhost file replace केलेली नाही; तिच्यात edit केले आहे. SSL ची प्रत तिच्या शेजारी ठेवली आहे, त्यामुळे Certbot ने जोडलेली प्रत्येक line तुम्ही वाचू शकता.

प्रमाणपत्र प्रत्यक्षात कुठे असते आणि ते कधीही कॉपी का करू नये

सर्व फाइल्स /etc/letsencrypt/live/example.com/ अंतर्गत तयार होतात: fullchain.pem (प्रमाणपत्र आणि intermediate chain; सर्व्हरने याच्याकडे निर्देश करावा), privkey.pem (private key; केवळ root कडून वाचता येते), तसेच स्वतंत्र घटक आवश्यक असलेल्या software साठी cert.pem आणि chain.pem. हे /etc/letsencrypt/archive/ मधील फाइल्सकडे निर्देश करणारे symlinks आहेत. हीच रचना renewal यंत्रणा आहे: renewal नवीन फाइल्स archive/ मध्ये लिहिते आणि symlinks नव्या फाइल्सकडे वळवते. इतर कोणत्याही software ला live/ paths कडे निर्देशित करा; त्याला renewals आपोआप मिळतील. फाइल्स दुसरीकडे कॉपी केल्यास 90 दिवसांनंतर सेवा बंद पडण्याची समस्या तुम्ही स्वतः निर्माण करता.

माहिती असणे उपयुक्त ठरणारी दुसरी फाइल म्हणजे /etc/letsencrypt/renewal/example.com.conf. या फाइलमध्ये हे प्रमाणपत्र कशा प्रकारे जारी झाले, authenticator = apache, installer = apache आणि domains यांची नोंद असते. त्यामुळे renewal unattended पद्धतीने ही प्रक्रिया पुन्हा करू शकते आणि त्यानंतर Apache reload देखील करू शकते.

नूतनीकरण आधीच नियोजित आहे; ते पडताळा, नव्याने तयार करू नका

Let's Encrypt प्रमाणपत्रांची वैधता नियोजितप्रमाणे 90 दिवसांची असते आणि apt पॅकेजने आवश्यक यंत्रणा आधीच स्थापित केलेली असते: systemd timer, जो दिवसातून दोनदा यादृच्छिक वेळी चालतो आणि मुदत संपण्यास 30 दिवस किंवा त्यापेक्षा कमी कालावधी उरलेल्या कोणत्याही प्रमाणपत्राचे नूतनीकरण करतो. त्यावर cron job जोडू नका; दुसरा scheduler log मध्ये अनावश्यक नोंदी आणि rate-limit लागू होण्याचा धोका याशिवाय काहीही वाढवत नाही.

systemctl list-timers certbot.timer
sudo certbot renew --dry-run

पहिली command timer सक्रिय आहे हे दाखवते. पुढील 24 तासांतील एखादा NEXT वेळ दिसेल. Schedule दिवसातून दोनदा असते आणि त्यात randomized delay असतो. त्यामुळे अचूक वेळ जाणीवपूर्वक अनिश्चित असते. snap install मध्ये timer त्याऐवजी snap.certbot.renew.timer असतो. Dry run Let's Encrypt च्या staging environment विरुद्ध संपूर्ण renewal rehearsal करते. यात वास्तविक challenge चालते, मात्र प्रमाणपत्र जारी केले जात नाही आणि rate-limit खर्च होत नाही. योग्य परिणामाचा शेवट पुढीलप्रमाणे होतो:

Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/example.com/fullchain.pem (success)

Dry run अयशस्वी झाल्यास, सुमारे 60 दिवसांनंतर होणारे वास्तविक नूतनीकरण त्याच कारणामुळे अयशस्वी होईल. सध्याच्या प्रमाणपत्राची संपूर्ण वैधता शिल्लक असतानाच ही समस्या दुरुस्त करा. प्रमाणपत्र जारी झाल्यानंतर firewall rule जोडून port 80 पुन्हा बंद करणे हे यामागील नेहमीचे कारण असते.

curl ने पडताळणी आणि padlock मध्ये दिसणारी माहिती

curl -sI http://example.com | head -n 3
curl -I https://example.com
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -issuer -dates

पहिल्या कमांडने HTTP/1.1 301 Moved Permanently परत केले पाहिजे आणि त्यात Location: https://example.com/ header असला पाहिजे. हा Certbot ने स्थापित केलेला redirect आहे. दुसऱ्या कमांडने HTTP/1.1 200 OK परत केले पाहिजे आणि curl कडून TLS संबंधी कोणतीही तक्रार नसली पाहिजे. तिसरी कमांड issuer, R12 किंवा E7 सारख्या लहान CN असलेली O = Let's Encrypt ओळ आणि साधारण 90 दिवसांनी समाप्त होणारी notAfter माहिती दाखवते. ब्राउझरमध्ये padlock दिसेल आणि त्यावर क्लिक केल्यास तोच issuer दिसतो. curl यशस्वी होत असेल आणि ब्राउझर इशारा देत असेल, तर तुम्ही जवळजवळ निश्चितपणे cached page किंवा चुकीचा hostname पाहत आहात; ही प्रमाणपत्राची समस्या नाही.

अनेक sites: एक SAN certificate किंवा प्रत्येक site साठी स्वतंत्र certificate

दोन्ही पद्धती कार्य करतात आणि दोन्हींचे renewal एकाच प्रकारे होते. एकाच server वर असलेल्या परस्पर असंबंधित sites साठी issue command प्रत्येक site साठी एकदा चालवा. प्रत्येक site ला live/ अंतर्गत स्वतंत्र directory आणि स्वतःचे renewal config मिळते. त्यामुळे एका domain मधील समस्या इतर domains चे renewal कधीही अडवत नाही. ही माझी default पद्धत आहे.

एका site साठी अनेक names असल्यास ते एकाच SAN certificate मध्ये ठेवा. एका certificate मध्ये 100 पर्यंत names ठेवता येतात. तुम्ही हे वर example.com आणि www.example.com वापरून आधीच केले आहे. नंतर विद्यमान certificate मध्ये एखादे name जोडायचे असल्यास, certificate चे नाव आणि नवीन names ची संपूर्ण यादी देऊन पुन्हा issue करा:

sudo certbot --apache --cert-name example.com -d example.com -d www.example.com -d blog.example.com

Certbot ला domain set बदलल्याचे आढळते. तो expansion साठी तुमची पुष्टी मागतो आणि certificate त्याच ठिकाणी बदलतो. live/ path तोच राहतो, त्यामुळे इतर कोणत्याही गोष्टीत बदल करण्याची गरज नसते. लक्षात ठेवा, ही यादी append केली जात नाही; ती replacement असते. त्या command मधून www वगळल्यास नवीन certificate मधून ते name शांतपणे काढले जाते.

Wildcard प्रमाणपत्रांसाठी DNS-01 आवश्यक असते; आणि सहसा wildcard ची गरज नसते

HTTP-01 वापरून *.example.com जारी करता येत नाही. Web server वर फाइल ठेवणे एका hostname वरील नियंत्रण सिद्ध करते; संपूर्ण namespace वरील नाही. Wildcard साठी DNS-01 challenge आवश्यक असते. Certbot _acme-challenge.example.com येथे TXT record सेट करते. प्रत्यक्षात यासाठी तुमच्या DNS provider साठी API credentials असलेले certbot-dns-* plugin आवश्यक असते. अन्यथा प्रत्येक renewal वेळी --manual वापरून TXT records हाताने संपादित करावे लागतात. ही पद्धत त्रासदायक आहे; तिच्यावर आधारित नियोजन करू नका. TXT record ची कार्यपद्धती आणि unattended renewal करणाऱ्या plugin पर्यंतचे संपूर्ण मार्गदर्शन DNS-01 द्वारे Certbot वापरून wildcard प्रमाणपत्रे येथे दिले आहे. स्पष्ट सल्ला असा आहे: तुमच्याकडे चार ज्ञात subdomains असल्यास, त्या चारही नोंदविणारे SAN certificate wildcard पेक्षा सोपे असते आणि server वर DNS API keys ठेवण्याची गरज नसते.

अपयशाच्या स्थिती आणि दिसणारे संदेश

Apache चे configuration चुकीचे असल्यामुळे Certbot सुरू होण्यास नकार देतो.

The apache plugin is not working; there may be problems with your existing configuration.
The error was: MisconfigurationError('Error while running apache2ctl configtest.\n\nAction \'configtest\' failed.\nThe Apache error log may have more information.\n\nAH00526: Syntax error on line 12 of /etc/apache2/sites-enabled/example.com.conf')

काहीही करण्यापूर्वी plugin configtest चालवतो. Apache मध्येच समस्या असल्यास तो पुढे न जाता थांबतो. \n मधील s अक्षरे जशीच्या तशी आहेत, कारण Certbot exception चे repr छापतो. sudo apache2ctl configtest स्वतः चालवा. त्यात file आणि line नमूद असतात. हाताने configuration संपादित करताना झालेली typo, अस्तित्वात नसलेल्या path कडे निर्देश करणारा SSLCertificateFile किंवा enabled नसलेल्या module चा संदर्भ ही याची सामान्य कारणे आहेत. त्यात Syntax OK दिसेपर्यंत दुरुस्ती करा. त्यानंतर Certbot पुन्हा चालवा.

कोणताही vhost domain शी जुळत नाही.

Unable to find a virtual host listening on port 80 which is currently the only challenge port.

ही आधी नमूद केलेली missing-ServerName समस्या आहे. Issue करताना ती आढळते. Certbot ने port-80 वरील सर्व enabled vhost मध्ये तुमच्या -d शी जुळणारा ServerName/ServerAlias शोधला; परंतु तो सापडला नाही. Apache प्रत्यक्षात कोणत्या मार्गाने विनंत्या पाठवतो ते sudo apache2ctl -S दाखवते. योग्य vhost मध्ये ServerName line जोडा, reload करा आणि पुन्हा प्रयत्न करा. याच्याशी संबंधित दुसरी समस्या म्हणजे validation चुकीच्या vhost पर्यंत पोहोचणे. दुसऱ्या site ने request स्वीकारल्यामुळे challenge response Invalid response ... 404 परत येतो. निदान तेच आणि tool तेच: apache2ctl -S.

Validation ला timeout येतो.

Certbot failed to authenticate some domains (authenticator: apache).
...
Detail: ...: Timeout during connect (likely firewall problem)

तुमच्या DNS मध्ये जाहीर केलेल्या address वर port 80 साठी Let's Encrypt ला TCP connection उघडता आला नाही. संभाव्य कारणांचा क्रम असा आहे: provider चा network firewall (तो ufw पेक्षा स्वतंत्र असतो आणि hosting panel मध्ये configured केलेला असतो), फक्त 443 किंवा फक्त SSH ला परवानगी देणारा ufw ruleset, DNS अजूनही जुन्या server कडे निर्देश करत असणे किंवा stale-AAAA समस्या. शेवटच्या स्थितीत त्यांच्या servers ने IPv6 वापरून प्रयत्न केला, परंतु तुमचा server फक्त IPv4 वर उत्तर देतो. VPS च्या बाहेरून चाचणी करा: तुमच्या laptop वरून curl -I http://example.com चालवल्यास validator ला जे दिसते त्याची पुनरावृत्ती होते.

पुन्हा पुन्हा प्रयत्न केल्यामुळे rate limit लागू होते.

Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/

Let's Encrypt प्रत्येक hostname आणि account साठी दर तासाला 5 अयशस्वी validations ला परवानगी देते. 2025 मधील rate-limit पुनर्रचनेनंतर ही refilling bucket आहे. त्यातून साधारणपणे दर 12 मिनिटांनी 1 retry पुन्हा उपलब्ध होतो. Firewall मध्ये समस्या असताना वारंवार retry केल्यास ही मर्यादा पटकन संपते. प्रतीक्षा केल्याने समस्या सुटते; परंतु योग्य उपाय म्हणजे पद्धत बदलणे: कोणतेही अपयश आल्यावर staging environment वापरून debugging करा आणि ते यशस्वी होईपर्यंत प्रयत्न करा.

sudo certbot certonly --apache --dry-run -d example.com -d www.example.com

certonly लक्षात ठेवा: --dry-run फक्त certonly आणि renew subcommands सोबत स्वीकारले जाते. स्वतंत्र certbot --apache --dry-run form चालतच नाही आणि --dry-run currently only works with the 'certonly' or 'renew' subcommands असा संदेश देते. Dry run staging विरुद्ध validation करते. Staging ला स्वतःच्या मोठ्या limits असतात आणि ते वास्तविक certificates जारी करत नाही. त्यामुळे तिथे दिवसभर अपयशी प्रयत्न करता येतात. Staging यशस्वी झाल्यावरच वास्तविक command पुन्हा चालवा. इतर limits म्हणजे registered domain मागे दर आठवड्याला 50 certificates आणि त्याच name set च्या दर आठवड्याला 5 duplicates. एखादी script loop मध्ये पुन्हा पुन्हा certificate जारी करत असेल तरच तुम्ही या limits पर्यंत पोहोचाल.

HTTPS सुरू झाल्यानंतर लक्षात ठेवा की certificate transport सुरक्षित करते, server नाही. Port 22 वर दिवसभर password guesses सुरूच राहू शकतात. यासोबत Ubuntu 24.04 वर Fail2ban वापरणे हा पुढील 30 मिनिटांसाठी योग्य उपाय आहे.

FAQ

Ubuntu 24.04 वर Apache साठी Certbot snap ने स्थापित करावे की apt ने?

apt वापरा. Ubuntu 24.04 मध्ये Certbot 2.9.0 उपलब्ध आहे. या मार्गदर्शकातील सर्व कामांसाठी ही आवृत्ती पुरेशी नवीन आहे. तिला unattended-upgrades द्वारे security patches मिळतात आणि snapd आवश्यक नसते. नवीनतम release त्वरित हवी असल्यास किंवा फक्त snap म्हणून वितरित केलेला DNS plugin आवश्यक असल्यासच snap निवडा. पद्धत बदलल्यास, दोन renewal schedulers एकाच वेळी चालू राहू नयेत म्हणून प्रथम apt remove certbot python3-certbot-apache करा.

Certbot मध्ये "Unable to find a virtual host listening on port 80" असे का दिसते?

कारण port 80 वर ऐकणाऱ्या कोणत्याही enabled vhost मध्ये ServerName किंवा ServerAlias नसते, किंवा -d सोबत दिलेल्या domain शी ते जुळत नाही. Ubuntu च्या default vhost मध्ये ServerName टिप्पणी केलेले असते. sudo apache2ctl -S चालवा. दिलेल्या नावासाठी जबाबदार असलेले vhost शोधा किंवा तयार करा. त्यात ServerName example.com जोडा, Apache reload करा आणि Certbot पुन्हा चालवा.

"Timeout during connect (likely firewall problem)" ही समस्या कशी दुरुस्त करावी?

Let's Encrypt ला तुमच्या DNS मध्ये प्रकाशित केलेल्या पत्त्यावर port 80 पर्यंत पोहोचता आले नाही. ufw सोबत तुमच्या provider च्या panel-level network firewall चीही तपासणी करा. dig +short example.com या VPS कडे निर्देश करते का ते पडताळा. जुना AAAA record असल्यास तो काढा किंवा दुरुस्त करा. IPv6 उपलब्ध असल्यास validation त्याला प्राधान्य देते. सर्व्हरच्या बाहेरून curl -I http://example.com वापरून दुरुस्तीची खात्री करा. त्यानंतर प्रत्यक्ष issuance करण्यापूर्वी sudo certbot certonly --apache --dry-run -d example.com वापरून rehearsal करा.

Ubuntu 24.04 वर Certbot certificates आपोआप renew करते का?

होय. apt package certbot.timer स्थापित करते. हा systemd timer दिवसातून दोनदा चालतो आणि expiry ला 30 दिवस किंवा त्यापेक्षा कमी कालावधी उरलेले कोणतेही certificate renew करतो. त्यानंतर Apache reload करतो. snap त्याच कामासाठी snap.certbot.renew.timer वापरते. systemctl list-timers certbot.timer वापरून पडताळणी करा आणि sudo certbot renew --dry-run वापरून rehearsal करा. त्यासोबत स्वतःचा cron job जोडू नका.

Certbot आणि Apache वापरून wildcard certificate कसे मिळवावे?

Wildcard certificates साठी DNS-01 challenge आवश्यक असते. Certbot ने _acme-challenge.example.com येथे TXT record ठेवणे आवश्यक असते. यासाठी तुमच्या DNS provider साठी API credentials असलेला certbot-dns-* plugin लागतो. --manual हा पर्याय वापरल्यास प्रत्येक renewal वेळी TXT records हाताने संपादित करावे लागतात. तुमच्याकडे मोजकेच ज्ञात subdomains असल्यास, ती नावे स्पष्टपणे नमूद करणारे SAN certificate अधिक सोपे असते आणि DNS API keys सर्व्हरवर ठेवण्याची गरज राहत नाही.