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

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

Ubuntu 24.04 پر sudo apt install certbot python3-certbot-nginx ایسا فعال Certbot فراہم کرتا ہے جو حقیقی، عوامی طور پر trusted Let's Encrypt certificates جاری کرتا ہے۔ Certbot کی upstream دستاویزات اس کے بجائے snap استعمال کرنے کی ہدایت دیتی ہیں؛ فرق محدود ہے۔ snap upstream releases کو follow کرتا ہے، جبکہ archive package اس release کے ساتھ فراہم ہونے والے ورژن کو follow کرتا ہے جو LTS کے ساتھ ship ہوا تھا، اور اسے security fixes ملتی رہتی ہیں۔

ایک طریقہ منتخب کریں۔ Certbot کی 2 copies رکھنے سے ایک ہی /etc/letsencrypt tree کے لیے 2 renewal timers بن جاتے ہیں، اور جس copy کو آپ بھول جاتے ہیں، وہی بعد میں غیر متوقع مسئلہ پیدا کرتی ہے۔

apt طریقہ:

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

یہ /usr/bin/certbot، nginx plugin، certbot.service + certbot.timer pair، اور /etc/cron.d/certbot entry انسٹال کرتا ہے، جو 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 اپنا timer، snap.certbot.renew.timer، فراہم کرتا ہے۔ snap انسٹال کرنے سے پہلے apt package کو remove کریں۔

اس کے بعد دونوں installations ایک ہی طرح کام کرتی ہیں۔ Certbot 2.x میں بطور default ECDSA (P-256) keys استعمال ہوتی ہیں۔ --key-type rsa صرف ایسے client کے لیے دیں جو ECDSA استعمال نہیں کر سکتا۔ تمام state /etc/letsencrypt کے تحت محفوظ ہوتی ہے: archive/ میں اصل key اور certificate files ہوتی ہیں، live/ موجودہ files کی طرف symlinks فراہم کرتا ہے، renewal/ میں ہر certificate کے لیے ایک config file ہوتی ہے، اور accounts/ میں آپ کی ACME account key ہوتی ہے۔

HTTP-01 دراصل کیا کرتا ہے، اور port 80 اختیاری کیوں نہیں ہے

HTTP-01 challenge ایک callback ہے۔ آپ Let's Encrypt سے example.com کے لیے certificate طلب کرتے ہیں؛ یہ public DNS میں نام resolve کرتا ہے، ملنے والے address پر port 80 سے connection کھولتا ہے، اور http://example.com/.well-known/acme-challenge/<token> کی request بھیجتا ہے۔ آپ کا server اسی exact token content کے ساتھ جواب دیتا ہے جو Certbot نے ابھی disk پر لکھا ہے۔ طریقۂ کار یہی ہے۔ اس کے 3 نتائج نکلتے ہیں، اور زیادہ تر ناکام issuance کی وجہ یہی بنتے ہیں۔

• port 80 public internet سے قابل رسائی ہونا چاہیے، صرف آپ کے laptop سے نہیں۔ ufw rule، cloud-provider security group، یا VPS-console firewall جو صرف 443 کھولتا ہے، issuance اور اس کے بعد ہر renewal کو ناکام بنا دیتا ہے۔
• DNS کو پہلے ہی اس box کی طرف point کرنا چاہیے۔ Validation server باہر سے خود lookup کرتا ہے؛ آپ کی /etc/hosts entries اور browser cache اس کے لیے بے معنی ہیں۔
• اگر آپ AAAA record publish کرتے ہیں تو IPv6 پہلے آزمایا جاتا ہے۔ اگر IPv6 connection مکمل طور پر ناکام ہو جائے تو Let's Encrypt IPv4 کے ذریعے دوبارہ کوشش کرتا ہے، لیکن کسی ایسے host کی طرف اشارہ کرنے والا پرانا AAAA record جو connection قبول کرتا ہو اور کوئی دوسری چیز serve کرتا ہو، قطعی failure کا سبب بنتا ہے۔

Redirects کی اجازت ہے: validation HTTP redirect کو HTTPS کی طرف follow کرتا ہے اور اسے اس بات سے فرق نہیں پڑتا کہ دوسری طرف موجود certificate missing، expired یا self-signed ہے۔ لیکن یہ port 80 کے علاوہ کسی اور port سے شروع نہیں ہوگا۔ Certbot میں TLS-ALPN-01 implementation موجود نہیں، اس لیے "صرف 443 استعمال کریں" قابل عمل متبادل نہیں ہے۔

authenticator کا انتخاب: --nginx، --webroot، --standalone

--nginx اس وقت درست default ہے جب nginx پہلے سے چل رہا ہو اور domain کو پہلے ہی serve کر رہا ہو۔ Certbot آپ کی configuration کو parse کرتا ہے، عارضی challenge location شامل کرتا ہے، nginx کو reload کرتا ہے، validation مکمل کرتا ہے، پھر server block میں TLS directives لکھ دیتا ہے۔ Downtime نہیں ہوتی۔

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

نئے server کے لیے scripted طریقہ:

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 configuration سے بالکل الگ رکھنا چاہتے ہوں، مثلاً configuration template سے generate کرتے ہوں، git میں محفوظ رکھتے ہوں، یا Ansible کے ذریعے deploy کرتے ہوں۔ Certbot صرف challenge file اس directory میں لکھتا ہے جسے آپ پہلے ہی serve کر رہے ہوتے ہیں۔

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

--standalone اس وقت درست ہے جب port 80 پر کوئی service listen نہ کر رہی ہو: مثلاً mail server، صرف 443 پر کام کرنے والی API، یا ایسا first-boot script جو nginx کے موجود ہونے سے پہلے چلتا ہو۔ Certbot چند سیکنڈ کے لیے خود port 80 پر bind کرتا ہے۔ اگر nginx چل رہا ہو تو یہ عمل ناکام ہو جاتا ہے؛ run کے دوران اسے روک دیں:

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

یہ hooks certificate کی renewal configuration میں درج ہو جاتے ہیں، اس لیے renewal کے وقت بھی یہی stop/start عمل unattended طور پر ہوتا ہے۔

وہ server block جو certificate موجود ہونے سے پہلے اور بعد میں کام کرے

یہ chicken-and-egg مسئلہ ہے: nginx ایسے ssl_certificate کی طرف اشارہ کرنے پر start نہیں ہوتا جس کی file موجود نہ ہو، جبکہ Certbot اس وقت validation نہیں کر سکتا جب nginx بند ہو۔ پہلے site کو 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 چلائیں، box کے باہر سے تصدیق کریں کہ curl -I http://example.com/ جواب دے رہا ہے، پھر certificate جاری کریں۔ اس کے بعد:

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 location پر ^~ prefix اہم ہے۔ یہ return 301 block کو challenge request سنبھالنے سے روکتا ہے۔ اس location کو port 80 پر رکھنے سے site کے باقی حصے کے HTTPS-only ہونے کے بعد بھی renewals کام کرتی رہتی ہیں۔

اوپر دیے گئے دونوں blocks disk سے files serve کرتے ہیں؛ اگر nginx اس کے بجائے کسی application کے سامنے front end کے طور پر کام کر رہا ہو تو location / ایک proxy_pass block بن جائے گا۔ reverse proxy server block کی ایک ایک سطر میں اس application کے مطلوبہ headers کی وضاحت ہے، جبکہ ACME location اور TLS directives بالکل اسی طرح رہیں گی۔

HTTP/2 syntax آپ کے nginx version پر منحصر ہے۔ دونوں forms کو خلط ملط کرنے سے startup error پیدا ہوتا ہے۔ Ubuntu 24.04 کے ساتھ nginx 1.24 آتا ہے، جو اسے inline چاہتا ہے: listen 443 ssl http2;۔ Debian 13 کے ساتھ نیا nginx آتا ہے، جو الگ http2 on; directive چاہتا ہے۔ پہلے nginx -v چیک کریں۔

nginx کو live/ کی طرف point کریں، archive/ کی طرف کبھی نہیں۔ ہر renewal پر live/ symlinks کا نیا مقام مقرر کیا جاتا ہے؛ archive/ کے اندر hard path استعمال کرنے سے آپ ایسے certificate سے وابستہ رہیں گے جو آپ کے علم کے بغیر expire ہو جائے گا۔

وائلڈ کارڈز کا مطلب DNS-01 ہے، اور DNS-01 کا مطلب plugin ہے

وائلڈ کارڈ certificate (*.example.com) کی توثیق HTTP-01 کے ذریعے نہیں ہو سکتی، کیونکہ فائل حاصل کرنے کے لیے کوئی ایک hostname موجود نہیں ہوتا۔ واحد طریقہ DNS-01 ہے: آپ _acme-challenge.example.com TXT record شائع کر کے اس hostname پر اپنا اختیار ثابت کرتے ہیں۔ Certbot کو یہ کام unattended طور پر کرنے کے لیے آپ کے DNS provider کے API credentials درکار ہوتے ہیں، اور provider plugins اسی مقصد کے لیے موجود ہیں۔ مکمل وائلڈ کارڈ certificate walkthrough میں TXT record کے طریقہ کار اور manual mode میں renewal trap کی وضاحت ہے؛ مختصر Cloudflare طریقہ ذیل میں دیا گیا ہے۔

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

apt والے طریقے میں اس کے بجائے sudo apt install python3-certbot-dns-cloudflare استعمال کریں۔ Credentials صرف root کے لیے قابل رسائی file میں رکھیں:

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

Token کو صرف اسی zone میں DNS edit کرنے کے اختیارات تک محدود رکھیں۔ یہ آپ کے DNS کی key ہے؛ اسے اسی لحاظ سے محفوظ رکھیں۔

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

وائلڈ کارڈ کو quotes میں لکھیں تاکہ آپ کا shell اسے glob نہ کرے۔ DNS-01 اس مسئلے کو بھی حل کرتا ہے جسے HTTP-01 حل نہیں کر سکتا: ایسے hosts کے لیے certificates جن پر public port 80 موجود نہ ہو، کسی internal service کے لیے، ایسے box کے لیے جو صرف VPS پر self-hosted WireGuard VPN کے ذریعے قابل رسائی ہو، یا private interface پر موجود admin panel کے لیے۔

تجدید: 90 دن، timer اور deploy hook

Let's Encrypt certificates کی مدت 90 دن ہوتی ہے۔ Certbot اس وقت تجدید کرتا ہے جب 30 دن سے کم مدت باقی رہ جائے۔ اس طرح آپ کے پاس 30 دن کی گنجائش ہوتی ہے، جس میں ناکام renewal کسی outage کے بجائے قابل اصلاح مسئلہ رہتی ہے۔ Let's Encrypt اب expiry-warning emails نہیں بھیجتا۔ کوئی آپ کو یاد دہانی بھی نہیں کرائے گا، اس لیے monitoring اب آپ کی ذمہ داری ہے۔

اپنی installation کے ساتھ فراہم کیا گیا timer دیکھیں:

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

certbot renew، /etc/letsencrypt/renewal/ میں موجود ہر config کو دیکھتا ہے، 30 دن کی window سے باہر والی configs کو چھوڑ دیتا ہے، اور باقی کی تجدید بالکل انہی flags کے ساتھ کرتا ہے جو اصل run میں استعمال ہوئے تھے۔ اسی لیے پہلی run اہم ہے: record اسی run کا بنتا ہے۔

Disk پر file کی تجدید ہونے سے خود کچھ تبدیل نہیں ہوتا۔ nginx memory میں موجود پرانا certificate فراہم کرتا رہتا ہے، جب تک اسے reload کرنے کا حکم نہ دیا جائے۔ ایک بار deploy hook configure کریں:

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/ میں موجود کوئی بھی executable ہر successful renewal کے بعد چلتا ہے۔ --deploy-hook flag ایک certificate کے لیے یہی کام کرتا ہے اور renew_hook = ... کو اس کی renewal config میں محفوظ کرتا ہے۔ certbot --nginx آپ کے لیے reload کر دیتا ہے؛ --webroot اور --standalone setups ایسا نہیں کرتے۔ Hook موجود نہ ہونے کی یہی وجہ ہے کہ کوئی site expired certificate فراہم کرتی رہتی ہے، جبکہ certbot certificates اطمینان سے نیا certificate رپورٹ کرتا ہے۔ جو بھی دوسری service startup پر certificate پڑھتی ہے، اسے بھی یہی hook درکار ہوگا۔ Docker، TLS اور backups کے ساتھ Nextcloud VPS installation جیسی containerised app کے لیے بھی اپنا restart یا reload step یہاں configure کریں۔

حقیقی renewal کی جانچ

sudo certbot renew --dry-run

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

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

وہ errors جن کا آپ کو حقیقت میں سامنا ہوگا

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

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

unauthorized :: Invalid response from http://example.com/.well-known/acme-challenge/xyz: 404، port 80 قابل رسائی ہے، لیکن token serve نہیں ہو رہا۔ request کسی دوسرے server block تک پہنچی ہے؛ دیکھیں کہ default_server کا مالک کون سا block ہے، یا -w کو دیا گیا directory وہ نہیں ہے جسے nginx serve کرتا ہے۔ /var/www/example.com/.well-known/acme-challenge/test پر ایک file رکھ کر اسے بیرونی طور پر fetch کریں؛ اگر وہاں 404 آئے تو مسئلہ certificate میں نہیں تھا۔

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

too many certificates already issued for: example.com، rate limit ہے، اور debugging کو loop میں جاری رکھنے والے افراد کو عموماً یہی مسئلہ درپیش ہوتا ہے۔ Let's Encrypt ایک ہی exact set of names کے duplicate certificates کی حد 5 فی ہفتہ مقرر کرتا ہے، اور registered domain کے لیے الگ سے 50 نئے certificates فی ہفتہ کی اجازت دیتا ہے؛ دونوں صورتوں میں صرف وقت گزرنے سے پابندی ختم ہوتی ہے۔ --dry-run کے ساتھ staging پر debugging کریں۔

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

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

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

ایک certificate میں زیادہ سے زیادہ 100 نام شامل ہو سکتے ہیں، اور ایک ہی certbot --nginx -d a.example.com -d b.example.com ... رکھنا پرکشش لگتا ہے، لیکن ایک پرانا DNS record validation میں ناکام ہو جائے تو اس certificate کے تمام دوسرے نام بھی متاثر ہو جاتے ہیں۔ ہر site کے لیے الگ certificates ایک دوسرے سے آزادانہ طور پر ناکام ہوتے ہیں، اور ایک ایسے box پر یہی مطلوب ہے جہاں دو سے زیادہ سروسز چل رہی ہوں۔ چند sites سے زیادہ ہونے پر ACME سے باخبر front door اپنا فائدہ ثابت کرتا ہے: Docker Compose کے تحت متعدد ایپس چلانے والا Traefik reverse proxy خود certificates کی درخواست اور renewal کرتا ہے، اس لیے Certbot کی ضرورت مکمل طور پر ختم ہو جاتی ہے۔ اس front door کے لیے کون سا proxy استعمال کرنا ہے، یہ الگ فیصلہ ہے، اور Nginx، Caddy اور Traefik کا تقابل زیادہ تر اس بات پر منحصر ہے کہ certificate management اور ہر ایپ کی configuration کا کتنا کام آپ proxy کے سپرد کرنا چاہتے ہیں۔

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

Box کو دوبارہ بنائیں یا نئے LTS پر منتقل ہوں تو renewal timer آپ کے ساتھ منتقل نہیں ہوتا۔ کسی بھی migration، snapshot restore یا distro upgrade کے بعد systemctl list-timers 'certbot*' اور ایک --dry-run چلائیں۔ اسے چھوڑ دینا اس بات کا سبب بن سکتا ہے کہ 89 دن بعد، رات 3am پر، site بند ہو جائے؛ وہ certificate جس کے بارے میں سب نے فرض کر رکھا تھا کہ اس کی renewal خودکار طور پر ہو رہی ہے۔

یہ سب ایسی machine فرض کرتا ہے جسے آپ control کرتے ہوں، جس کا public IP ہو اور port 80 پوری دنیا کے لیے کھلا ہو؛ دوسرے لفظوں میں، ایک VPS۔ اوپر بیان کردہ طریقہ کار ان سب پر یکساں ہے۔

یہی certificate کے مراحل nginx کے بجائے Apache پر بھی لاگو ہوتے ہیں، اور جب public certificate کا اختیار موجود نہ ہو تو Ubuntu پر self-signed certificate داخلی سروسز کے لیے کافی ہے۔

FAQ

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

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

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

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

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

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

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

nginx certificate کو memory میں رکھتا ہے اور disk پر موجود نئی file کا اس وقت تک پتا نہیں چلتا جب تک اسے reload نہ کیا جائے۔ certbot --nginx خود آپ کے لیے reload کرتا ہے، لیکن --webroot اور --standalone ایسا نہیں کرتے۔ اس لیے renewal کامیاب ہو سکتی ہے، جبکہ browser کو اب بھی ختم ہونے والا 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 استعمال نہیں ہوتی، اور disk پر کچھ نہیں لکھا جاتا۔ اس لیے کامیابی سے معلوم ہوتا ہے کہ network والا حصہ درست ہے۔ تاہم یہ deploy hook کے اجرا کی قابلِ اعتماد تصدیق نہیں کرتا۔ اسے الگ سے test کریں: hook script دستی طور پر چلائیں اور sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf چیک کریں۔