Ubuntu 24.04 Apache Certbot HTTPS Let's Encrypt

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

Ubuntu 24.04 پر ایک Apache سائٹ جو HTTPS پر جواب دیتی ہے، جس میں ایک مفت، براؤزر سے قابلِ اعتماد Let's Encrypt سرٹیفکیٹ شامل ہے۔ یہ سرٹیفکیٹ Certbot جاری کرتا ہے، اور اسے ایک systemd timer خود بخود تجدید کرتا ہے جس کے بارے میں آپ کو دوبارہ سوچنے کی ضرورت نہیں پڑتی۔ کام انجام دینے والا کمانڈ ایک ہی لائن پر مشتمل ہے۔ جو کچھ غلط ہوتا ہے وہ اس لائن سے پہلے غلط ہوتا ہے: ایک vhost جس میں ServerName موجود نہیں، فراہم کنندہ کے فائر وال پر port 80 بند ہونا، یا DNS اب بھی پرانے سرور کی طرف اشارہ کرنا۔ لہٰذا، یہ رہنمائی اپنا زیادہ تر حصہ پیشہ ورانہ شرائط پر خرچ کرتی ہے، اور ہر غلطی کے نتیجے میں جو عین غلطی کا پیغام ظاہر ہوتا ہے اس کی نشاندہی کرتی ہے۔

دائرہ کار کے حوالے سے دو باتیں۔ اگر آپ کا web server nginx ہے، تو عمل کی شکل وہی رہتی ہے لیکن پلگ اِن اور کنفیگریشنز مختلف ہوتی ہیں — اس کے بجائے اس رہنمائی کا nginx ورژن استعمال کریں۔ اور اگر وہ چیز جسے آپ محفوظ بنانا چاہتے ہیں صرف اندرونی ہے — کسی نجی پتے پر ایک ایڈمن پینل، یا ایک اسٹیجنگ باکس جس پر کوئی اور نہیں جاتا — تو آپ کو کسی سرٹیفکیٹ اتھارٹی کی ضرورت ہی نہیں؛ ایک سیلف سائنڈ سرٹیفکیٹ میں مشینری کم ہوتی ہے اور یہ آف لائن بھی کام کرتا ہے۔

ضروریات، اور وہ تین طریقے جن سے یہ Certbot کے چلنے سے پہلے ہی ناکام ہو جاتا ہے

• Apache پہلے ہی آپ کی سائٹ کو plain HTTP پر serve کر رہا ہے۔ Certbot کا Apache plugin موجودہ سائٹ میں ترمیم کرتا ہے؛ یہ کوئی نئی سائٹ نہیں بناتا۔ اگر آپ ایک خالی VPS سے شروع کر رہے ہیں، تو پہلے Ubuntu 24.04 پر LAMP stack بنائیں اور واپس آئیں — یہ گائیڈ اسی کا missing TLS باب ہے۔
• ایک public domain جس کا A record آپ کے VPS پتے پر ہو۔ Let's Encrypt کے HTTP-01 challenge کا مطلب ہے کہ ان کے validation servers انٹرنیٹ سے آپ کے باکس سے connect ہوتے ہیں: بغیر port forward کے NATed homelab نہیں، کوئی .local names نہیں، کوئی bare IPs نہیں۔ dig +short example.com کو آپ کا VPS پتا return کرنا چاہیے، اور اگر آپ نے پچھلے گھنٹے میں DNS تبدیل کیا ہے، تو issue کرنے سے پہلے پرانے record کے TTL کا انتظار کریں۔
• اگر کوئی AAAA record موجود ہے، تو وہ درست ہونا چاہیے۔ Let's Encrypt AAAA record publish ہونے پر IPv6 کو ترجیح دیتا ہے، اس لیے ایک stale AAAA validation میں ناکام ہو جاتا ہے، یہاں تک کہ جب curl آپ کے laptop سے — شاید IPv4 پر — ٹھیک کام کر رہا ہو۔ یا تو درست AAAA publish کریں یا بالکل نہ کریں۔

Ports 80 اور 443 کو ufw اور آپ کے provider کے network firewall میں کھلا ہونا ضروری ہے — زیادہ تر 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 تقسیم پر منتقل ہوا تھا ایک وجہ سے: ڈسٹرو پیکیجز متجمد ہوگئے تھے۔ 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 پر آپس میں تصادم کریں گے، اور جو certbot آپ کا شیل PATH میں تلاش کرتا ہے وہ ضروری نہیں کہ وہی ہو جو آپ کے سرٹیفکیٹس کا مالک ہے۔ اوپر دی گئی apt remove لائن کوئی اختیاری سجاوٹ نہیں ہے۔

Certbot کی ترمیم کرنے والے vhost کا پہلے سے موجود ہونا ضروری ہے — ServerName ہی سب کچھ ہے

certbot --apache اس طرح کام کرتا ہے: یہ port 80 والے virtual host کو تلاش کرتا ہے جس کا ServerName یا ServerAlias آپ کے دیے گئے ہر -d domain سے مطابقت رکھتا ہو۔ پھر اس کے ذریعے domain پر کنٹرول ثابت کرتا ہے۔ اس کے بعد اسی vhost کا SSL ہمزاد بنا کر لکھتا ہے۔ اگر کوئی مطابقت رکھنے والا ServerName نہیں ہے، تو کوئی میچ نہیں ہوگا۔ اور Ubuntu کے ڈیفالٹ 000-default.conf میں ServerName کو comment کر کے غیر فعال چھوڑا گیا ہے۔ یہی ایک comment شدہ لائن اس گائیڈ کے واحد بڑے کمانڈ کے ناکام ہوننے کی سب سے عام وجہ ہے۔

لہٰذا Certbot کو چھونے سے پہلے، سائٹ کو ایک درست 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>

اسے فعال کریں اور تصدیق کریں کہ Apache اسے parse بھی کرتا ہے اور نام کو اسی کی طرف 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 کے بارے میں ایک وارننگ ہے، آپ کے 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-enabled symlink رپورٹ کرتا ہے جسے اس نے واقعی پڑھا، نہ کہ وہ فائل جسے آپ نے sites-available میں ترمیم کی تھی۔ اگر example.com port 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 لکھا — جو آپ کے vhost کی ایک کاپی ہے جو *:443 پر مبنی ہے اور اس میں SSLEngine on اور سرٹیفکیٹ کے پاتھ شامل ہیں — اسے فعال کیا، اور اصل port-80 vhost میں ایک RewriteRule بلاک شامل کیا جو ہر چیز کو HTTPS پر 301 ریڈائریکٹ کرتا ہے۔ آپ کی اصل vhost فائل میں ترمیم کی گئی ہے، اسے تبدیل نہیں کیا گیا، اور SSL ٹوین اس کے ساتھ موجود ہے جہاں آپ اس کا ہر لائن پڑھ سکتے ہیں جو اس نے شامل کی ہے۔

سرٹیفکیٹ اصل میں کہاں موجود ہوتا ہے، اور آپ اسے کیوں کاپی نہیں کرتے

سب کچھ /etc/letsencrypt/live/example.com/ کے تحت آتا ہے: fullchain.pem (سرٹیفکیٹ اور انٹرمیڈیٹ چین — جس کی طرف سرورز کو اشارہ کرنا چاہیے)، privkey.pem (نجی کلید، صرف روٹ پڑھ سکتا ہے)، اس کے علاوہ 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 ماحول کے خلاف تجدید کی ایک مکمل ریہرسل کرتا ہے — حقیقی چیلنج، کوئی جاری شدہ سرٹیفکیٹ نہیں، کوئی rate-limit قیمت نہیں۔ درست نتیجہ اس کے ساتھ ختم ہوتا ہے:

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

اگر dry run ناکام ہو، تو تقریباً 60 دن میں ہونے والی حقیقی تجدید بھی اسی طرح ناکام ہوگی — اسے ابھی درست کریں، جبکہ موجودہ سرٹیفکیٹ کی پوری عمر ابھی باقی ہے۔ عام مجرم ایک 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 شکایت نہیں ہونی چاہیے۔ تیسرا کمانڈ جاری کنندہ کو ظاہر کرتا ہے — ایک O = Let's Encrypt لائن جس میں مختصر CN جیسے R12 یا E7 ہو — اور notAfter تقریباً 90 دن بعد ہو۔ براؤزر میں آپ کو تالا نظر آتا ہے، اور اسے کلک کرنے پر وہی جاری کنندہ ظاہر ہوتا ہے۔ اگر curl کام کرتا ہے اور براؤزر تنخواہ دیتا ہے، تو تقریباً یقینی ہے کہ آپ کیش شدہ صفحہ یا غلط ہوسٹ نام دیکھ رہے ہیں، سرٹیفکیٹ کا مسئلہ نہیں۔

متعدد سائٹس: ایک 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 خود خوش نہیں ہے تو دستبردار ہو جاتا ہے — \ns اس لیے لفظی ہیں کیونکہ 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 سے الگ، ہوسٹنگ پینل میں کنفیگرڈ)، ایک ufw رول سیٹ جو صرف 443 یا صرف SSH کی اجازت دیتا ہے، DNS اب بھی پچھلے سرور کی طرف اشارہ کر رہا ہے، یا پرانا-AAAA مسئلہ — ان کے سرورز نے IPv6 آزمایا، آپ کا صرف IPv4 پر جواب دیتا ہے۔ VPS سے باہر سے ٹیسٹ کریں: آپ کے لیپ ٹاپ سے curl -I http://example.com وہی دوبارہ پیدا کرتا ہے جو ان کا validator دیکھتا ہے۔

آپ نے دوبارہ کوشش کرتے ہوئے ریٹ لیمٹ میں داخل ہو گئے۔

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 کو صرف اس وقت منتخب کریں جب آپ کو فوراً تازہ ترین ریلیز درکار ہو یا کوئی DNS پلگ ان جو خصوصی طور پر snap کے طور پر تقسیم ہوتا ہو — اور اگر آپ تبدیل کرتے ہیں، تو پہلے apt remove certbot python3-certbot-apache کریں تاکہ دو تجدید شیڈولر ایک ساتھ موجود نہ ہوں۔

Certbot کیوں کہتا ہے "Unable to find a virtual host listening on port 80"؟

اس لیے کہ فعال port-80 vhost میں کوئی ServerName یا ServerAlias موجود نہیں جو آپ نے -d کے ساتھ دیے گئے ڈومین سے ملے — 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 ریکارڈ حذف یا درست کریں — جب کوئی IPv6 موجود ہو تو تصدیق اس کو ترجیح دیتی ہے۔ ٹھیک کرنے کے بعد سرور سے باہر curl -I http://example.com سے تصدیق کریں، پھر اصل جاری کرنے سے پہلے sudo certbot certonly --apache --dry-run -d example.com سے مشق کریں۔

کیا Certbot Ubuntu 24.04 پر سرٹیفکیٹس کی خودکار تجدید کرتا ہے؟

ہاں۔ 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-* پلگ ان (--manual متبادل ہر تجدید پر دستی طور پر ترمیم شدہ TXT ریکارڈ چاہیے)۔ اگر آپ کے پاس صرف چند معلوم سب ڈومینز ہیں، تو انہیں واضح طور پر درج کرنے والا SAN سرٹیفکیٹ آسان ہے اور سرور سے DNS API کلیدز کو دور رکھتا ہے۔