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 नाम। HTTP-01 एक bare IP को validate कर सकता है, लेकिन Let's Encrypt केवल अपने opt-in shortlived profile (160-घंटे की अवधि) पर ही IP certificates जारी करता है, और apt का Certbot 2.9.0 न तो ACME profiles का अनुरोध कर सकता है और न ही IP पतों का, इसलिए इस गाइड के लिए एक domain name की आवश्यकता है। dig +short example.com को आपका VPS पता लौटाना चाहिए, और यदि आपने पिछले एक घंटे में DNS बदला है, तो जारी करने से पहले पुराने record के TTL के समाप्त होने की प्रतीक्षा करें।
• यदि AAAA record मौजूद है, तो वह सही होना चाहिए। जब AAAA record प्रकाशित होता है, तो Let's Encrypt हमेशा पहले IPv6 का प्रयास करता है। यदि वह connection time out हो जाता है, तो वह IPv4 पर पुनः प्रयास करता है, लेकिन किसी अन्य त्रुटि को वह दूसरा मौका नहीं देता: एक ऐसे पते पर AAAA जो connection को अस्वीकार करता है, या किसी ऐसे live सर्वर पर जो यह सर्वर नहीं है, validation विफल हो जाता है, भले ही आपके लैपटॉप से curl, जो संभवतः IPv4 पर है, ठीक काम कर रहा हो। एक सही AAAA प्रकाशित करें या कोई भी न रखें।

Ports 80 और 443 को ufw तथा आपके प्रदाता के network firewall में खुला होना चाहिए, अधिकांश होस्टिंग पैनल में एक दूसरा firewall होता है जिसे OS कभी नहीं देख पाता। HTTP-01 विशेष रूप से port 80 पर validate करता है; आप इसे केवल 443 पर नहीं चला सकते।

sudo ufw allow "Apache Full"
sudo ufw status

इनके तैयार होने पर पूरा काम पंद्रह मिनट का है, और उनमें से दस मिनट पढ़ने में लगेंगे।

Certbot के लिए Snap या apt? 24.04 पर, apt अंततः सही है

Certbot ने वर्षों पहले एक अच्छे कारण से snap वितरण का विकल्प चुना था: distro पैकेज पुराने हो जाते थे। Ubuntu 20.04 में Certbot 0.40 आया और फिर कभी अपडेट नहीं हुआ, और प्रोजेक्ट टीम पांच साल पुरानी बग्स को ठीक करने से थक गई थी। 24.04 पर वह कारण अब समाप्त हो गया है, क्योंकि आर्काइव में Certbot 2.9.0 उपलब्ध है, जो आधुनिक 2.x लाइन का फरवरी 2024 का release है, और unattended-upgrades इसके लिए Ubuntu द्वारा जारी किए गए किसी भी सुरक्षा अपडेट को install कर देता है। अपस्ट्रीम अब 5.x सीरीज पर आगे बढ़ चुका है, लेकिन इस गाइड में किसी भी चीज़ के लिए उसकी आवश्यकता नहीं है। इस OS के लिए मेरी सिफारिश है: apt का उपयोग करें। आप snapd daemon से बच जाते हैं, Apache plugin उसी transaction में install हो जाता है, और renewal timer सामान्य Debian तरीके से systemd के साथ एकीकृत हो जाता है।

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

सही परिणाम: certbot 2.9.0। python3-certbot-apache पैकेज वह plugin है जो आपकी Apache configs को पढ़ता और संपादित करता है, इसके बिना, certbot --apache, The requested apache plugin does not appear to be installed के साथ विफल हो जाता है।

Snap अभी भी दो स्थितियों में सही विकल्प है: यदि आप Certbot का नवीनतम संस्करण उसी दिन चाहते हैं जिस दिन वह जारी होता है, या यदि आपको ऐसे DNS plugin की आवश्यकता है जो केवल snap के रूप में वितरित किया जाता है (कई certbot-dns-* प्रदाता plugins ऐसे ही हैं)। यदि आप उस रास्ते पर जाते हैं:

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

आप जो भी चुनें, दोनों को कभी न चलाएं। दो इंस्टॉलेशन का मतलब है दो renewal schedulers जो /etc/letsencrypt के लिए आपस में टकराएंगे, और PATH में आपकी shell को जो certbot मिलेगा, हो सकता है कि वह आपके certificates का स्वामी न हो। ऊपर दी गई 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

पहली बार चलाने पर यह तीन चीजें पूछता है: एक ईमेल पता (Let's Encrypt अब इसे अपने ACME account के साथ स्टोर नहीं करता है और न ही expiry की चेतावनी भेजता है, इसलिए renewals की निगरानी आपकी जिम्मेदारी है), Let's Encrypt की शर्तों के लिए सहमति, और क्या आप अपना ईमेल EFF के साथ साझा करना चाहते हैं। अब redirect के लिए कोई सवाल नहीं पूछा जाता है: Certbot 1.0 के बाद से Apache installer डिफ़ॉल्ट रूप से HTTP को HTTPS पर redirect कर देता है (यह सवाल 1.4 संस्करण में हटा दिया गया था), जो कि आप चाहते भी हैं। यदि आपको वास्तव में 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 2027-01-09.

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 पहले से enable नहीं था तो उसे enable किया, example.com-le-ssl.conf लिखा, जो *:443 पर आपके vhost की एक प्रति है जिसमें SSLEngine on और certificate paths शामिल हैं, इसे enable किया, और मूल port-80 vhost में एक RewriteRule block जोड़ा जो हर चीज़ को 301 के जरिए HTTPS पर भेज देता है। आपकी मूल vhost file को edit किया गया है, बदला नहीं गया है, और SSL twin उसके बगल में स्थित है जहाँ आप इसके द्वारा जोड़ी गई हर लाइन को पढ़ सकते हैं।

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 करना भी शामिल है।

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

Let's Encrypt certificates डिफ़ॉल्ट रूप से 90 दिनों के लिए वैध होते हैं, और apt पैकेज ने पहले ही आवश्यक तंत्र स्थापित कर दिया है: एक systemd timer जो दिन में दो बार यादृच्छिक समय पर Certbot चलाता है, और समाप्ति के 30 दिनों के भीतर किसी भी certificate को नवीनीकृत करता है। इसके ऊपर कोई cron job न जोड़ें; एक दूसरा शेड्यूलर केवल लॉग शोर और rate-limit जोखिम बढ़ाता है। Let's Encrypt ने घोषणा की है कि 10 फरवरी, 2027 से नए certificates का डिफ़ॉल्ट जीवनकाल 64 दिन का होगा। 30-दिन की विंडो उनके साथ भी काम करती रहेगी, नवीनीकरण बस 60वें दिन के बजाय 34वें दिन के आसपास होगा, इसलिए इस सर्वर पर कुछ भी बदलने की आवश्यकता नहीं है।

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

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

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

यदि dry run विफल हो जाता है, तो लगभग 60 दिनों में वास्तविक नवीनीकरण भी उसी तरह विफल हो जाएगा। इसे अभी ठीक करें, जबकि वर्तमान certificate का पूरा जीवनकाल अभी बाकी है। इसका सामान्य कारण जारी होने के बाद जोड़ा गया firewall rule है जिसने port 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 द्वारा इंस्टॉल किया गया रीडायरेक्ट है। दूसरा कमांड HTTP/1.1 200 OK लौटाना चाहिए जिसमें curl की ओर से कोई TLS त्रुटि न हो। तीसरा कमांड जारीकर्ता (issuer) को प्रिंट करता है, एक O = Let's Encrypt लाइन जिसमें YE1 या YE2 (ECDSA keys) या YR1 या YR2 (RSA keys) जैसा छोटा CN होता है, और notAfter लगभग 90 दिनों की अवधि दिखाता है। Let's Encrypt द्वारा अपने पुराने इंटरमीडिएट्स को रिटायर करने से पहले जारी किया गया सर्टिफिकेट अगले नवीनीकरण तक R12 या E7 जैसा CN दिखा सकता है; यह कोई त्रुटि नहीं है। ब्राउज़र में आपको पैडलॉक दिखाई देगा, और उस पर क्लिक करने से वही जारीकर्ता दिखाई देगा। यदि 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 स्वयं ठीक से काम नहीं कर रहा है, तो यह रुक जाता है। \n अक्षरशः होते हैं क्योंकि Certbot अपवाद (exception) के repr को प्रिंट करता है। स्वयं sudo apache2ctl configtest चलाएँ: यह फ़ाइल और लाइन का नाम बताता है, जो आमतौर पर मैन्युअल संपादन (hand-editing) के कारण हुई टाइपिंग की गलती, किसी ऐसे पथ की ओर इशारा करने वाला 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 के लिए हर सक्षम port-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 द्वारा विज्ञापित पते पर port 80 के लिए TCP कनेक्शन नहीं खोल सका। संभावना के क्रम में: आपके प्रदाता का नेटवर्क फ़ायरवॉल (जो ufw से अलग है और होस्टिंग पैनल में कॉन्फ़िगर किया गया है), एक ufw रूल्सेट जो केवल 443 या केवल SSH की अनुमति देता है, या DNS जो अभी भी पिछले सर्वर की ओर इशारा कर रहा है। केवल एक पुराना AAAA रिकॉर्ड आमतौर पर इसका कारण नहीं बनता है, क्योंकि जब IPv6 का प्रयास समय समाप्त (timeout) हो जाता है, तो Let's Encrypt IPv4 पर पुनः प्रयास करता है; AAAA की समस्या अक्सर गलत सर्वर से Connection refused या Invalid response के रूप में सामने आती है। VPS के बाहर से टेस्ट करें: अपने लैपटॉप से curl -I http://example.com चलाकर देखें कि उनका वैलिडेटर क्या देखता है।

आपने बार-बार प्रयास करके रेट लिमिट को ट्रिगर कर दिया है।

Error creating new order :: too many failed authorizations (5) for "example.com" in the last 1h0m0s, retry after ... UTC: see https://letsencrypt.org/docs/rate-limits/...

Let's Encrypt प्रति होस्टनाम प्रति अकाउंट प्रति घंटे 5 विफल वैलिडेशन की अनुमति देता है। यह एक रिफिलिंग बकेट की तरह है जो लगभग हर 12 मिनट में एक पुनः प्रयास की अनुमति वापस अर्जित करती है। खराब फ़ायरवॉल के खिलाफ बार-बार प्रयास करने से यह सीमा जल्दी खत्म हो जाती है। प्रतीक्षा करना काम करता है, लेकिन वास्तविक समाधान व्यवहार में बदलाव है: किसी भी विफलता के बाद, 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 चालू हो जाने के बाद, याद रखें कि सर्टिफिकेट ट्रांसपोर्ट को सुरक्षित करता है, सर्वर को नहीं: port 22 पर अभी भी पूरे दिन पासवर्ड का अनुमान लगाया जा सकता है। इसे Ubuntu 24.04 पर Fail2ban के साथ जोड़ना अगले तीस मिनट का स्वाभाविक कदम है।

FAQ

क्या मुझे Ubuntu 24.04 पर Apache के लिए Certbot को snap से या apt से install करना चाहिए?

apt का उपयोग करें। Ubuntu 24.04 में Certbot 2.9.0 आता है, जो इस गाइड की सभी आवश्यकताओं के लिए पर्याप्त है, unattended-upgrades के माध्यम से Ubuntu द्वारा जारी किए गए सुरक्षा अपडेट प्राप्त करता है, और इसके लिए 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 नहीं है जो उस domain से मेल खाता हो जिसे आपने -d के साथ pass किया है। 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 उस address पर port 80 तक नहीं पहुँच सका जिसे आपका DNS प्रकाशित करता है। अपने provider के panel-level network firewall के साथ-साथ ufw की भी जाँच करें। पुष्टि करें कि dig +short example.com इस VPS को return करता है, और किसी भी पुराने AAAA record को ठीक करें या हटा दें, क्योंकि validation पहले IPv6 का प्रयास करता है और timeout के बाद ही IPv4 पर वापस आता है। सर्वर के बाहर से 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 को install करता है, जो एक 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 को सर्वर से दूर रखता है।