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

आप क्या बना रहे हैं

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

दो स्कोप नोट्स। यदि आपका वेब सर्वर nginx है, तो प्रक्रिया का स्वरूप समान है लेकिन प्लगइन और कॉन्फ़िगरेशन अलग हैं, इसके बजाय इस गाइड के nginx संस्करण का उपयोग करें। और यदि आप जिस चीज़ को सुरक्षित कर रहे हैं वह केवल आंतरिक उपयोग के लिए है, जैसे कि प्राइवेट एड्रेस पर कोई एडमिन पैनल या कोई स्टेजिंग बॉक्स जिसे कोई और नहीं देखता, तो आपको सर्टिफिकेट अथॉरिटी की बिल्कुल भी आवश्यकता नहीं है; एक self-signed certificate में कम मशीनरी लगती है और यह ऑफलाइन भी काम करता है।

पूर्वापेक्षाएँ, और वे तीन तरीके जिनसे Certbot के चलने से पहले ही यह विफल हो जाता है

• Apache पहले से ही आपकी साइट को plain HTTP पर सर्व कर रहा हो। Certbot का Apache plugin एक मौजूदा साइट को edit करता है; यह नई साइट नहीं बनाता है। यदि आप एक खाली VPS से शुरुआत कर रहे हैं, तो पहले Ubuntu 24.04 पर LAMP stack बनाएँ और फिर वापस आएँ, यह गाइड उसका अधूरा TLS अध्याय है।
• आपके VPS पते पर A record वाला एक public domain। Let's Encrypt की HTTP-01 challenge का मतलब है कि उनके validation servers इंटरनेट से आपके बॉक्स से जुड़ते हैं: port forward के बिना कोई NATed homelab नहीं, कोई .local नाम नहीं, और कोई bare IP नहीं। dig +short example.com को आपका VPS पता ही दिखाना चाहिए, और यदि आपने पिछले एक घंटे में DNS बदला है, तो certificate जारी करने से पहले पुराने record के TTL के समाप्त होने की प्रतीक्षा करें।
• यदि AAAA record मौजूद है, तो उसका सही होना अनिवार्य है। Let's Encrypt AAAA record प्रकाशित होने पर IPv6 को प्राथमिकता देता है, इसलिए एक पुराना AAAA record validation को विफल कर देता है, भले ही आपके लैपटॉप से curl, जो शायद IPv4 पर हो, ठीक काम कर रहा हो। एक सही AAAA record प्रकाशित करें या कोई भी न रखें।

Ports 80 और 443 का ufw में तथा आपके प्रदाता के network firewall में खुला होना आवश्यक है, अधिकांश होस्टिंग पैनल में एक दूसरा firewall होता है जिसे OS कभी नहीं देख पाता। HTTP-01 विशेष रूप से port 80 पर validate करता है; आप इसे केवल 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 उपलब्ध है, जो कि वर्तमान पीढ़ी का release है, और unattended-upgrades इसे पैच करता रहता है। इस OS के लिए मेरी सिफारिश है: apt का उपयोग करें। आप snapd डेमन से बच जाते हैं, Apache प्लगइन उसी ट्रांजेक्शन में इंस्टॉल हो जाता है, और renewal टाइमर सामान्य Debian तरीके से systemd के साथ एकीकृत हो जाता है।

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

आप जो भी चुनें, दोनों को कभी न चलाएं। दो इंस्टॉलेशन का मतलब है दो renewal शेड्यूलर जो /etc/letsencrypt के लिए आपस में लड़ रहे हैं, और certbot जो आपका शेल PATH में ढूंढता है, हो सकता है कि वह आपके प्रमाणपत्रों का स्वामी न हो। ऊपर दी गई apt remove लाइन कोई वैकल्पिक सजावट नहीं है।

Certbot द्वारा संपादित किए जाने वाले vhost पहले से मौजूद होने चाहिए, ServerName ही मुख्य आधार है

certbot --apache उस port-80 virtual host को खोजकर काम करता है जिसका ServerName या ServerAlias आपके द्वारा दिए गए प्रत्येक -d domain से मेल खाता है। यह उस vhost के माध्यम से domain पर नियंत्रण सिद्ध करता है और फिर उस vhost का एक SSL twin तैयार करता है। यदि कोई मेल खाने वाला ServerName नहीं है, तो कोई match नहीं होगा, और Ubuntu का default 000-default.conf, ServerName को comment-out करके आता है। वह एक comment की गई line ही इस guide के मुख्य 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 इसे parse करता है और traffic को उस नाम पर route करता है:

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

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

-S output वह जांच है जो मायने रखती है। आपको port 80 namevhost example.com (/etc/apache2/sites-enabled/example.com.conf:1) जैसी एक line चाहिए जिसके नीचे alias www.example.com हो। Apache उस sites-enabled symlink की रिपोर्ट करता है जिसे उसने वास्तव में पढ़ा है, न कि उस file की जिसे आपने sites-available में edit किया था। यदि example.com port 80 के विरुद्ध सूचीबद्ध नहीं है, तो Certbot भी इसे नहीं ढूँढ पाएगा।

Certificate जारी करें: certbot --apache

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

पहली बार चलाने पर यह तीन चीजें पूछता है: एक ईमेल पता (जो आपके ACME account और जरूरी CA सूचनाओं के लिए उपयोग होता है; Let's Encrypt अब expiry की चेतावनी नहीं भेजता है, इसलिए renewals की निगरानी आपकी जिम्मेदारी है), Let's Encrypt की शर्तों के लिए सहमति, और क्या आप अपना ईमेल EFF के साथ साझा करना चाहते हैं। अब redirect के लिए कोई प्रश्न नहीं पूछा जाता है: Certbot 2.0 के बाद से Apache installer डिफ़ॉल्ट रूप से HTTP को HTTPS पर redirect करता है, जो कि वांछित व्यवहार है। यदि आपको वास्तव में content serve करने के लिए plain 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 module पहले से सक्षम नहीं था तो उसे सक्षम किया, example.com-le-ssl.conf लिखा, जो *:443 पर आपके vhost की एक प्रति है जिसमें SSLEngine on और certificate paths शामिल हैं, इसे सक्षम किया, और मूल port-80 vhost में एक RewriteRule block जोड़ा जो सब कुछ HTTPS पर 301 redirect करता है। आपकी मूल vhost file को बदला नहीं गया है, बल्कि edit किया गया है, और SSL twin उसके बगल में स्थित है जहाँ आप इसके द्वारा जोड़ी गई प्रत्येक line को पढ़ सकते हैं।

Certificate वास्तव में कहाँ रहता है, और आप इसे कभी कॉपी क्यों नहीं करते

सब कुछ /etc/letsencrypt/live/example.com/ के अंतर्गत आता है: fullchain.pem (certificate और intermediate chain, जिसे servers को point करना चाहिए), privkey.pem (private key, जो केवल root द्वारा पठनीय है), और साथ ही cert.pem तथा chain.pem उन software के लिए जिन्हें इन हिस्सों की अलग-अलग आवश्यकता होती है। ये /etc/letsencrypt/archive/ के symlinks हैं, और यह indirection ही renewal की प्रक्रिया है: renewal नई files को archive/ में लिखता है और symlinks को फिर से point करता है। किसी अन्य software को live/ paths पर point करें और यह renewals को अपने आप उठा लेगा; यदि आप files को कहीं और कॉपी करते हैं, तो आपने 90 दिनों बाद के लिए एक outage तैयार कर लिया है।

एक अन्य file जिसे जानना उपयोगी है वह है authenticator = apache, installer = apache, और domains के साथ /etc/letsencrypt/renewal/example.com.conf, जो यह record करती है कि यह certificate कैसे जारी किया गया था, ताकि renewal प्रक्रिया बिना किसी मानवीय हस्तक्षेप के दोहराई जा सके, जिसमें बाद में Apache को reload करना भी शामिल है।

Renewal पहले से ही निर्धारित है, इसे सत्यापित करें, इसे दोबारा न बनाएँ

Let's Encrypt certificates को डिज़ाइन के अनुसार 90 दिनों के लिए वैध रखा जाता है, और apt पैकेज ने पहले ही आवश्यक तंत्र स्थापित कर दिया है: एक systemd timer जो दिन में दो बार यादृच्छिक समय पर Certbot चलाता है, और समाप्ति के 30 दिनों के भीतर किसी भी certificate को renew करता है। इसके ऊपर कोई अतिरिक्त cron job न जोड़ें; दूसरा scheduler केवल log noise और rate-limit के जोखिम को बढ़ाता है।

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

पहली command सक्रिय timer को दिखाती है, जिसमें NEXT समय आने वाले 24 घंटों के भीतर होता है। schedule दिन में दो बार का है जिसमें एक यादृच्छिक देरी शामिल है, इसलिए सटीक समय जानबूझकर अनिश्चित रखा गया है (snap install पर, timer snap.certbot.renew.timer होता है)। dry run, Let's Encrypt के staging environment के विरुद्ध पूर्ण renewal का पूर्वाभ्यास करता है, जिसमें वास्तविक challenge शामिल होता है, लेकिन कोई certificate जारी नहीं होता और न ही कोई rate-limit का खर्च आता है। सही परिणाम इस पर समाप्त होता है:

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

यदि dry run विफल हो जाता है, तो ~60 दिनों में होने वाला वास्तविक renewal भी उसी तरह विफल हो जाएगा। इसे अभी ठीक करें, जबकि वर्तमान certificate का पूरा जीवनकाल अभी बाकी है। इसका सामान्य कारण जारी होने के बाद जोड़ा गया 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/ हेडर लौटाना चाहिए, जो कि Certbot द्वारा इंस्टॉल किया गया रीडायरेक्ट है। दूसरा कमांड बिना किसी TLS त्रुटि के HTTP/1.1 200 OK लौटाना चाहिए। तीसरा कमांड जारीकर्ता (issuer) को प्रिंट करता है, जिसमें O = Let's Encrypt लाइन के साथ R12 या E7 जैसा छोटा CN होता है, और notAfter लगभग 90 दिनों बाद की तारीख दिखाता है। ब्राउज़र में आपको पैडलॉक दिखाई देगा, और उस पर क्लिक करने से वही जारीकर्ता दिखाई देगा। यदि curl काम करता है और ब्राउज़र चेतावनी देता है, तो आप लगभग निश्चित रूप से एक कैश किए गए पेज या गलत होस्टनेम को देख रहे हैं, न कि किसी सर्टिफिकेट समस्या को।

मल्टीपल साइट्स: एक SAN सर्टिफिकेट या प्रति साइट एक सर्टिफिकेट

दोनों तरीके काम करते हैं; उनका नवीनीकरण (renewal) एक ही तरह से होता है। एक ही सर्वर पर मौजूद असंबंधित साइटों के लिए, प्रत्येक साइट के लिए एक बार issue कमांड चलाएँ। प्रत्येक को live/ के अंतर्गत अपनी डायरेक्टरी और अपना नवीनीकरण कॉन्फ़िगरेशन मिलता है, और एक डोमेन के साथ समस्या होने पर अन्य का नवीनीकरण नहीं रुकता। यह मेरा डिफ़ॉल्ट तरीका है।

कई नामों वाली एक साइट के लिए, उन्हें एक ही SAN सर्टिफिकेट पर रखें; एक सर्टिफिकेट में 100 नाम तक हो सकते हैं। आपने ऊपर example.com और www.example.com के साथ ऐसा पहले ही किया है। बाद में किसी मौजूदा सर्टिफिकेट में कोई नाम जोड़ने के लिए, सर्टिफिकेट का नाम और पूरे नए नामों की सूची के साथ उसे फिर से जारी (reissue) करें:

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

Certbot डोमेन सेट में बदलाव को पहचान लेता है, आपसे विस्तार (expansion) की पुष्टि करने के लिए कहता है, और सर्टिफिकेट को उसी स्थान पर बदल देता है। इसका live/ पाथ वही रहता है, इसलिए किसी और चीज़ को बदलने की आवश्यकता नहीं होती। ध्यान दें कि यह सूची एक रिप्लेसमेंट है, न कि अपेंड: यदि आप उस कमांड से www को हटा देते हैं, तो नया सर्टिफिकेट उसे बिना किसी सूचना के हटा देगा।

Wildcards के लिए DNS-01 की आवश्यकता होती है, और आमतौर पर आपको wildcard की जरूरत नहीं होती है

HTTP-01 *.example.com जारी नहीं कर सकता है, क्योंकि वेब सर्वर पर एक फाइल रखने से केवल एक hostname का नियंत्रण सिद्ध होता है, पूरे namespace का नहीं। Wildcards के लिए DNS-01 challenge की आवश्यकता होती है: Certbot _acme-challenge.example.com पर एक TXT record सेट करता है, जिसका व्यावहारिक अर्थ है आपके DNS प्रदाता के API credentials के साथ एक certbot-dns-* प्लगइन, या हर renewal पर --manual के साथ मैन्युअल रूप से TXT records को एडिट करना (यह बहुत कठिन है, इस पर निर्भर न रहें)। TXT record की कार्यप्रणाली से लेकर बिना किसी मानवीय हस्तक्षेप के renewal करने वाले प्लगइन तक की पूरी जानकारी Certbot के माध्यम से DNS-01 पर wildcard certificates में दी गई है। ईमानदार सलाह: यदि आपके पास चार ज्ञात subdomains हैं, तो उन चारों को सूचीबद्ध करने वाला एक SAN certificate, wildcard की तुलना में सरल है और इसके लिए सर्वर पर किसी DNS API key को रखने की आवश्यकता नहीं होती है।

विफलता के प्रकार और उनसे संबंधित संदेश

Apache की कॉन्फ़िगरेशन खराब होने के कारण 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')

प्लगइन किसी भी बदलाव से पहले configtest चलाता है और यदि Apache स्वयं ठीक से काम नहीं कर रहा है, तो यह रुक जाता है। \ns शाब्दिक हैं क्योंकि Certbot अपवाद (exception) के repr को प्रिंट करता है। स्वयं sudo apache2ctl configtest चलाएँ: यह फ़ाइल और लाइन नंबर बताता है, जो आमतौर पर मैन्युअल संपादन के कारण हुई टाइपिंग त्रुटि, किसी ऐसे पथ की ओर इशारा करने वाला SSLCertificateFile जो अब मौजूद नहीं है, या किसी ऐसे मॉड्यूल का संदर्भ है जिसे सक्षम (enable) नहीं किया गया है, के कारण होता है। इसे तब तक ठीक करें जब तक कि यह Syntax OK प्रिंट न कर दे, फिर Certbot को पुनः चलाएँ।

डोमेन से कोई vhost मेल नहीं खाता है।

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

यह पहले बताई गई missing-ServerName विफलता है, जो जारी करने (issue) के समय पकड़ी जाती है। Certbot ने आपके -d से मेल खाने वाले ServerName/ServerAlias के लिए हर सक्षम पोर्ट-80 vhost को खोजा और कुछ नहीं मिला। sudo apache2ctl -S दिखाता है कि Apache वास्तव में क्या रूट करता है; सही vhost में ServerName लाइन जोड़ें, reload करें और पुनः प्रयास करें। इसका एक मिलता-जुलता कारण यह है कि वैलिडेशन गलत vhost तक पहुँच रहा है, और चैलेंज रिस्पॉन्स Invalid response ... 404 आता है क्योंकि किसी अन्य साइट ने अनुरोध को पकड़ लिया है। निदान और उपकरण वही हैं: apache2ctl -S।

वैलिडेशन का समय समाप्त (timeout) हो गया है।

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

Let's Encrypt आपके DNS द्वारा विज्ञापित पते पर पोर्ट 80 के लिए TCP कनेक्शन नहीं खोल सका। संभावना के क्रम में: आपके प्रदाता का नेटवर्क फ़ायरवॉल (ufw से अलग, जो होस्टिंग पैनल में कॉन्फ़िगर होता है), एक ufw रूल्सेट जो केवल 443 या केवल SSH की अनुमति देता है, DNS का अभी भी पिछले सर्वर की ओर इशारा करना, या stale-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 मिनट में एक पुनः प्रयास (retry) वापस अर्जित करता है। टूटे हुए फ़ायरवॉल के खिलाफ बार-बार प्रयास करने से यह जल्दी खत्म हो जाता है। प्रतीक्षा करना काम करता है, लेकिन वास्तविक समाधान व्यवहार में बदलाव है: किसी भी विफलता के बाद, staging environment के साथ तब तक डीबग करें जब तक कि वह सफल न हो जाए।

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 बताता है। ड्राई रन staging के खिलाफ वैलिडेशन करता है, जिसकी अपनी उदार सीमाएँ हैं और यह कोई वास्तविक सर्टिफिकेट जारी नहीं करता है, इसलिए आप वहाँ पूरे दोपहर विफल हो सकते हैं। एक बार staging पास हो जाने के बाद ही वास्तविक कमांड को पुनः चलाएँ। अन्य सीमाएँ, जैसे प्रति पंजीकृत डोमेन प्रति सप्ताह 50 सर्टिफिकेट, या प्रति सप्ताह एक ही नाम सेट के 5 डुप्लिकेट, आप केवल तभी पार करेंगे यदि कोई स्क्रिप्ट लूप में पुनः जारी (reissue) कर रही हो।

एक बार HTTPS चालू हो जाने के बाद, याद रखें कि सर्टिफिकेट ट्रांसपोर्ट को सुरक्षित करता है, सर्वर को नहीं: पोर्ट 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 को केवल तभी चुनें यदि आपको तुरंत सबसे नया release चाहिए या कोई ऐसा DNS plugin चाहिए जो केवल snap के रूप में उपलब्ध हो। यदि आप switch करते हैं, तो पहले apt remove certbot python3-certbot-apache करें ताकि दो renewal schedulers एक साथ न चलें।

Certbot यह क्यों कहता है कि "Unable to find a virtual host listening on port 80"?

इसका कारण यह है कि किसी भी enabled port-80 vhost में वह ServerName या ServerAlias नहीं है जो आपके द्वारा -d के साथ दिए गए domain से मेल खाता हो। Ubuntu का default vhost ServerName को comment out करके आता है। sudo apache2ctl -S चलाएँ, वह vhost ढूँढें (या बनाएँ) जिसे उस नाम का स्वामी होना चाहिए, ServerName example.com जोड़ें, Apache को reload करें, और Certbot को फिर से चलाएँ।

मैं "Timeout during connect (likely firewall problem)" को कैसे ठीक करूँ?

Let's Encrypt उस पते पर port 80 तक नहीं पहुँच सका जिसे आपका DNS प्रकाशित करता है। अपने provider के panel-level network firewall के साथ-साथ ufw की भी जाँच करें। पुष्टि करें कि dig +short example.com इसी VPS को return करता है, और किसी भी पुराने AAAA record को हटा दें या सही करें, क्योंकि IPv6 मौजूद होने पर validation उसे प्राथमिकता देता है। सर्वर के बाहर से curl -I http://example.com के साथ सुधार की पुष्टि करें, फिर वास्तविक issuance से पहले sudo certbot certonly --apache --dry-run -d example.com के साथ अभ्यास करें।

क्या Certbot Ubuntu 24.04 पर certificates को स्वचालित रूप से renew करता है?

हाँ। apt package certbot.timer इंस्टॉल करता है, जो एक systemd timer है। यह दिन में दो बार चलता है और समाप्ति के 30 दिनों के भीतर किसी भी certificate को renew करता है, जिसके बाद Apache को reload कर देता है। snap इसी काम के लिए snap.certbot.renew.timer का उपयोग करता है। systemctl list-timers certbot.timer के साथ पुष्टि करें और sudo certbot renew --dry-run के साथ अभ्यास करें; इसके ऊपर अपना खुद का cron job न जोड़ें।

मैं Certbot और Apache के साथ wildcard certificate कैसे प्राप्त करूँ?

Wildcards के लिए DNS-01 challenge की आवश्यकता होती है: Certbot को _acme-challenge.example.com पर एक TXT record डालना होगा। इसका मतलब है कि आपके DNS provider के API credentials के साथ एक certbot-dns-* plugin की आवश्यकता है (--manual विकल्प के लिए हर renewal पर हाथ से TXT records को edit करना पड़ता है)। यदि आपके पास केवल कुछ ही ज्ञात subdomains हैं, तो उन्हें स्पष्ट रूप से सूचीबद्ध करने वाला एक SAN certificate अधिक सरल है और यह DNS API keys को सर्वर से दूर रखता है।