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

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

Ubuntu 24.04 वर एक Apache साइट जी HTTPS वर प्रतिसाद देते, ती विनामूल्य, ब्राउझर-विश्वसनीय Let's Encrypt प्रमाणपत्रासह — जे Certbot द्वारे जारी केले जाते आणि systemd timer द्वारे आपोआप नूतनीकरण केले जाते, ज्याबद्दल तुम्हाला पुन्हा विचार करावा लागणार नाही. हे काम करणारी कमांड एकच ओळ आहे. सर्व चुका त्या ओळीपूर्वीच होतात: ServerName नसलेला vhost, प्रदात्याच्या फायरवॉलवर बंद असलेले port 80, जुन्या सर्व्हरकडे निर्देश करणारे DNS. म्हणूनच हे मार्गदर्शक बहुतांश वेळ पूर्वअटींवर खर्च करते आणि प्रत्येक चुकीमुळे छापले जाणारे नेमके error string सांगते.

दोन मर्यादा स्पष्टीकरण. जर तुमचा वेब सर्व्हर nginx असेल, तर प्रक्रिया समान आहे पण प्लगइन आणि कॉन्फिग वेगळ्या आहेत — त्याऐवजी या मार्गदर्शकाची nginx आवृत्ती वापरा. आणि जर तुम्ही सुरक्षित करत असलेली गोष्ट फक्त अंतर्गत असेल — खाजगी पत्त्यावरील admin पॅनल, ज्याला दुसरा कोणी भेट देत नाही असा staging बॉक्स — तर तुम्हाला certificate authority ची आवश्यकताच नाही; self-signed प्रमाणपत्र कमी यंत्रणा वापरते आणि ऑफलाइन काम करते.

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

• Apache आधीच तुमची साइट साध्या HTTP वर चालवत आहे. Certbot चे Apache प्लगइन विद्यमान साइट संपादित करते; ते नवीन साइट तयार करत नाही. जर तुम्ही एका साध्या VPS पासून सुरुवात करत असाल, तर आधी Ubuntu 24.04 वर LAMP स्टॅक तयार करा आणि परत या — हे मार्गदर्शक हा त्याचा गहाळ झालेला TLS प्रकरण आहे.
• तुमच्या VPS पत्त्यावर A record सह एक सार्वजनिक डोमेन. Let's Encrypt चा HTTP-01 आव्हान म्हणजे त्यांचे पडताळणी सर्व्हर इंटरनेटवरून तुमच्या मशीनशी जोडले जातात: port forward नसलेला NATed homelab चालणार नाही, .local नावे चालणार नाही, साधे IP चालणार नाही. dig +short example.com तुमचा VPS पत्ता परत करणे आवश्यक आहे, आणि जर तुम्ही गेल्या तासात DNS बदलले असेल, तर सर्टिफिकेट जारी करण्यापूर्वी जुन्या record चा TTL पूर्ण होण्याची वाट पाहा.
• जर AAAA record अस्तित्वात असेल, तर ते योग्य असणे आवश्यक आहे. AAAA record प्रकाशित झाल्यास Let's Encrypt IPv6 ला प्राधान्य देते, म्हणून जुना AAAA पडताळणी अपयशी ठरवतो, जरी तुमच्या लॅपटॉपवरून — कदाचित IPv4 वरून — curl योग्यरित्या काम करत असेल. एकतर योग्य AAAA प्रकाशित करा किंवा काहीच नको.

ufw मध्ये आणि तुमच्या प्रदात्याच्या नेटवर्क फायरवॉलमध्ये पोर्ट 80 आणि 443 खुले असणे आवश्यक आहे — बहुतेक होस्टिंग पॅनेंमध्ये दुसरा फायरवॉल असतो जो OS कधीच पाहत नाही. HTTP-01 विशेषतः पोर्ट 80 वर पडताळणी करते; तुम्ही हे फक्त 443 वर चालू शकत नाही.

sudo ufw allow "Apache Full"
sudo ufw status

हे सर्व व्यवस्थित असल्यास संपूर्ण काम पंधरा मिनिटांचे आहे, आणि त्यातील दहा मिनिटे वाचनाची आहेत.

Snap की apt Certbot? 24.04 वर, apt शेवटी वापरण्यास योग्य आहे

Certbot ने वर्षांूपूर्वी snap वितरणाकडे स्थलांतर केले, त्यामागे एक योग्य कारण होते: distro पॅकेजेस जुनी झाली होती. Ubuntu 20.04 मध्ये Certbot 0.40 आले आणि त्यानंतर कधीच पुढे गेले नाही, आणि प्रकल्पाला पाच वर्षांच्या जुन्या बग्स डिबग करण्याची खूप त्रास झाला. 24.04 वर हे कारण आता नाही — आर्काइव्हमध्ये Certbot 2.9.0 आहे, जे एक अद्ययावत पिढीचे रिलीझ आहे, आणि unattended-upgrades त्यात नियमित पॅचेस देत राहते. या OS साठी माझी शिफारस: apt वापरा. तुम्ही snapd डेमन टाळता, Apache प्लगइन त्याच ट्रान्झॅक्शनमध्ये इंस्टॉल होते, आणि रिन्युअल टायमर systemd मध्ये सामान्य Debian पद्धतीने एकत्रित होतो.

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

योग्य परिणाम: certbot 2.9.0. python3-certbot-apache पॅकेज हे तुमच्या Apache कॉन्फिग्स वाचणारे आणि संपादित करणारे प्लगइन आहे — ते नसल्यास, certbot --apache हे The requested apache plugin does not appear to be installed सह अपयशी होते.

Snap अजूनही दोन प्रकरणांमध्ये योग्य पर्याय आहे: तुम्हाला Certbot ची नवीनतम आवृत्ती ती रिलीझ होताच हवी असेल, किंवा तुम्हाला एक DNS प्लगइन हवे असेल जे फक्त snap म्हणूनच वितरीत केले जाते (certbot-dns-* प्रदाता प्लगइन्सपैकी अनेक असे आहेत). तुम्ही तसे करणार असाल, तर:

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

तुम्ही कोणताही पर्याय निवडला, तरी दोन्ही कधीच चालवू नका. दोन इंस्टॉलेशन्स म्हणजे /etc/letsencrypt वर नियंत्रण मिळवण्यासाठी लढणारे दोन रिन्युअल शेड्युलर्स, आणि तुमच्या शेलला PATH मध्ये सापडणारे certbot हे तुमच्या प्रमाणपत्रांचे मालक असलेले नसेल. वरील apt remove ओळ ही नक्कीच पर्यायी सजावट नाही.

Certbot संपादित करणारा vhost आधीच अस्तित्वात असला पाहिजे — ServerName हाच मुख्य मुद्दा आहे

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

म्हणून Certbot ला हात लावण्यापूर्वी, साइटला योग्य नाव-आधारित 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>

ते सक्षम करा आणि Apache ते योग्यरित्या वाचतो आणि त्या नावाला त्याच दिशेने नेतो ह्याची खात्री करा:

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 देखील छापले, तर ते ग्लोबल ServerName बद्दलचा इशारा आहे, तुमच्या vhost बद्दल नाही — इथे ते हानिकारक नाही, आणि echo "ServerName $(hostname -f)" | sudo tee /etc/apache2/conf-available/servername.conf && sudo a2enconf servername && sudo systemctl reload apache2 द्वारे ते मूक केले जाते.

-S आउटपुट ही तपासणी महत्त्वाची आहे. तुम्हाला port 80 namevhost example.com (/etc/apache2/sites-enabled/example.com.conf:1) सारखी एक ओळ हवी आहे आणि त्याखाली alias www.example.com हवे — Apache ते sites-available मध्ये तुम्ही जे फाइल संपादित केली ती न दाखवता, ते वास्तविक वाचलेले sites-enabled सिमलिंक दाखवते. जर example.com पोर्ट 80 विरुद्ध सूचीबद्ध नसेल, तर Certbot लाही ते सापडणार नाही.

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

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

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

यशाचे स्वरूप असे असते, आणि तुम्ही ते फक्त वाचून काढण्याऐवजी काळजीपूर्वक वाचले पाहिजे:

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

त्या संदेशाच्या मागे Certbot ने चार गोष्टी केल्या: आधीच सक्रिय नसल्यास Apache चे ssl मॉड्यूल सक्रिय केले, example.com-le-ssl.conf लिहिले — तुमच्या *:443 वरील vhost ची एक प्रत, ज्यामध्ये SSLEngine on आणि प्रमाणपत्राचे मार्ग आहेत — ते सक्रिय केले, आणि मूळ port-80 vhost मध्ये एक RewriteRule ब्लॉक जोडले जे सर्वांना HTTPS वर 301 रीडायरेक्ट करते. तुमची मूळ vhost फाइल संपादित केली जाते, बदलली जात नाही, आणि तिच्या शेजारी SSL ट्विन ठेवली जाते जिथे तुम्ही त्याने जोडलेल्या प्रत्येक ओळी वाचू शकता.

प्रमाणपत्र खरंच कुठे साठवले जाते, आणि ते तुम्ही कधीच का कॉपी करू नये

सर्व काही /etc/letsencrypt/live/example.com/ अंतर्गत साठवले जाते: fullchain.pem (प्रमाणपत्र आणि मध्यस्थ साखळी — ज्याकडे सर्व्हर निर्देश करणे आवश्यक आहे), privkey.pem (खाजगी की, फक्त root-वाचनीय), तसेच वेगळे भाग हवे असलेल्या सॉफ्टवेअरसाठी cert.pem आणि chain.pem. हे सर्व /etc/letsencrypt/archive/ मधील symlinks आहेत. ही अप्रत्यक्ष दुव्यांची पद्धतच नूतनीकरणाचा यंत्रणा आहे: नूतनीकरणावेळी नवीन फायली archive/ मध्ये लिहिल्या जातात आणि symlinks पुन्हा निर्देशित केले जातात. इतर कोणत्याही सॉफ्टवेअरला live/ मार्गांवर निर्देश करा, आणि ते आपोआप नूतनीकरणे मिळवेल. फायली दुसरीकडे कॉपी केल्यास, 90 दिवसांनी तुम्ही स्वतःच सेवाअवरोध निर्माण कराल.

/etc/letsencrypt/renewal/example.com.conf ही ओळखण्यासारखी आणखी एक फाईल आहे. ती या प्रमाणपत्राचे वाटप कसे केले गेले हे नोंदवते — authenticator = apache, installer = apache, डोमेन्स — जेणेकरून नूतनीकरणावेळी Apache ला नंतर पुन्हा लोड करताना ही प्रक्रिया बिनदिक्कत पुन्हा करता येईल.

नूतनीकरण आधीच नियोजित आहे — त्याची तपासणी करा, ते तयार करू नका

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

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

पहिली कमांड timer सक्रिय दर्शवते, येत्या 24 तासांत कुठेतरी NEXT वेळ सह येते — हे शेड्यूल दिवसातून दोन वेळा यादृच्छिक विलंबासह असते, म्हणून ती नेमकी वेळ जाणून-घेण्याच्या उद्देशाने अनिश्चित ठेवली आहे (snap स्थापनेवर, timer ऐवजी snap.certbot.renew.timer असते). dry run Let's Encrypt च्या staging environment विरुद्ध संपूर्ण नूतनीकरणाची आखतात करतो — वास्तविक आव्हान, कोणतेही जारी केलेले प्रमाणपत्र नाही, कोणताही rate-limit खर्च नाही. योग्य निकाल याने संपतो:

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

dry run अपयशी ठरल्यास, ~60 दिवसांतील वास्तविक नूतनीकरण त्याच प्रकारे अपयशी होईल — ते आता ठीक करा, जेव्हा सध्याच्या प्रमाणपत्राची संपूर्ण मुदत अजून शिल्लक आहे. सामान्य दोषी असा आहे की जारी केल्यानंतर जोडलेला एक firewall नियम ज्याने पोर्ट 80 पुन्हा बंद केला.

curl सह तपासा, आणि पॅडलॉक काय दर्शविले पाहिजे

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/ हेडरसह परत करेल — हे Certbot ने स्थापित केलेले redirect आहे. दुसरी कमांड HTTP/1.1 200 OK हे curl कडून कोणतीही TLS तक्रार न घेता परत करेल. तिसरी कमांड issuer छापते — R12 किंवा E7 सारखा लहान CN असलेली O = Let's Encrypt ओळ — आणि notAfter सुमारे 90 दिवसांच्या आसपास असेल. ब्राउझरमध्ये तुम्हाला पॅडलॉक दिसेल, आणि त्यावर क्लिक केल्यावर तोच issuer दिसेल. curl कार्य करत असेल आणि ब्राउझर तरीही इशारा देत असेल, तर तुम्ही नक्कीच cached page किंवा चुकीचे hostname पाहत आहात, ही certificate समस्या नाही.

एकाधिक साइट्स: एक SAN प्रमाणपत्र किंवा प्रति साइट एक प्रमाणपत्र

दोन्ही पद्धती काम करतात. दोन्हींचे नूतनीकरण सारख्याच प्रकारे होते. एकाच सर्व्हरवरील एकमेकांशी संबंध नसलेल्या साइट्ससाठी, प्रति साइट एकदा इश्यू कमांड चालवा — प्रत्येक साइटला live/ अंतर्गत स्वतःची डिरेक्टरी आणि स्वतःचे नूतनीकरण कॉन्फिगरेशन मिळते, आणि एका डोमेनमधील समस्या इतरांचे नूतनीकरण कधीच अडवत नाही. हा माझा डिफॉल्ट पर्याय आहे.

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

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

Certbot बदललेला डोमेन संच ओळखते, विस्ताराची खात्री करण्यास विचारते, आणि प्रमाणपत्र त्याच जागी बदलते — तोच live/ मार्ग, म्हणून दुसऱ्या कशालाही स्पर्श करण्याची गरज नाही. लक्षात घ्या की ही यादी एक बदली आहे, जोडणी नाही: त्या कमांडमधून www वगळल्यास नवीन प्रमाणपत्र ते मौनाने वगळते.

वाइल्डकार्डसाठी DNS-01 आवश्यक असते, आणि सहसा तुम्हाला वाइल्डकार्डची गरज नसते

HTTP-01 द्वारे *.example.com जारी करता येत नाही — वेब सर्व्हरवर फाइल ठेवणे एका होस्टनेमवर नियंत्रण सिद्ध करते, संपूर्ण नेमस्पेसचे नाही. वाइल्डकार्डसाठी DNS-01 आव्हान आवश्यक असते: Certbot _acme-challenge.example.com वर TXT रेकॉर्ड सेट करते. व्यवहारात याचा अर्थ तुमच्या DNS प्रदातासाठी API क्रेडेन्शियल्ससह certbot-dns-* प्लगइन वापरणे, किंवा प्रत्येक नूतनीकरणावर --manual सह TXT रेकॉर्ड हाताने संपादित करणे (अतिशय कष्टाचे — हा मार्ग निवडू नका). TXT रेकॉर्डच्या कार्यपद्धतीपासून ते स्वयंचलित नूतनीकरण करणाऱ्या प्लगइनपर्यंतचे संपूर्ण मार्गदर्शन DNS-01 द्वारे Certbotसह वाइल्डकार्ड प्रमाणपत्रे मध्ये उपलब्ध आहे. प्रामाणिक सल्ला: जर तुमच्याकडे चार ज्ञात सबडोमेन असतील, तर चारही समाविष्ट असलेले SAN प्रमाणपत्र वाइल्डकार्डपेक्षा सोपे असते आणि त्यासाठी सर्व्हरवर DNS API की ठेवण्याची गरज नसते.

अपयशाच्या पद्धती, आणि तुम्हाला दिसणाऱ्या स्ट्रिंग्स

Certbot सुरू होण्यास नकार देते कारण Apache ची कॉन्फिगरेशन तुटलेली आहे.

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')

प्लगइन काहीही बदलण्यापूर्वी configtest चालवते आणि Apache स्वतःच समाधानी नसल्यास बाहेर पडते — \n हे शबशः असतात कारण Certbot अपवादाचे repr प्रिंट करते. स्वतः sudo apache2ctl configtest चालवा: ते फाइल आणि ओळ दर्शवते — सहसा हाताने संपादित केलेली चूक, अस्तित्वात नसलेल्या पथाकडे निर्देश करणारा SSLCertificateFile, किंवा संदर्भित पण सक्षम न केलेला मॉड्यूल यांसारख्या कारणांमुळे. ते Syntax OK प्रिंट करेपर्यंत दुरुस्ती करा, नंतर Certbot पुन्हा चालवा.

कोणताही vhost डोमेनशी जुळत नाही.

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

हा आधीचा गहाळ झालेला-ServerName अपयश आहे, जो इश्यू वेळी आढळतो. Certbot ने प्रत्येक सक्षम port-80 vhost मध्ये तुमच्या -d शी जुळणारा ServerName/ServerAlias शोधला आणि काहीही सापडले नाही. sudo apache2ctl -S दर्शवते की Apache प्रत्यक्षात काय राउट करते; योग्य vhost मध्ये ServerName ओळ जोडा, रीलोड करा, पुन्हा प्रयत्न करा. याच जवळचा प्रकार म्हणजे व्हॅलिडेशन चुकीच्या vhost पर्यंत पोहोचणे — आव्हानाचा प्रतिसाद Invalid response ... 404 म्हणून परत येतो कारण दुसऱ्या साइटने विनंती पकडली. तपास तोच, साधन तोच: apache2ctl -S.

व्हॅलिडेशन वेळेत पूर्ण होत नाही.

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

Let's Encrypt तुमच्या DNS ने सांगितलेल्या पत्त्यावरील port 80 वर TCP कनेक्शन उघडू शकले नाही. संभाव्यतेच्या क्रमानुसार: तुमच्या प्रदात्याचा नेटवर्क फायरवॉल (ufw पेक्षा वेगळा, होस्टिंग पॅनेलमध्ये कॉन्फिगर केलेला), फक्त 443 किंवा फक्त SSH ला परवानगी देणारा ufw नियमसंच, DNS अजूनही मागील सर्व्हरकडे निर्देश करत असणे, किंवा जुना-AAAA प्रश्न — त्यांच्या सर्व्हर्सने IPv6 वर प्रयत्न केला, तुम्ही फक्त IPv4 वर उत्तर देता. VPS च्या बाहेरून तपासा: तुमच्या लॅपटॉपवरून curl -I http://example.com त्यांच्या व्हॅलिडेटरला दिसणारे जसे दिसते तसेच पुनरुत्पादन करते.

तुम्ही पुन्हा प्रयत्न करत राहून रेट लिमिटमध्ये अडकलात.

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

Let's Encrypt प्रति तास, प्रति होस्टनेम, प्रति खाते 5 अयशस्वी व्हॅलिडेशन्सची परवानगी देते — त्यांच्या 2025 रेट-लिमिट पुनर्रचनेनंतर हे एक रिफिलिंग बकेट आहे, दर 12 मिनिटांनून साधारणपणे एक रिट्राय परत मिळतो — आणि तुटलेल्या फायरवॉलविरुद्ध पुन्हा पुन्हा प्रयत्न केल्याने ते लवकर संपते. थांबून राहणे काम करते, पण खरा उपाय वर्तनात्मक आहे: कोणत्याही अपयशानंतर, ते यशस्वी होईपर्यंत स्टेजिंग एन्व्हायर्नमेंटसह डिबग करा.

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

certonly लक्षात घ्या: --dry-run फक्त certonly आणि renew सबकमांड्सद्वारे स्वीकारले जाते, आणि फक्त certbot --apache --dry-run हे स्वरूप चालण्यास नकार देते, तुम्हाला --dry-run currently only works with the 'certonly' or 'renew' subcommands सांगते. ड्राय रन स्टेजिंगविरुद्ध व्हॅलिडेट करते, ज्याच्याकडे स्वतःच्या उदार मर्यादा आहेत आणि जे वास्तविक प्रमाणपत्रे जारी करत नाही, त्यामुळे तुम्ही तिथे संपूर्ण दुपार अपयशी होऊ शकता. स्टेजिंग यशस्वी झाल्यावरच वास्तविक कमांड पुन्हा चालवा. इतर मर्यादा — प्रति आठवडा प्रति नोंदणीकृत डोमेन 50 प्रमाणपत्रे, प्रति आठवडा त्याच नाव संचाचे 5 डुप्लिकेट्स — तुम्हाला फक्त तेव्हा भेटतील जेव्हा कोणतीतरी स्क्रिप्ट लूपमध्ये पुन्हा इश्यू करत असेल.

HTTPS सुरू झाल्यावर, लक्षात ठेवा की प्रमाणपत्र ट्रान्सपोर्ट सुरक्षित करते, सर्व्हर नाही: port 22 आजूबाजूला दिवसभर पासवर्ड अंदाजांचे स्वागत करत आहे. याला Ubuntu 24.04 वर Fail2ban सोबत जोडणे ही पुढील नैसर्गिक तीस मिनिटे आहेत.

FAQ

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

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

Certbot का "Unable to find a virtual host listening on port 80" असे सांगते?

कारण सक्षम केलेल्या port-80 vhost मध्ये -d सोबत दिलेले डोमेन मॅच होणारा ServerName किंवा ServerAlias नाही. Ubuntu च्या डीफॉल्ट vhost मध्ये ServerName कमेंट करून ठेवलेले असते. sudo apache2ctl -S चालवा, त्या नावाची मालकी असलेला vhost शोधा (किंवा तयार करा), त्यात ServerName example.com जोडा, Apache रीलोड करा आणि Certbot पुन्हा चालवा.

"Timeout during connect (likely firewall problem)" ही समस्या मी कशी सोडवू?

Let's Encrypt ला तुमच्या DNS ने प्रकाशित केलेल्या पत्त्यावर port 80 पर्यंत पोहोचता आले नाही. तुमच्या प्रदात्याच्या पॅनेल-स्तरीय नेटवर्क फायरवॉलसह ufw तपासा. dig +short example.com हे VPS परत करते याची खात्री करा आणि कोणताही जुना AAAA रेकॉर्ड डिलीट करा किंवा तो योग्य करा. जर AAAA रेकॉर्ड असेल, तर व्हॅलिडेशन IPv6 ला प्राधान्य देते. सर्व्हरच्या बाहेरून curl -I http://example.com सोबत बदल तपासा. नंतर वास्तविक जारीकरणापूर्वी sudo certbot certonly --apache --dry-run -d example.com सोबत रिहर्स करा.

Ubuntu 24.04 वर Certbot प्रमाणपत्रे आपोआप नूतनीकरण करते का?

होय. apt पॅकेज certbot.timer स्थापित करते. हा systemd टायमर दिवसातून दोनदा चालतो आणि समाप्तीच्या 30 दिवस आतील कोणतेही प्रमाणपत्र नूतनीकरण करतो. त्यानंतर तो Apache रीलोड करतो. snap हे काम त्याचसाठी snap.certbot.renew.timer वापरते. systemctl list-timers certbot.timer सोबत तपासा आणि sudo certbot renew --dry-run सोबत रिहर्स करा. यावर तुम्ही स्वतःचे cron job जोडू नका.

Certbot आणि Apache सोबत मी वाइल्डकार्ड प्रमाणपत्र कसे मिळवू?

वाइल्डकार्डसाठी DNS-01 आव्हान आवश्यक आहे. Certbot ला _acme-challenge.example.com वर TXT रेकॉर्ड ठेवावा लागतो. यासाठी तुमच्या DNS प्रदात्यासाठी API क्रेडेन्शियल्ससह certbot-dns-* plugin आवश्यक आहे (--manual पर्यायासाठी प्रत्येक नूतनीकरणावर स्वहस्ते TXT रेकॉर्ड संपादित करावे लागतात). जर तुमच्याकडे फक्त काही ज्ञात सबडोमेन असतील, तर त्यांची स्पष्टपणे नोंद करणारे SAN प्रमाणपत्र सोपे आहे आणि यामुळे DNS API की सर्व्हरवरून दूर राहतात.