Ubuntu 24.04 पर Apache के लिए Certbot कैसे डालें

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

Ubuntu 24.04 पर एक Apache site जो HTTPS पर काम करती है। इसमें Let's Encrypt का free, browser-trusted certificate होगा — जिसे Certbot द्वारा जारी किया जाता है और systemd timer द्वारा automatically renew किया जाता है। इस प्रक्रिया के लिए केवल एक line का command चाहिए। लेकिन, काम शुरू करने से पहले सभी गलतियाँ ठीक होनी चाहिए: जैसे बिना ServerName वाला vhost, provider firewall पर बंद port 80, या पुराने server पर point करता हुआ DNS। इसलिए, यह guide preconditions पर अधिक ध्यान केंद्रित करती है और प्रत्येक गलती से मिलने वाले exact error string को बताती है।

दो महत्वपूर्ण बातें। यदि आपका web server nginx है, तो प्रक्रिया समान है लेकिन plugin और configs अलग होंगे — इसके लिए nginx version of this guide का उपयोग करें। और यदि आप किसी internal-only system को secure कर रहे हैं — जैसे private address पर admin panel, या कोई staging box जिसे कोई और visit नहीं करता — तो आपको certificate authority की आवश्यकता नहीं है; self-signed certificate कम जटिल है और offline काम करता है।

Prerequisites, और Certbot के चलने से पहले विफल होने के तीन तरीके

• Apache पहले से ही आपके site को plain HTTP पर serve कर रहा है। Certbot का Apache plugin मौजूदा site को edit करता है; यह नई site नहीं बनाता है। यदि आप एक खाली VPS से शुरुआत कर रहे हैं, तो पहले Ubuntu 24.04 पर LAMP stack सेटअप करें और फिर वापस आएं — यह guide उसका TLS chapter है।
• एक public domain जिसमें आपके VPS address का A record हो। Let's Encrypt का HTTP-01 challenge यह है कि उनके validation servers internet से आपके box से connect करते हैं: बिना port forward के NATed homelab नहीं चलेगा, कोई .local names नहीं, और bare IPs नहीं। dig +short example.com को आपका VPS address return करना चाहिए, और यदि आपने पिछले एक घंटे में DNS बदला है, तो certificate issue करने से पहले पुराने record के TTL का इंतज़ार करें।
• यदि AAAA record मौजूद है, तो वह सही होना चाहिए। जब AAAA record publish होता है, तो Let's Encrypt IPv6 को प्राथमिकता देता है, इसलिए एक stale AAAA validation को विफल कर देता है, भले ही आपके laptop से curl (जो शायद IPv4 पर है) सही काम कर रहा हो। एक सही AAAA publish करें या फिर कोई भी record न रखें।

Ports 80 और 443 ufw में और आपके provider के network firewall में open होने चाहिए — अधिकांश hosting panels में एक दूसरा firewall होता है जिसे OS नहीं देख पाता। HTTP-01 विशेष रूप से port 80 पर validate करता है; आप इसे केवल 443 पर नहीं चला सकते।

sudo ufw allow "Apache Full"
sudo ufw status

इन सब के सेटअप होने के बाद पूरा काम पंद्रह मिनट का है, जिसमें से दस मिनट पढ़ने में बीतेंगे।

Snap या apt Certbot? 24.04 पर, apt अब सही है

Certbot को सालों पहले snap distribution पर स्थानांतरित कर दिया गया था, जिसके पीछे एक ठोस कारण था: distro packages पुराने हो जाते हैं। Ubuntu 20.04 में Certbot 0.40 आया था और वह कभी अपडेट नहीं हुआ, जिससे प्रोजेक्ट के डेवलपर्स पुराने bugs को ठीक करते-करते थक गए थे। 24.04 में यह समस्या खत्म हो गई है — archive में Certbot 2.9.0 उपलब्ध है, जो कि current-generation release है, और unattended-upgrades इसे patched रखता है। इस OS के लिए मेरा सुझाव है: apt का उपयोग करें। आपको snapd daemon की आवश्यकता नहीं होगी, Apache plugin एक ही transaction में इंस्टॉल हो जाता है, और renewal timer Debian के मानक तरीके से systemd के साथ integrate हो जाता है।

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

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

दो स्थितियों में snap का उपयोग करना अभी भी सही है: यदि आप Certbot का सबसे नया version रिलीज होते ही चाहते हैं, या यदि आपको किसी ऐसे DNS plugin की आवश्यकता है जो केवल snap के रूप में उपलब्ध है (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

आप चाहे जो भी चुनें, दोनों का एक साथ उपयोग न करें। दो installs का मतलब है कि दो renewal schedulers /etc/letsencrypt के लिए आपस में लड़ेंगे, और PATH में आपकी shell द्वारा पाया गया certbot वह नहीं हो सकता जो आपके certificates का मालिक है। ऊपर दी गई apt remove line कोई वैकल्पिक सजावट नहीं है।

vhost Certbot edits पहले से मौजूद होने चाहिए — ServerName ही सबसे महत्वपूर्ण है

certbot --apache उस port-80 virtual host को खोजकर काम करता है जिसका ServerName या ServerAlias आपके द्वारा दिए गए प्रत्येक -d domain से मेल खाता है। यह इस बात का प्रमाण है कि आपके पास domain का control है, और फिर यह उस vhost का SSL twin लिखता है। यदि ServerName मेल नहीं खाता, तो कोई match नहीं मिलेगा — और Ubuntu के default 000-default.conf में ServerName commented होता है। वह एक commented line इस guide के मुख्य command के fail होने का सबसे सामान्य कारण है।

इसलिए 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 करता है और name को इसके पास 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 के बारे में warning है, न कि आपके vhost के बारे में — यहाँ यह हानिरहित है, और echo "ServerName $(hostname -f)" | sudo tee /etc/apache2/conf-available/servername.conf && sudo a2enconf servername && sudo systemctl reload apache2 द्वारा इसे शांत कर दिया जाता है।

-S output ही महत्वपूर्ण check है। आपको 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 किया है। यदि port 80 के सामने example.com सूचीबद्ध नहीं है, तो Certbot भी इसे नहीं खोज पाएगा।

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

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

पहली बार चलाने पर तीन चीजें पूछी जाती हैं: एक email address (इसका उपयोग आपके ACME account और ज़रूरी CA notices के लिए किया जाता है; Let's Encrypt अब expiry warnings नहीं भेजता है, इसलिए renewals की निगरानी आपको स्वयं करनी होगी), Let's Encrypt के terms से सहमति, और क्या आप अपना email 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 पहले से enable नहीं था, तो उसे enable किया, example.com-le-ssl.conf लिखा — जो *:443 पर आपके vhost की एक प्रति है जिसमें SSLEngine on और certificate paths शामिल हैं — इसे enable किया, और मूल port-80 vhost में एक RewriteRule block जोड़ा जो सब कुछ HTTPS पर 301s करता है। आपकी मूल vhost file को edit किया जाता है, replace नहीं; SSL twin उसके बगल में स्थित होता है जहाँ आप उसकी जोड़ी गई हर line को पढ़ सकते हैं।

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

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

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

Renewal पहले से ही schedule है — इसे verify करें, दोबारा build न करें

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

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

पहला command active timer दिखाता है, जिसमें NEXT time अगले 24 घंटों के भीतर का होगा — schedule दिन में दो बार है और इसमें randomized delay होता है, इसलिए exact time जानबूझकर unpredictable रखा गया है (snap install पर, timer snap.certbot.renew.timer होता है)। dry run Let's Encrypt के staging environment के विरुद्ध एक full renewal rehearsal करता है — इसमें real challenge होता है, लेकिन कोई certificate issue नहीं होता और न ही rate-limit का असर पड़ता है। सही result इस प्रकार समाप्त होगा:

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

यदि dry run fail होता है, तो ~60 दिनों में होने वाला real renewal भी उसी तरह fail होगा — इसे अभी ठीक करें, जब तक कि current certificate की validity बची हुई है। इसका मुख्य कारण अक्सर issuance के बाद जोड़ा गया कोई firewall rule होता है, जिसने port 80 को फिर से बंद कर दिया हो।

curl से verify करें, और 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

पहला request HTTP/1.1 301 Moved Permanently return करना चाहिए जिसमें Location: https://example.com/ header हो — यह वह redirect है जो Certbot ने install किया है। दूसरा request HTTP/1.1 200 OK return करना चाहिए और curl में कोई TLS error नहीं आना चाहिए। तीसरा request issuer को print करेगा — एक O = Let's Encrypt line जिसमें R12 या E7 जैसा छोटा CN हो — और notAfter लगभग 90 days की validity देगा। Browser में आपको padlock दिखेगा, और उस पर click करने से वही issuer दिखाई देगा। यदि curl सही काम कर रहा है लेकिन browser warning दे रहा है, तो इसका मतलब है कि आप या तो cached page देख रहे हैं या गलत hostname, यह certificate की समस्या नहीं है।

Multiple sites: ek SAN certificate ya har site ke liye ek alag cert

Dono tarike kaam karte hain; renewal ki prakriya dono ke liye ek jaisi hai. Agar ek hi box par unrelated sites hain, to har site ke liye ek baar issue command chalayein — har site ko live/ ke andar apna alag directory aur apna renewal config milega. Ek domain mein samasya hone par bhi dusre domains ka renewal nahi rukta. Main isi tarike ko recommend karta hoon.

Ek site jisme kai names hain, unke liye ek hi SAN certificate ka upyog karein — ek single cert mein 100 names tak ho sakte hain. Aapne upar example.com aur www.example.com ke saath aisa hi kiya hai. Baad mein kisi existing certificate mein naya name jodne ke liye, certificate ko reissue karein aur poori nayi list dein:

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

Certbot domain set mein badlav ko pehchan leta hai, aapse expansion confirm karne ko kehta hai, aur certificate ko usi jagah replace kar deta hai — wahi live/ path, isliye kisi aur cheez ko badalne ki zaroorat nahi hai. Dhyan rakhein ki yeh list replacement hai, append nahi: agar aap us command se www hata dete hain, to naya certificate use silently drop kar dega.

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

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

Failure modes, with the strings you will see

Certbot start नहीं हो पा रहा है क्योंकि Apache की config खराब है।

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 में कोई समस्या है, तो यह रुक जाता है — \ns सटीक हैं क्योंकि Certbot exception का repr प्रिंट करता है। sudo apache2ctl configtest को स्वयं चलाकर देखें: यह file और line का नाम बताता है — आमतौर पर यह hand-editing के दौरान हुई typo, किसी ऐसे path का SSLCertificateFile जो अब मौजूद नहीं है, या किसी ऐसे module का संदर्भ है जो enabled नहीं है। इसे तब तक ठीक करें जब तक Syntax OK प्रिंट न हो जाए, फिर Certbot को दोबारा चलाएं।

कोई भी vhost domain से मैच नहीं करता है।

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

यह पहले बताया गया missing-ServerName failure है, जो issue के समय पकड़ा जाता है। Certbot ने आपके -d से मैच करने वाले ServerName/ServerAlias के लिए हर enabled port-80 vhost को खोजा लेकिन कुछ नहीं मिला। sudo apache2ctl -S दिखाता है कि Apache वास्तव में क्या route करता है; सही vhost में ServerName line जोड़ें, reload करें, और retry करें। एक मिलता-जुलता मामला गलत vhost तक validation का पहुँचना है — challenge response Invalid response ... 404 आता है क्योंकि किसी अन्य site ने request को पकड़ लिया है। diagnosis और tool समान हैं: apache2ctl -S।

Validation timeout हो जाता है।

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

Let's Encrypt आपके DNS द्वारा बताए गए address पर port 80 पर TCP connection नहीं खोल सका। संभावना के क्रम में: आपके provider का network firewall (ufw से अलग, जो hosting panel में configure होता है), एक ufw ruleset जो केवल 443 या केवल SSH की अनुमति देता है, DNS का अभी भी पिछले server की ओर इशारा करना, या stale-AAAA समस्या — उनके servers ने IPv6 का प्रयास किया, लेकिन आपका server केवल IPv4 पर जवाब दे रहा है। VPS के बाहर से test करें: आपके laptop से curl -I http://example.com चलाने पर वही परिणाम मिलेगा जो उनका validator देखता है।

बार-बार retry करने से आप rate limit तक पहुँच गए।

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

Let's Encrypt प्रति hostname प्रति account प्रति hour 5 failed validations की अनुमति देता है — 2025 के rate-limit rework के बाद, यह एक refilling bucket है, जिसमें हर 12 मिनट में लगभग एक retry वापस मिलता है — और खराब firewall के विरुद्ध बार-बार retry करने से यह limit जल्दी खत्म हो जाती है। इंतज़ार करना काम करता है, लेकिन असली समाधान व्यवहारिक है: किसी भी failure के बाद, staging environment के साथ debug करें जब तक कि वह सफल न हो जाए।

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

certonly पर ध्यान दें: --dry-run को केवल certonly और renew subcommands द्वारा ही स्वीकार किया जाता है, और बिना किसी argument के certbot --apache --dry-run form चलाने से मना कर देता है और आपको --dry-run currently only works with the 'certonly' or 'renew' subcommands बताता है। dry run staging के विरुद्ध validate करता है, जिसकी अपनी उदार limits हैं और यह real certificates जारी नहीं करता है, इसलिए आप वहां पूरा दोपहर fail हो सकते हैं। real command को तभी दोबारा चलाएं जब staging pass हो जाए। अन्य limits — प्रति registered domain प्रति week 50 certificates, प्रति week एक ही name set के 5 duplicates — आप इनका सामना तभी करेंगे यदि कोई script loop में reissue कर रही हो।

एक बार HTTPS चालू हो जाने के बाद, याद रखें कि certificate transport को सुरक्षित करता है, server को नहीं: port 22 अभी भी पूरे दिन password guesses ले रहा है। इसे Fail2ban on Ubuntu 24.04 के साथ जोड़ना अगला स्वाभाविक कदम है।

FAQ

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

apt का उपयोग करें। Ubuntu 24.04 में Certbot 2.9.0 मिलता है, जो इस guide के सभी कार्यों के लिए पर्याप्त है। इसे unattended-upgrades के माध्यम से security patches मिलते हैं, और इसके लिए 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" क्यों कहता है?

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

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

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

क्या Certbot Ubuntu 24.04 पर certificates को automatically renew करता है?

हाँ। apt package certbot.timer install करता है, जो एक systemd timer है। यह दिन में दो बार चलता है और expiry के 30 दिनों के भीतर किसी भी certificate को renew करता है, और उसके बाद Apache को reload करता है; snap भी इसी कार्य के लिए snap.certbot.renew.timer का उपयोग करता है। systemctl list-timers certbot.timer से verify करें और 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 पर hand-edited TXT records की आवश्यकता होती है)। यदि आपके पास केवल कुछ ही ज्ञात subdomains हैं, तो उन्हें स्पष्ट रूप से सूचीबद्ध करने वाला SAN certificate अधिक सरल है और यह DNS API keys को server से दूर रखता है।