Ubuntu 24.04 پر Apache کے لیے Certbot انسٹال کریں

آپ کیا بنا رہے ہیں

Ubuntu 24.04 پر ایک Apache site، جو HTTPS پر جواب دیتی ہے اور Certbot کے ذریعے جاری کردہ مفت، browser-trusted Let's Encrypt certificate استعمال کرتی ہے۔ یہ certificate ایک systemd timer خودکار طور پر renew کرتا ہے، اس لیے بعد میں آپ کو اس کے بارے میں دوبارہ سوچنے کی ضرورت نہیں رہتی۔ کام کرنے والی command ایک ہی line ہے۔ جو بھی خرابی آتی ہے، وہ اس line سے پہلے آتی ہے: ایسا vhost جس میں ServerName نہ ہو، provider firewall پر بند port 80، یا اب بھی پرانے server کی طرف اشارہ کرتا ہوا DNS۔ اسی لیے اس guide کا زیادہ تر حصہ ضروری ابتدائی شرائط پر ہے، اور ہر غلطی سے ظاہر ہونے والا درست error string بھی دیا گیا ہے۔

دائرۂ کار سے متعلق دو باتیں۔ اگر آپ کا web server nginx ہے تو طریقۂ کار کی بنیادی ساخت وہی ہے، لیکن plugin اور configurations مختلف ہیں؛ اس کے بجائے اس guide کا nginx ورژن استعمال کریں۔ اگر جس چیز کو آپ secure کر رہے ہیں وہ صرف داخلی استعمال کے لیے ہے، مثلاً private address پر موجود admin panel یا ایسا staging box جس تک کوئی اور رسائی نہیں کرتا، تو آپ کو certificate authority کی ضرورت نہیں۔ self-signed certificate کم انتظامی پیچیدگی رکھتا ہے اور offline بھی کام کرتا ہے۔

شرائطِ لازم، اور Certbot کے چلنے سے پہلے ناکامی کی تین صورتیں

• Apache آپ کی site کو پہلے ہی سادہ HTTP پر پیش کر رہا ہو۔ Certbot کا Apache plugin موجودہ site میں ترمیم کرتا ہے؛ یہ نئی site نہیں بناتا۔ اگر آپ خالی VPS سے شروع کر رہے ہیں تو پہلے Ubuntu 24.04 پر LAMP stack تیار کریں اور پھر واپس آئیں؛ یہ guide اسی میں موجود TLS باب کو مکمل کرتی ہے۔
• آپ کے VPS کے پتے پر A record والا public domain موجود ہو۔ Let's Encrypt کا HTTP-01 challenge اس بات پر مبنی ہے کہ اس کے validation servers internet کے ذریعے آپ کے server سے connect کریں۔ اس لیے port forwarding کے بغیر NAT والا homelab، .local names، اور bare IPs قابلِ استعمال نہیں ہیں۔ dig +short example.com کو آپ کے VPS کا address واپس کرنا چاہیے۔ اگر آپ نے گزشتہ hour میں DNS تبدیل کیا ہے تو certificate جاری کرنے سے پہلے پرانے record کی TTL ختم ہونے تک انتظار کریں۔
• اگر AAAA record موجود ہو تو وہ درست ہونا چاہیے۔ جب AAAA record شائع ہو تو Let's Encrypt IPv6 کو ترجیح دیتا ہے۔ اس لیے پرانا AAAA validation ناکام کر دیتا ہے، چاہے آپ کے laptop سے، غالباً IPv4 کے ذریعے، curl درست طور پر کام کر رہا ہو۔ درست AAAA شائع کریں، یا AAAA record بالکل نہ رکھیں۔

Port 80 اور 443 کو ufw میں بھی کھلا ہونا چاہیے اور آپ کے provider کے network firewall میں بھی۔ زیادہ تر hosting panels میں دوسرا firewall ہوتا ہے جسے OS دیکھ ہی نہیں پاتا۔ HTTP-01 کی validation خاص طور پر port 80 کے ذریعے ہوتی ہے؛ آپ اسے صرف 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 فراہم کیا گیا اور اس کے بعد اسے اپ ڈیٹ نہیں کیا گیا، جبکہ project کے منتظمین پانچ سال پرانے bugs کی debugging سے تنگ آ گئے۔ 24.04 میں یہ وجہ ختم ہو چکی ہے۔ archive میں Certbot 2.9.0 فراہم کیا گیا ہے، جو موجودہ نسل کا release ہے، اور unattended-upgrades اسے patched رکھتا ہے۔ اس OS کے لیے میری تجویز ہے: apt استعمال کریں۔ اس طرح snapd daemon کی ضرورت نہیں رہتی، Apache plugin اسی transaction میں install ہو جاتا ہے، اور 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 configurations کو پڑھتا اور ان میں ترمیم کرتا ہے۔ اس کے بغیر certbot --apache، The requested apache plugin does not appear to be installed کے ساتھ fail ہو جاتا ہے۔

دو صورتوں میں snap اب بھی درست انتخاب ہے: آپ Certbot کا سب سے نیا version اس کے release ہوتے ہی چاہتے ہیں، یا آپ کو ایسا DNS plugin درکار ہے جو صرف snap کے طور پر distributed ہو، کیونکہ 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 ایک دوسرے سے متصادم ہوں گے، اور PATH میں آپ کے shell کو ملنے والا certbot شاید وہ نہ ہو جو آپ کے certificates کا مالک ہے۔ اوپر دی گئی apt remove line اختیاری decoration نہیں ہے۔

Certbot میں ترمیم کیے جانے والے vhost پہلے سے موجود ہونے چاہییں، ServerName ہی بنیادی شرط ہے

certbot --apache اس port-80 virtual host کو تلاش کر کے کام کرتا ہے جس کا ServerName یا ServerAlias آپ کے فراہم کردہ ہر -d domain سے مطابقت رکھتا ہو۔ پھر یہ اسی کے ذریعے domain پر اپنا اختیار ثابت کرتا ہے اور اس vhost کی SSL نقل لکھتا ہے۔ اگر مطابقت رکھنے والا ServerName نہ ہو تو کوئی match نہیں ملتا، جبکہ Ubuntu کا default 000-default.conf، ServerName کو commented out حالت میں فراہم کرتا ہے۔ یہی ایک commented 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 بھی کر رہا ہے اور نام کو اسی vhost تک route بھی کر رہا ہے:

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 بھی دکھائے تو یہ 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 وہ جانچ ہے جو اہم ہے۔ آپ کو 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 کے تحت ترمیم کی ہے۔ اگر example.com کو port 80 کے سامنے درج نہ کیا گیا ہو تو Certbot بھی اسے تلاش نہیں کر سکے گا۔

سرٹیفکیٹ جاری کریں: certbot --apache

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

پہلی بار چلانے پر تین چیزیں پوچھی جاتی ہیں: ایک email address، جو آپ کے ACME account اور CA کی فوری اطلاعات کے لیے استعمال ہوتا ہے؛ Let's Encrypt اب expiry warnings نہیں بھیجتا، اس لیے renewals کی monitoring آپ کی ذمہ داری ہے؛ پھر Let's Encrypt کی شرائط سے اتفاق، اور یہ کہ آیا آپ اپنا email EFF کے ساتھ share کرنا چاہتے ہیں۔ اب redirect سے متعلق سوال نہیں آتا: Certbot 2.0 کے بعد Apache installer HTTP کو HTTPS پر default طور پر redirect کرتا ہے، اور یہی مطلوبہ configuration ہے۔ اگر واقعی 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 نہیں تھا تو اسے enable کیا؛ example.com-le-ssl.conf لکھا، جو آپ کے vhost کی *:443 پر موجود copy ہے اور اس میں SSLEngine on اور certificate paths شامل ہیں؛ اسے enable کیا؛ اور اصل port-80 vhost میں RewriteRule block شامل کیا، جو ہر request کو 301 کے ذریعے HTTPS پر redirect کرتا ہے۔ آپ کی اصل vhost file replace نہیں ہوتی بلکہ edit کی جاتی ہے، جبکہ SSL والی copy اسی کے ساتھ موجود رہتی ہے، جہاں شامل کی گئی ہر line پڑھی جا سکتی ہے۔

اصل certificate کہاں موجود ہوتی ہے، اور آپ اسے کبھی copy کیوں نہیں کرتے

تمام فائلیں /etc/letsencrypt/live/example.com/ کے تحت موجود ہوتی ہیں: fullchain.pem (certificate اور intermediate chain، جن کی طرف servers کو point کرنا چاہیے)، privkey.pem (private key، جسے صرف root پڑھ سکتا ہے)، اور ان software کے لیے cert.pem اور chain.pem جو یہ اجزا الگ الگ چاہتے ہیں۔ یہ /etc/letsencrypt/archive/ کے اندر موجود فائلوں کے symlinks ہیں، اور یہی renewal کا طریقہ ہے: renewal نئی فائلیں archive/ میں لکھتی ہے اور symlinks کو نئی فائلوں کی طرف repoint کرتی ہے۔ کسی بھی دوسرے software کو live/ والے paths پر point کریں، اور اسے renewals خود بخود مل جائیں گی؛ فائلیں کہیں اور copy کرنے سے آپ نے 90 دن بعد ہونے والی outage خود پیدا کر لی ہے۔

دوسری قابلِ ذکر file /etc/letsencrypt/renewal/example.com.conf ہے۔ اس میں درج ہوتا ہے کہ یہ certificate کیسے جاری ہوئی، authenticator = apache، installer = apache، اور domains، تاکہ renewal بغیر نگرانی کے یہی عمل دوبارہ انجام دے سکے، جس میں بعد میں Apache کو reload کرنا بھی شامل ہے۔

Renewal پہلے ہی شیڈول ہے، اس کی تصدیق کریں، نیا شیڈول نہ بنائیں

Let's Encrypt certificates ڈیزائن کے لحاظ سے 90 دن تک مؤثر رہتے ہیں، اور apt package نے ضروری نظام پہلے ہی install کر دیا ہے: ایک systemd timer جو دن میں دو مرتبہ random اوقات پر چلتا ہے اور expiry میں 30 دن یا اس سے کم باقی رہنے والے ہر certificate کو renew کرتا ہے۔ اس کے ساتھ cron job شامل نہ کریں؛ دوسرا scheduler صرف log noise اور rate-limit exposure میں اضافہ کرے گا۔

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

پہلی command timer کے active ہونے کو دکھاتی ہے۔ اس میں آنے والے 24 گھنٹوں کے اندر کسی وقت کا NEXT وقت نظر آنا چاہیے۔ schedule روزانہ دو مرتبہ ہے اور اس میں randomized delay شامل ہے، اس لیے درست وقت جان بوجھ کر غیر متوقع رکھا جاتا ہے۔ snap install پر timer snap.certbot.renew.timer ہوتا ہے۔ dry run، Let's Encrypt کے staging environment کے خلاف مکمل renewal rehearsal چلاتا ہے۔ challenge حقیقی ہوتا ہے، لیکن کوئی certificate جاری نہیں کیا جاتا اور rate-limit پر کوئی اثر نہیں پڑتا۔ درست نتیجہ اس پر ختم ہوتا ہے:

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

اگر dry run ناکام ہو جائے تو تقریباً 60 دن بعد ہونے والی حقیقی renewal بھی اسی طرح ناکام ہو جائے گی۔ اسے ابھی درست کریں، جب موجودہ certificate کی پوری مدت ابھی باقی ہے۔ عام وجہ یہ ہوتی ہے کہ 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/ header ہونا چاہیے۔ یہ وہ redirect ہے جسے Certbot نے انسٹال کیا ہے۔ دوسری کمانڈ کو HTTP/1.1 200 OK واپس کرنا چاہیے، اور curl کی طرف سے TLS کے بارے میں کوئی شکایت نہیں ہونی چاہیے۔ تیسری کمانڈ issuer، O = Let's Encrypt کی ایک لائن دکھاتی ہے جس میں R12 یا E7 جیسا مختصر CN ہوتا ہے، اور notAfter تقریباً 90 دن بعد کی تاریخ دکھاتا ہے۔ browser میں padlock ظاہر ہوگا، اور اس پر کلک کرنے سے وہی issuer نظر آئے گا۔ اگر curl کام کرتا ہے لیکن browser warning دکھاتا ہے تو تقریباً یقینی طور پر آپ cached page یا غلط hostname دیکھ رہے ہیں؛ مسئلہ certificate کا نہیں ہے۔

متعدد 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 کا نام اور مکمل نئی فہرست دے کر اسے دوبارہ issue کریں:

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

Certbot تبدیل شدہ domain set کو پہچان لیتا ہے، آپ سے certificate میں توسیع کی تصدیق طلب کرتا ہے، اور certificate کو اسی جگہ، یعنی live/ path پر، replace کر دیتا ہے۔ اس لیے کسی اور چیز کو تبدیل کرنے کی ضرورت نہیں ہوتی۔ یاد رکھیں کہ یہ فہرست replacement ہے، append نہیں۔ اگر اس command سے www خارج کر دیں تو نیا certificate اسے خاموشی سے خارج کر دے گا۔

وائلڈ کارڈ کے لیے DNS-01 درکار ہے، اور عموماً وائلڈ کارڈ کی ضرورت نہیں ہوتی

HTTP-01 *.example.com جاری نہیں کر سکتا، کیونکہ web server پر فائل رکھنا صرف ایک hostname کے کنٹرول کا ثبوت ہے، پورے namespace کا نہیں۔ وائلڈ کارڈ کے لیے DNS-01 challenge درکار ہوتا ہے: Certbot _acme-challenge.example.com پر TXT record بناتا ہے۔ عملی طور پر اس کے لیے certbot-dns-* plugin درکار ہوتا ہے، جس میں آپ کے DNS provider کے API credentials شامل ہوں، یا ہر renewal پر --manual کے ذریعے TXT records دستی طور پر edit کرنے پڑتے ہیں۔ یہ طریقہ انتہائی دشوار ہے، اس لیے اس پر منصوبہ نہ بنائیں۔ TXT record کے طریقۂ کار سے لے کر unattended renewal کرنے والے plugin تک مکمل طریقۂ کار DNS-01 کے ذریعے Certbot کے ساتھ وائلڈ کارڈ certificates میں موجود ہے۔ واضح مشورہ: اگر آپ کے چار معلوم subdomains ہیں تو چاروں کو درج کرنے والا SAN certificate وائلڈ کارڈ سے زیادہ سادہ ہے، اور اس کے لیے 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 خود درست حالت میں نہ ہو تو یہ رک جاتا ہے۔ \ns لفظی طور پر موجود ہیں، کیونکہ Certbot exception کا repr پرنٹ کرتا ہے۔ خود sudo apache2ctl configtest چلائیں۔ یہ file اور line کی نشاندہی کرتا ہے۔ عموماً وجہ ہاتھ سے edit کرتے وقت ہونے والی typo، کسی ایسے path کی طرف اشارہ کرنے والا SSLCertificateFile جس کا وجود باقی نہ رہا ہو، یا ایسا module ہوتا ہے جس کا حوالہ دیا گیا ہو لیکن وہ enabled نہ ہو۔ جب تک اس کا output Syntax OK نہ آ جائے، خرابی درست کرتے رہیں۔ اس کے بعد Certbot دوبارہ چلائیں۔

کسی vhost میں domain match نہیں ہوتا۔

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

یہ پہلے بیان کردہ missing-ServerName failure ہے، جو certificate issue کرتے وقت سامنے آتا ہے۔ Certbot نے ہر enabled port-80 vhost میں ایسا ServerName/ServerAlias تلاش کیا جو آپ کے -d سے match کرتا ہو، لیکن کچھ نہیں ملا۔ sudo apache2ctl -S سے معلوم ہوتا ہے کہ Apache حقیقت میں request کو کہاں route کرتا ہے۔ درست vhost میں ServerName line شامل کریں، configuration reload کریں، پھر دوبارہ کوشش کریں۔ اس سے ملتی جلتی صورت یہ ہے کہ validation غلط vhost تک پہنچ رہی ہو۔ اس صورت میں challenge response Invalid response ... 404 واپس آتا ہے، کیونکہ کسی دوسری site نے request سنبھال لی۔ تشخیص وہی ہے اور tool بھی وہی: apache2ctl -S۔

Validation کا وقت ختم ہو جاتا ہے۔

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 میں configured ہوتا ہے؛ ufw ruleset جو صرف 443 یا صرف SSH کی اجازت دیتا ہو؛ DNS کا اب بھی پچھلے server کی طرف point کرنا؛ یا 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 تبدیلی کے بعد یہ refilling bucket ہے، جس میں تقریباً ہر 12 minutes بعد ایک 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 کے ساتھ accepted ہے۔ سادہ certbot --apache --dry-run form بالکل نہیں چلتا اور آپ کو --dry-run currently only works with the 'certonly' or 'renew' subcommands بتاتا ہے۔ dry run staging کے خلاف validation کرتا ہے۔ staging کی اپنی نسبتاً فراخ limits ہوتی ہیں اور یہ حقیقی certificates جاری نہیں کرتا، اس لیے آپ وہاں پورا دن ناکام ہو سکتے ہیں۔ حقیقی command صرف اس وقت دوبارہ چلائیں جب staging کامیاب ہو جائے۔ دوسری limits، یعنی فی registered domain فی week 50 certificates اور ہر week ایک ہی name set کے 5 duplicates، آپ اسی وقت پوری کریں گے جب کوئی script loop میں دوبارہ issue کر رہی ہو۔

HTTPS فعال ہونے کے بعد یاد رکھیں کہ certificate صرف transport کو محفوظ کرتا ہے، server کو نہیں۔ port 22 پر اب بھی سارا دن password guesses آ سکتی ہیں۔ اسے Ubuntu 24.04 پر Fail2ban کے ساتھ استعمال کرنا اگلے 30 minutes کے لیے موزوں قدم ہے۔

FAQ

کیا Ubuntu 24.04 پر Apache کے لیے Certbot کو snap سے install کرنا چاہیے یا apt سے؟

apt استعمال کریں۔ Ubuntu 24.04 میں Certbot 2.9.0 شامل ہے، جو اس گائیڈ کی تمام ہدایات کے لیے کافی نیا ہے، unattended-upgrades کے ذریعے security patches حاصل کرتا ہے، اور snapd کی ضرورت نہیں رکھتا۔ snap صرف اس صورت میں منتخب کریں جب آپ کو فوراً تازہ ترین release درکار ہو یا ایسا DNS plugin چاہیے جو صرف snap کے ذریعے تقسیم ہوتا ہو۔ اگر آپ طریقہ تبدیل کریں تو پہلے 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 out حالت میں فراہم کرتا ہے۔ sudo apache2ctl -S چلائیں، پھر وہ vhost تلاش کریں یا بنائیں جسے یہ name handle کرنا چاہیے، ServerName example.com شامل کریں، Apache reload کریں، اور Certbot دوبارہ چلائیں۔

"Timeout during connect (likely firewall problem)" کو کیسے درست کروں؟

Let's Encrypt اس address پر port 80 تک نہیں پہنچ سکا جو آپ کے DNS میں publish ہے۔ اپنے provider کے panel-level network firewall کے ساتھ ufw بھی چیک کریں، تصدیق کریں کہ dig +short example.com اسی VPS پر resolve ہوتا ہے، اور کوئی پرانا AAAA record موجود ہو تو اسے حذف یا درست کریں؛ اگر IPv6 موجود ہو تو validation اسے ترجیح دیتی ہے۔ server کے باہر سے curl -I http://example.com کے ذریعے fix کی تصدیق کریں، پھر اصل issuance سے پہلے sudo certbot certonly --apache --dry-run -d example.com کے ساتھ rehearsal کریں۔

کیا Ubuntu 24.04 پر Certbot certificates خودکار طور پر renew کرتا ہے؟

ہاں۔ apt package certbot.timer install کرتا ہے، جو 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 دستی طور پر edit کرنے کا تقاضا کرتا ہے۔ اگر آپ کے پاس صرف چند معلوم subdomains ہیں تو SAN certificate زیادہ سادہ ہے، جس میں ان subdomains کو واضح طور پر درج کیا جاتا ہے، اور اس سے DNS API keys server سے باہر رہتی ہیں۔