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

Certbot انسٹال کریں: apt یا snap

Ubuntu 24.04 پر، sudo apt install certbot python3-certbot-nginx آپ کو ایک قابلِ عمل Certbot دیتا ہے جو حقیقی، عوامی سطح پر قابلِ اعتماد Let's Encrypt سرٹیفکیٹ جاری کرتا ہے۔ Certbot کی اپنی دستاویزات آپ کو snap کی طرف رہنمائی کرتی ہیں۔ فرق بہت کم ہے۔ snap اپنی ریلیزز کی پیروی کرتا ہے۔ آرکائیو پیکیج اس چیز کی پیروی کرتا ہے جو LTS کے ساتھ آئی تھی، اور اسے صرف سیکیورٹی فکسز ملتے ہیں۔

کوئی ایک منتخب کریں۔ Certbot کی دو کاپیاں ہونے کا مطلب ہے کہ اسی /etc/letsencrypt ٹری کے لیے دو تجدید ٹائمرز چلیں گے۔ جسے آپ بھول جائیں گے، وہی آپ کو مشکلات میں ڈالے گا۔

apt کا طریقہ:

sudo apt update
sudo apt install certbot python3-certbot-nginx

یہ /usr/bin/certbot، nginx پلگ ان، ایک certbot.service + certbot.timer جوڑا، اور ایک /etc/cron.d/certbot انٹری انسٹال کرتا ہے جو systemd کے تحت کچھ نہیں کرتی۔

snap کا طریقہ:

sudo apt remove certbot python3-certbot-nginx
sudo snap install core && sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

snap اپنا ٹائمر snap.certbot.renew.timer لے کر آتا ہے۔ snap انسٹال کرنے سے پہلے apt پیکیج ہٹا دیں۔

بعد میں دونوں انسٹالیشنز ایک جیسی طرزِ عمل رکھتی ہیں۔ Certbot 2.x بطور ڈیفالٹ ECDSA (P-256) کلیدز استعمال کرتا ہے۔ صرف اس کلائنٹ کے لیے --key-type rsa پاس کریں جو ECDSA نہیں کر سکتا۔ تمام ڈیٹا /etc/letsencrypt کے تحت محفوظ ہے: archive/ میں اصل کلید اور سرٹیفکیٹ فائلیں ہوتی ہیں، live/ موجودہ فائلوں کی طرف symlinks بناتا ہے، renewal/ میں ہر سرٹیفکیٹ کے لیے ایک کنفیگ فائل ہوتی ہے، اور accounts/ میں آپ کی ACME اکاؤنٹ کلید ہوتی ہے۔

HTTP-01 دراصل کیا کرتا ہے، اور پورٹ 80 لازمی کیوں ہے

HTTP-01 چیلنج ایک کال بیک ہے۔ آپ Let's Encrypt سے example.com کا سرٹیفکیٹ طلب کرتے ہیں۔ وہ پبلک DNS میں نام کو حل کرتا ہے، جو پتہ ملتا ہے اس کے port 80 پر کنکشن کھولتا ہے، اور http://example.com/.well-known/acme-challenge/<token> کی درخواست بھیجتا ہے۔ آپ کا سرور Certbot کے ڈسک پر لکھے ہوئے عین ٹوکن مواد کے ساتھ جواب دیتا ہے۔ یہ پورا طریقہ کار ہے۔ اس کے تین نتائج نکلتے ہیں، اور ناکام ہونے والی جاری کاریوں کی اکثریت اسی کی وجہ سے ہوتی ہے۔

• port 80 کا پبلک انٹرنیٹ سے قابل رسائی ہونا لازمی ہے، صرف آپ کے لیپ ٹاپ سے نہیں۔ ایک ufw رول، کلاؤ پرووائڈر کا سیکیورٹی گروپ، یا VPS کنسول فائر وال جو صرف 443 کھولتا ہے، جاری کاری اور ہر مستقبل کی تجدید کو ناکام کر دیتا ہے۔
• DNS کا پہلے سے اس باکس کی طرف اشارہ کرنا لازمی ہے۔ تصدیقی سرور باہر سے اپنا تلاش کرتا ہے۔ آپ کے /etc/hosts اندراجات اور براؤزر کیشے اس کے لیے کچھ معنی نہیں رکھتے۔
• اگر آپ AAAA ریکارڈ شائع کرتے ہیں، تو IPv6 سب سے پہلے آزمایا جاتا ہے۔ IPv6 کنکشن مکمل ناکام ہونے پر Let's Encrypt IPv4 پر دوبارہ کوشش کرتا ہے — لیکن ایک پرانا AAAA جو اس میزبان کی طرف اشارہ کرتا ہے جو کنکشن قبول کرتا ہے اور کچھ اور پیش کرتا ہے، آپ کو مکمل ناکامی دیتا ہے۔

ریڈائریکٹس کی اجازت ہے: تصدیق ایک HTTP ریڈائریکٹ کو HTTPS تک پیروی کرتی ہے اور اس بات کو کوئی اہمیت نہیں دیتا کہ دوسرے سرے پر سرٹیفکیٹ غائب، ختم شدہ یا سیلف سائنڈ ہے۔ جو کام وہ نہیں کرے گا وہ یہ ہے کہ port 80 کے علاوہ کہیں سے شروع کرے۔ Certbot میں کوئی TLS-ALPN-01 نفاذ نہیں ہے، اس لیے "صرف 443 استعمال کریں" کوئی متبادل راستہ نہیں ہے۔

تصدیق کنندہ کا انتخاب: --nginx, --webroot, --standalone

--nginx وہ درست ڈیفالٹ ہے جب nginx پہلے سے چل رہا ہو اور ڈومین کی خدمت دے رہا ہو۔ Certbot آپ کی کنفیگریشن پڑھتا ہے، ایک عارضی چیلنج لوکیشن داخل کرتا ہے، nginx کو دوبارہ لوڈ کرتا ہے، توثیق کرتا ہے، پھر TLS ہدایات کو آپ کے سرور بلاک میں لکھتا ہے۔ کوئی ڈاؤن ٹائم نہیں ہوتا۔

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

ایک نئے سرور کے لیے اسکرپٹ شدہ طریقہ:

sudo certbot --nginx \
  -d example.com -d www.example.com \
  --agree-tos -m ops@example.com --no-eff-email \
  --redirect --non-interactive

--webroot اس وقت درست ہے جب آپ Certbot کو اپنی nginx کنفیگریشن کے قریب نہیں چاہتے — وہ کنفیگریشن جسے آپ کسی ٹیمپلیٹ سے بناتے ہیں، git میں رکھتے ہیں، یا Ansible سے پش کرتے ہیں۔ Certbot صرف چیلنج فائل لکھتا ہے، اس ڈائریکٹری میں جس کی خدمت آپ پہلے سے دے رہے ہیں۔

sudo certbot certonly --webroot -w /var/www/example.com \
  -d example.com -d www.example.com \
  --deploy-hook "systemctl reload nginx"

--standalone اس وقت درست ہے جب پورٹ 80 پر کچھ بھی نہیں سن رہا ہوتا: ایک میل سرور، ایک API جو صرف 443 بولتا ہے، یا ایک فرسٹ باؤٹ اسکرپٹ جو nginx کے وجود سے پہلے چلتا ہے۔ Certbot چند سیکنڈز کے لیے پورٹ 80 کو خود بائنڈ کرتا ہے۔ اگر nginx چل رہا ہے، تو یہ ناکام ہو جاتا ہے — اسے چلانے کے دوران بند کریں:

sudo certbot certonly --standalone -d mail.example.com \
  --pre-hook "systemctl stop nginx" \
  --post-hook "systemctl start nginx"

یہ ہکس سرٹیفکیٹ کی تجدید کنفیگریشن میں ریکارڈ ہو جاتے ہیں، اس لیے تجدید کے وقت یہی بند/چالو عمل بغیر نگرانی کے خود بخود ہوتا ہے۔

ایسا سرور بلاک جو سرٹیفکیٹ موجود ہونے اور نہ ہونے دونوں حالات میں کام کرے

یہ ایک باہمی انحصار کا مسئلہ ہے: nginx اس وقت شروع ہونے سے انکار کرتا ہے جب ssl_certificate ایک ایسی فائل کی طرف اشارہ کرے جو موجود نہیں ہے، اور nginx بند رہنے کی صورت میں Certbot تصدیق نہیں کر سکتا۔ پہلے سائٹ کو port 80 پر لائیو کریں۔

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    root /var/www/example.com;
    index index.html;

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/example.com;
        default_type "text/plain";
        try_files $uri =404;
    }

    location / {
        try_files $uri $uri/ =404;
    }
}

sudo nginx -t && sudo systemctl reload nginx چلائیں، باکس سے باہر سے curl -I http://example.com/ کے جوابات کی تصدیق کریں، پھر سرٹیفکیٹ جاری کریں۔ اس کے بعد:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/example.com;
        default_type "text/plain";
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    root /var/www/example.com;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

ACME لوکیشن پر ^~ کا پیش لاحقہ اپنا مقصد پورا کرتا ہے: یہ return 301 بلاک کو چیلنج درخواست کو جذب کرنے سے روکتا ہے۔ اس لوکیشن کو port 80 پر رکھنے کا مطلب ہے کہ سائٹ کے بقیہ حصے کے HTTPS-only ہونے کے بعد بھی تجدید جاری رہتی ہے۔

HTTP/2 کا نحو آپ کے nginx ورژن پر منحصر ہے، اور دونوں شکلوں کو ملا دینے پر ایک اسٹارٹ اپ خرابی پیدا ہوتی ہے۔ Ubuntu 24.04 میں nginx 1.24 آتا ہے، جو اسے ان لائن چاہتا ہے — listen 443 ssl http2;۔ Debian 13 میں ایک نیا nginx آتا ہے، جو الگ http2 on; ڈائریکٹو چاہتا ہے۔ پہلے nginx -v چیک کریں۔

nginx کو live/ کی طرف اشارہ کریں، کبھی بھی archive/ کی طرف نہیں۔ live/ سمولنکس ہر تجدید پر دوبارہ رد و بدل ہوتے ہیں؛ archive/ میں ایک ہارڈ پاتھ آپ کو ایک ایسے سرٹیفکیٹ پر قید کر دیتی ہے جو آپ کی نگرانی میں ہی ختم ہو جائے گا۔

وائلڈ کارڈ کا مطلب DNS-01 ہے، اور DNS-01 کا مطلب پلگ ان ہے

وائلڈ کارڈ سرٹیفکیٹ (*.example.com) کو HTTP-01 کے ذریعے تصدیق نہیں کیا جا سکتا — کیونکہ فائل حاصل کرنے کے لیے کوئی واحد ہوسٹ نام موجود نہیں ہے۔ DNS-01 واحد راستہ ہے: آپ ایک _acme-challenge.example.com TXT ریکارڈ شائش کر کنٹرول ثابت کرتے ہیں۔ Certbot کو آپ کے DNS فراہم کنندہ کے لیے API اسناد درکار ہیں تاکہ یہ بغیر نگرانی کے یہ کام کر سکے، اور اسی لیے فراہم کنندہ پلگ انز موجود ہیں۔ مکمل وائلڈ کارڈ سرٹیفکیٹ کی تفصیلی رہنمائی TXT ریکارڈ کے طریقہ کار اور مینوئل موڈ میں تجدید کے مسئلے کا احاطہ کرتی ہے؛ Cloudflare کا مختصر ورژن ذیل میں ہے۔

sudo snap set certbot trust-plugin-with-root=ok
sudo snap install certbot-dns-cloudflare

apt راستے پر یہ sudo apt install python3-certbot-dns-cloudflare ہے۔ اسناد ایک root-only فائل میں رکھیں:

# /root/.secrets/cloudflare.ini
# then: sudo chmod 600 /root/.secrets/cloudflare.ini
dns_cloudflare_api_token = your_scoped_token_here

ٹوکن کو صرف اسی ایک زون پر DNS-edit کی حقوق تک محدود رکھیں۔ یہ آپ کے DNS کی کنجی ہے؛ اسے اسی طرح سنبھالیں۔

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cloudflare.ini \
  -d example.com -d '*.example.com'

وائلڈ کارڈ کو کوٹ کریں تاکہ آپ کا شیل اسے گلوب نہ کرے۔ DNS-01 وہ بھی حل کرتا ہے جو HTTP-01 نہیں کر سکتا: ان ہوسٹس کے لیے سرٹیفکیٹ جن پر عوامی پورٹ 80 نہیں ہے — ایک اندرونی سروس، ایک باکس جو صرف VPS پر خود میزبانی کردہ WireGuard VPN کے ذریعے قابل رسائی ہو، یا نجی انٹرفیس پر ایک ایڈمن پینل۔

تجدید: 90 دن، ٹائمر، اور ڈپلائے ہک

Let's Encrypt سرٹیفکیٹس 90 دن کے لیے درست ہوتے ہیں۔ Certbot تجدید اس وقت کرتا ہے جب 30 دن سے کم وقت باقی رہ جائے۔ یہ آپ کو 30 دن کی کھڑکی دیتا ہے جس میں تجدید میں خرابی ایک قابلِ اصلاح مسئلہ رہتی ہے نہ کہ سروس کا خاتمہ۔ Let's Encrypt اب ختم ہونے کی وارننگ ای میلز نہیں بھیجتا۔ کوئی آپ کو یاد نہیں دلائے گا، اس لیے نگرانی اب آپ کی ذمہ داری ہے۔

اپنی انسٹالیشن میں شامل ٹائمر کو چیک کریں:

systemctl list-timers 'certbot*' 'snap.certbot*'
sudo certbot certificates

certbot renew /etc/letsencrypt/renewal/ میں ہر کنفیگ کو چیک کرتا ہے، 30 دن کی کھڑکی سے باہر کی ہر چیز کو چھوڑ دیتا ہے، اور باقی کی تجدید اصل رن کے بالکل وہی flags استعمال کر کے کرتا ہے۔ اسی لیے پہلی رن اہم ہے: یہ وہی ہے جسے ریکارڈ کیا جاتا ہے۔

ڈسک پر فائل کی تجدید خود بخود کچھ نہیں بدلتی۔ nginx میموری میں موجود پرانا سرٹیفکیٹ اس وقت تک پیش کرتا رہتا ہے جب تک اسے دوبارہ لوڈ کرنے کا کہا نہ جائے۔ ڈپلائے ہک کو ایک بار ترتیب دیں:

sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh >/dev/null <<'EOF'
#!/bin/sh
set -e
nginx -t && systemctl reload nginx
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

renewal-hooks/deploy/ میں کوئی بھی قابلِ اجرا فائل کسی بھی کامیاب تجدید کے بعد چلتی ہے۔ --deploy-hook flag ایک سرٹیفکیٹ کے لیے یہی کام کرتا ہے، اور renew_hook = ... کو اس کی تجدید کنفیگ میں محفوظ کرتا ہے۔ certbot --nginx آپ کے لیے دوبارہ لوڈ کرتا ہے؛ --webroot اور --standalone سیٹ اپس ایسا نہیں کرتے۔ ہک کا غائب ہونا اس کی وجہ ہے کہ ایک سائٹ ختم شدہ سرٹیفکیٹ پیش کرتی ہے جبکہ certbot certificates خوشی سے نیا سرٹیفکیٹ رپورٹ کرتا ہے۔ جو کچھ بھی اسٹارٹ اپ پر سرٹیفکیٹ پڑھتا ہے وہ وہی ہک چاہتا ہے — ایک کنٹینرائزڈ ایپ جیسے Nextcloud VPS انسٹالیشن Docker، TLS اور بیک اپس کے ساتھ کو اپنا ری اسٹارٹ یا ری لوڈ اسٹیپ یہاں بھی ترتیب دینے کی ضرورت ہے۔

حقیقی تجدید کا آزمائش

sudo certbot renew --dry-run

یہ Let's Encrypt کے staging ماحول کے خلاف مکمل challenge چلاتا ہے: وہی code path، وہی firewall، وہی DNS، کوئی rate-limit کا خرچ نہیں، اور disk پر کچھ نہیں لکھا جاتا۔ اگر یہ آج کامیاب ہو جائے، تو 60 دن بعد بغیر نگرانی کی تجدید بھی کامیاب ہو گی، بشرطیکہ اس کے درمیان server میں کوئی تبدیلی نہ ہو۔

dry run یہ ثابت نہیں کرتا کہ آپ کا reload hook چلے گا — Certbot version کے لحاظ سے اس کا رویہ مختلف ہوتا ہے۔ اس حصے کا دستی آزمائش کریں: hook script کو براہ راست چلائیں، تصدیق کریں کہ systemctl reload nginx کامیاب ہوتا ہے، اور sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf کو چیک کریں۔

وہ نقائص جو درحقیقت سامنے آئیں گے

Could not bind to IPv4 or IPv6. — nginx پہلے ہی port 80 پر قابض ہے اس لیے --standalone۔ --nginx یا --webroot استعمال کریں، یا run کے دوران nginx کو روکیں۔ sudo ss -lntp | grep ':80' سے قابض کی تصدیق کریں۔

Timeout during connect (likely firewall problem) — Let's Encrypt port 80 تک نہیں پہنچ سکا۔ باہر کی جانب چلیں: sudo ufw status (اسے sudo ufw allow 'Nginx Full' سے کھولیں)، پھر VPS فراہم کنندہ کا اپنا firewall، پھر DNS۔ اپنے server کے علاوہ کہیں سے آزمائیں: curl -sSv http://example.com/.well-known/acme-challenge/test۔ ایک پرانا AAAA record بھی یہی پیغام دیتا ہے۔

unauthorized :: Invalid response from http://example.com/.well-known/acme-challenge/xyz: 404 — port 80 قابل رسائی ہے، لیکن token پیش نہیں کیا جا رہا۔ درخواست کسی دوسرے server block میں گئی (چیک کریں کہ default_server کس کی ملکیت ہے)، یا -w کو دی گئی directory وہ نہیں جسے nginx پیش کرتا ہے۔ /var/www/example.com/.well-known/acme-challenge/test پر ایک فائل رکھیں اور اسے باہر سے حاصل کریں؛ اگر وہ 404 دے، تو certificate کبھی مسئلہ ہی نہیں تھا۔

DNS problem: NXDOMAIN looking up A for example.com — نام عوامی طور پر resolve نہیں ہو رہا۔ ایسے نئے records جو ابھی propagate نہیں ہوئے، یا ایسا record جو کسی zone میں ہے جسے آپ کا registrar پیش نہیں کر رہا۔

too many certificates already issued for: example.com — ایک rate limit، اور وہی جو لوگ بار بار debug کرتے ہوئے پھنس جاتے ہیں۔ Let's Encrypt مکرر certificates کو محدود کرتا ہے — names کا بالکل وہی مجموعہ — ہفتہ وار پانچ تک، اور علاوہ ازاں ہفتہ وار 50 نئے certificates فی registered domain کی اجازت دیتا ہے؛ وقت کے سوا کچھ بھی انہیں نہیں کھولتا۔ --dry-run کے ساتھ staging پر debug کریں۔

nginx: [emerg] cannot load certificate "/etc/letsencrypt/live/example.com/fullchain.pem": No such file or directory — nginx ایک ایسے certificate کے لیے configure ہے جو کبھی issue نہیں ہوا، یا جسے certbot delete سے ہٹا دیا گیا۔ TLS server block کو comment کر دیں، nginx چلائیں، issue کریں، پھر block بحال کریں۔

open() "/etc/letsencrypt/options-ssl-nginx.conf" failed — وہ فائل nginx plugin package کے ساتھ آتی ہے۔ ایک certonly box پر جس میں python3-certbot-nginx نہیں ہے، یا plugin شامل کریں یا include لائن کو اپنے ssl_protocols اور ssl_ciphers settings سے بدل دیں۔

اسے بڑے پیمانے پر منظم کرنا

ایک سرٹیفکیٹ میں 100 نام تک شامل ہو سکتے ہیں، اور ایک ہی certbot --nginx -d a.example.com -d b.example.com ... پرکشش لگتا ہے — یہاں تک کہ ایک پرانا DNS ریکارڈ توثیق میں ناکام ہو جائے اور اس سرٹیفکیٹ پر موجود باقی تمام ناموں کو بھی اپنے ساتھ لے جائے۔ ہر سائٹ کے لیے الگ سرٹیفکیٹ آزادانہ طور پر ناکام ہوتے ہیں، جو کہ ایک ایسی مشین پر مطلوبہ رویہ ہے جو دو سے زائد چیزیں ہوسٹ کرتی ہو۔ چند سائٹس سے زیادہ پر، ACME سے واقف فرنٹ ڈور اپنی قیمت ادا کرتا ہے: ایک Docker Compose کے تحت متعدد ایپس چلانے والا Traefik ریورس پراکسی خود سرٹیفکیٹس کی درخواست اور تجدید کرتا ہے، اور Certbot مکمل طور پر تصویر سے باہر ہو جاتا ہے۔

/etc/letsencrypt کو مکمل طور پر بیک اپ کریں — sudo tar -czf letsencrypt-$(date +%F).tar.gz -C /etc letsencrypt — سم لِنکس محفوظ رکھتے ہوئے۔ اس درخت میں accounts/، یعنی آپ کی ACME اکاؤنٹ کلید شامل ہے، جسے آپ بالکل یکساں طور پر دوبارہ پیدا نہیں کر سکتے۔ نئے VPS پر منتقل ہونا پھر اس پر آ کر ختم ہوتا ہے: درخت کو -a کے ساتھ rsync کریں، Certbot انسٹال کریں، DNS کی طرف دوبارہ اشارہ کریں، اور کٹ اوور سے پہلے certbot renew --dry-run چلائیں۔

مشین کو دوبارہ بنائیں یا نئے LTS پر منتقل ہوں، تو تجدید ٹائمر آپ کے ساتھ نہیں آتا۔ کسی بھی منتقلی، اسنیپ شٹ ری اسٹور، یا ڈسٹرو اپ گریڈ کے بعد، systemctl list-timers 'certbot*' اور ایک --dry-run چلائیں۔ اسے چھوڑنا ہی اس کا باعث بنتا ہے کہ ایک سائٹ 89 دن بعد، رات 3 بجے، ایک ایسے سرٹیفکیٹ پر اندھیرے میں آ جاتی ہے جس کی تجدید سب خود بخود ہوتی سمجھ رہے تھے۔

یہ سب کچھ اس مفروضے پر ہے کہ مشین آپ کے کنٹرول میں ہے، اس میں ایک پبلک IP ہے اور پورٹ 80 دنیا کے لیے کھلا ہے — یعنی، ایک VPS۔ ان میں سے کسی بھی ایک پر یہ طریقے بالکل یکساں ہیں۔

یہی سرٹیفکیٹ کے مراحل nginx کی بجائے Apache پر بھی لاگو ہوتے ہیں، اور جب پبلک سرٹیفکیٹ کوئی آپشن نہ ہو، تو Ubuntu پر ایک سیلف سائنڈ سرٹیفکیٹ اندرونی سروسز کا احاطہ کرتا ہے۔

FAQ

اگر میری سائٹ صرف HTTPS پیش کرتی ہے تو کیا مجھے port 80 کھلا رکھنا ضروری ہے؟

ہاں، HTTP-01 challenge کے لیے۔ Let's Encrypt ہمیشہ اپنی validation درخواست port 80 پر شروع کرتا ہے، اور Certbot میں TLS-ALPN-01 کا کوئی implementation نہیں ہے، اس لیے ایسا firewall جو صرف 443 کھلا رکھتا ہے وہ پہلی issuance اور اس کے بعد ہر unattended renewal کو بلاک کر دیتا ہے۔ port 80 سے HTTPS پر redirect درست ہے — validation اس کی پیروی کرتی ہے۔ port 80 کو مکمل طور پر چھوڑنے کا واحد طریقہ DNS-01 اور ایک provider plugin کا استعمال ہے۔

apt یا snap — Ubuntu 24.04 پر nginx کے لیے کون سا Certbot انسٹال کروں؟

apt استعمال کریں۔ sudo apt install certbot python3-certbot-nginx Ubuntu 24.04 پر آپ کو Certbot 2.9.0 دیتا ہے، جو اس گائیڈ کی ہر چیز کے لیے کافی حالیہ ہے، unattended-upgrades کے ذریعے security patches حاصل کرتا ہے، اور اس میں snapd کی ضرورت نہیں۔ snap کو تبھی منتخب کریں جب آپ کو فوراً newest release درکار ہو یا کوئی DNS plugin جو خصوصاً snap کے طور پر دستیاب ہو۔ دونوں صورتوں میں، بالکل ایک ہی منتخب کریں: دو installations کا مطلب دو renewal timers ہیں جو ایک ہی /etc/letsencrypt tree کی طرف اشارہ کرتے ہیں، اور بھولا ہوا وہی ہوتا ہے جو آپ کو نقصان پہنچاتا ہے۔

کیا Certbot nginx کے لیے wildcard certificate جاری کر سکتا ہے؟

صرف DNS-01 کے ذریعے۔ *.example.com جیسا wildcard کوئی ایک hostname نہیں رکھتا جہاں سے challenge file حاصل کی جا سکے، اس لیے --nginx، --webroot اور --standalone سب خارج ہیں۔ اپنے DNS provider کے لیے plugin انسٹال کریں، ایک scoped API token کو root-only credentials file میں رکھیں، اور certbot certonly --dns-cloudflare -d example.com -d '*.example.com' چلائیں، wildcard کو quote کرتے ہوئے تاکہ shell اسے glob نہ کرے۔

کامیاب renewal کے بعد nginx اب بھی پرانا certificate کیوں پیش کرتا ہے؟

nginx certificate کو memory میں رکھتا ہے اور reload ہونے تک disk پر نئی file کو نظر انداز کرتا ہے۔ certbot --nginx آپ کے لیے reload کرتا ہے، لیکن --webroot اور --standalone runs ایسا نہیں کرتے، اس لیے renewal کامیاب ہو سکتا ہے جبکہ browser اب بھی ایک expiring certificate دیکھتا ہے۔ /etc/letsencrypt/renewal-hooks/deploy/ میں ایک executable script ڈالیں جو nginx -t && systemctl reload nginx چلائے، اور یہ ہر کامیاب renewal کے بعد فعال ہو جائے گا۔

کیا certbot renew --dry-run ثابت کرتا ہے کہ renewal کام کرے گا؟

زیادہ تر ہاں۔ یہ staging environment کے خلاف اصل challenge چلاتا ہے — وہی firewall، وہی DNS، وہی code path — بغیر کسی rate-limit cost کے اور disk پر کچھ لکھے بغیر، اس لیے pass کا مطلب ہے کہ network ٹھیک ہے۔ تاہم، یہ قابلِ اعتماد طریقے سے یہ نہیں ثابت کرتا کہ آپ کا deploy hook فعال ہوتا ہے۔ اسے علیحدہ طور پر test کریں: hook script کو دستی طور پر چلائیں اور sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf کو check کریں۔