Certbot سے DNS-01 کے ذریعے wildcard certificate

وائلڈ کارڈ certificate کے لیے DNS-01 کیوں ضروری ہے

وائلڈ کارڈ certificate کسی domain کے ہر first-level subdomain کا احاطہ کرتا ہے: *.example.com، app.example.com، blog.example.com اور کوئی بھی دوسری ایسی name جو ایک label گہری ہو، سے match کرتا ہے۔ Let's Encrypt وائلڈ کارڈ certificates صرف DNS-01 challenge کے ذریعے جاری کرتا ہے، اس لیے Certbot کو _acme-challenge.example.com پر TXT record شائع کرکے domain کے DNS پر کنٹرول ثابت کرنا ہوتا ہے۔ HTTP-01 challenge اس مقصد کے لیے کافی نہیں، کیونکہ token file فراہم کرنے سے صرف ایک hostname پر کنٹرول ثابت ہوتا ہے، یعنی وہ hostname جہاں سے validation server نے file حاصل کی تھی۔ وائلڈ کارڈ ہر ممکنہ name کے بارے میں domain کے تحت دعویٰ ہوتا ہے، اور پوری namespace کی نمائندگی کرنے والا واحد public record خود DNS ہے۔

یہی ایک شرط اس صفحے کی باقی تمام ترتیب طے کرتی ہے۔ DNS-01 کامیابی سے مکمل کرنے کے لیے آپ کو domain کے zone میں TXT records بنانے کی صلاحیت ہونی چاہیے۔ یہ کام دستی طور پر یا اپنے DNS provider کے API (application programming interface) کے ذریعے کیا جا سکتا ہے۔ دستی طریقہ ایک مرتبہ کام کرتا ہے، لیکن renewal کے وقت ناکام ہو جاتا ہے؛ اس کی واضح وجہ نیچے دی گئی ہے۔ Certbot DNS plugin کے ذریعے API والا طریقہ unattended renewal کرتا ہے، اور آخر میں آپ کو یہی setup استعمال کرنا چاہیے۔

یہ ہماری Certbot guides کا wildcard chapter ہے۔ عام single-hostname certificates، web server configuration اور port 80 کے rules Ubuntu 24.04 پر nginx کے ساتھ Certbot اور Ubuntu 24.04 پر Apache کے ساتھ Certbot میں بیان کیے گئے ہیں۔

_acme-challenge TXT ریکارڈ کیسے کام کرتا ہے

جب Certbot *.example.com کی درخواست کرتا ہے تو Let's Encrypt ایک بے ترتیب token بھیجتا ہے۔ Certbot اس token کو آپ کی ACME (automatic certificate management environment) account key کے ساتھ ملا کر SHA-256 سے hash کرتا ہے اور ایک مختصر متنی value تیار کرتا ہے۔ یہ value _acme-challenge.example.com پر TXT ریکارڈ کے طور پر موجود ہونی چاہیے۔ اس کے بعد Let's Encrypt اپنے infrastructure سے آپ کے domain کے authoritative name servers کو query کرتا ہے۔ اگر اسے ملنے والا ریکارڈ متوقع value سے مطابقت رکھتا ہو تو آپ ثابت کر دیتے ہیں کہ zone آپ کے control میں ہے، اور zone کا control اس کے تحت موجود ہر name کے control کے طور پر قبول کیا جاتا ہے۔

زیادہ تر failures کی وجہ دو تفصیلات ہوتی ہیں:

• ایک ہی certificate پر example.com اور *.example.com کی درخواست کرنے کا مطلب دو الگ challenges ہیں، اور دونوں TXT records ایک ہی name، _acme-challenge.example.com، پر موجود ہوتے ہیں۔ دونوں کا ایک ہی وقت میں موجود ہونا ضروری ہے۔ دوسرا record شامل کرنا درست ہے؛ پہلے record کو دوسرے record سے replace کرنے سے پہلا challenge fail ہو جاتا ہے۔
• Validation آپ کے authoritative servers سے data پڑھتی ہے، لیکن provider کے control panels کو نیا record وہاں پہنچانے میں ایک منٹ یا اس سے زیادہ وقت لگ سکتا ہے۔ Validation شروع کرنے سے پہلے باہر سے check کریں:

dig +short TXT _acme-challenge.example.com @1.1.1.1

جب اس command کے output میں وہ value ظاہر ہو جس کی Certbot نے درخواست کی تھی تو validation کامیاب ہو سکتی ہے۔ اگر output خالی ہو تو انتظار کریں اور اسے دوبارہ چلائیں۔

ایک بار اسے چلتے ہوئے دیکھیں: manual mode

manual mode میں DNS edit آپ کو خود کرنا ہوتا ہے۔ Automation سے پہلے طریقۂ کار سمجھنے کے لیے یہ بہترین طریقہ ہے:

sudo certbot certonly --manual --preferred-challenges dns -d example.com -d '*.example.com'

wildcard کے گرد موجود quotes آپ کے shell کو * کو filename pattern سمجھنے سے روکتے ہیں۔ Certbot ہدایات دکھا کر رک جاتا ہے:

Please deploy a DNS TXT record under the name:
_acme-challenge.example.com.
with the following value:
Jx9mQ2wLr8vTn5cKp0aYdG3hB7fZs4eN1oiRuXqMk6E

اپنے DNS provider کے panel میں یہ TXT record بنائیں۔ اوپر دی گئی dig command سے تصدیق کریں کہ یہ نظر آ رہا ہے۔ اس کے بعد ہی Enter دبائیں۔ چونکہ اس run میں bare domain اور wildcard دونوں مانگے جاتے ہیں، اس لیے Certbot دو بار prompt دکھاتا ہے۔ Issuance مکمل ہونے تک دونوں records برقرار رکھیں۔ کامیابی پر آخر میں یہ معروف lines ظاہر ہوتی ہیں:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem

دستی موڈ خودکار تجدید کیوں نہیں کر سکتا

ہر تجدید میں نیا challenge اور نیا token استعمال ہوتا ہے، اس لیے TXT value ہر بار تبدیل ہو جاتی ہے۔ آج شامل کیا گیا record 60 دن بعد بے کار ہو جائے گا۔ تجدید کا timer دن میں دو بار Certbot کو unattended طریقے سے چلاتا ہے، اور اس وقت کوئی شخص keyboard پر موجود نہیں ہوتا جو نئی value paste کر سکے۔ اسی لیے دستی طور پر جاری کیا گیا certificate درج ذیل error کے ساتھ تجدید میں ناکام ہو جاتا ہے:

Failed to renew certificate example.com with error: The manual plugin is not
working; there may be problems with your existing configuration.
The error was: PluginError('An authentication script must be provided with
--manual-auth-hook when using the manual plugin non-interactively.')

آپ --manual-auth-hook scripts لکھ کر یہ requirement پوری کر سکتے ہیں، جو آپ کے DNS provider کی API کو call کریں۔ لیکن اس مرحلے پر آپ عملاً DNS plugin دوبارہ خود تیار کر رہے ہوں گے۔ flow سمجھنے کے لیے manual mode استعمال کریں، یا ایسے domain پر واقعی صرف ایک بار کے لیے استعمال کریں جس کے DNS کو ابھی automate نہیں کیا جا سکتا۔ day 90 سے کافی پہلے reminder set کریں، کیونکہ Let's Encrypt اب expiry emails نہیں بھیجتا۔ باقی تمام صورتوں میں plugin استعمال کریں۔

Ubuntu 24.04 پر plugin route: certbot-dns-cloudflare

DNS plugin آپ کے DNS provider کے لیے API credential محفوظ رکھتا ہے اور issuance کے وقت اور ہر renewal پر پورا TXT record عمل خود انجام دیتا ہے۔ یہاں Cloudflare کو عملی مثال کے طور پر استعمال کیا گیا ہے، کیونکہ زیادہ تر صارفین کو اسی provider plugin کی ضرورت ہوتی ہے اور یہ Ubuntu میں package کی صورت میں دستیاب ہے۔

Ubuntu 24.04 پر ہماری Certbot guides apt packages استعمال کرنے کی تجویز دیتی ہیں، اور Cloudflare کے لیے بھی یہی طریقہ درست ہے:

sudo apt update
sudo apt install certbot python3-certbot-dns-cloudflare

Versions کے بارے میں ایک اہم وضاحت ہے۔ 24.04 archive میں یہ plugin version 2.0.0 پر اور Certbot 2.9.0 کے ساتھ دستیاب ہے؛ apt policy python3-certbot-dns-cloudflare آپ کے installed version کو دکھاتا ہے۔ یہ فرق مسئلہ پیدا نہیں کرتا، اور scoped API tokens کام کرتے ہیں، کیونکہ 24.04 میں بنیادی python3-cloudflare library version 2.11.1 ہے، جو token support کے لیے درکار version 2.3.1 سے جدید ہے۔ Ubuntu کی پرانی releases میں یہ library tokens کے لیے بہت پرانی تھی۔ اسی وجہ سے آن لائن ملنے والی وہ warnings پیدا ہوتی ہیں جن کے مطابق apt plugin Global API Key کو لازمی بناتا ہے۔ 24.04 پر یہ warnings اب لاگو نہیں ہوتیں۔

Cloudflare dashboard میں Global API Key کے بجائے scoped API token بنائیں: My Profile، پھر API Tokens، پھر Create Token منتخب کریں۔ صرف Zone / DNS / Edit permission دیں اور اسے اسی ایک zone تک محدود رکھیں جس کے لیے certificate جاری کرنا ہے۔ اسے ایسی file میں محفوظ کریں جسے صرف root پڑھ سکے:

sudo mkdir -p /root/.secrets
sudo tee /root/.secrets/cloudflare.ini > /dev/null <<'EOF'
dns_cloudflare_api_token = paste_your_scoped_token_here
EOF
sudo chmod 600 /root/.secrets/cloudflare.ini

اگر file دوسرے صارفین کے لیے بھی readable ہو تو Certbot اس کا mode چیک کرتا ہے اور Unsafe permissions on credentials configuration file کے بارے میں warning دکھاتا ہے۔ اب certificate جاری کریں:

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

Plugin API کے ذریعے TXT records بناتا ہے، مختصر propagation delay کا انتظار کرتا ہے، validation مکمل ہونے دیتا ہے، اور پھر records دوبارہ حذف کر دیتا ہے۔ اگر آپ کے zone کے name servers تبدیلیاں قبول کرنے میں سست ہوں تو --dns-cloudflare-propagation-seconds 60 کے ذریعے انتظار کا وقت بڑھائیں۔ Certificate /etc/letsencrypt/live/example.com/ میں محفوظ ہو جاتا ہے۔ پھر nginx یا Apache کو fullchain.pem اور privkey.pem پر point کریں، بالکل اسی طرح جیسے base guides میں دکھایا گیا ہے، جس میں deploy hook بھی شامل ہے۔

اگر آپ کے provider کا plugin apt میں موجود نہیں ہے

24.04 archive میں صرف چند providers کے plugins package کیے گئے ہیں۔ ان میں Cloudflare، Route 53، DigitalOcean اور عمومی RFC 2136 interface شامل ہیں۔ فہرست دیکھنے کے لیے apt search certbot-dns چلائیں۔ اگر آپ کا provider موجود نہیں ہے تو یہاں ہماری apt-first ہدایت میں استثنا ہے: اس کے بجائے Certbot اور plugin کو snap سے install کریں، اور پہلے apt والا Certbot remove کریں تاکہ دو renewal timers کبھی /etc/letsencrypt پر ایک دوسرے سے متصادم نہ ہوں:

sudo apt remove certbot python3-certbot-dns-cloudflare
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
sudo snap set certbot trust-plugin-with-root=ok
sudo snap install certbot-dns-yourprovider

snap plugin صرف snap والے Certbot سے connect ہوتا ہے۔ یہ apt والے Certbot کو extend نہیں کر سکتا۔ اسی لیے دونوں installations ایک ساتھ موجود نہیں ہونی چاہییں۔ اگر آپ کا DNS host کوئی API فراہم نہیں کرتا تو عملی اختیارات یہ ہیں کہ domain کا DNS ایسے provider کو منتقل کریں جس کے پاس API ہو، یا اپنا name server چلائیں اور rfc2136 plugin کو اس کی طرف point کریں۔

تجدید: ابھی ثابت کریں، 60 دن بعد نہیں

Certbot ریکارڈ کرتا ہے کہ ہر certificate کس طرح جاری کیا گیا تھا۔ یہ معلومات /etc/letsencrypt/renewal/example.com.conf میں محفوظ ہوتی ہیں، جن میں authenticator = dns-cloudflare اور credentials path بھی شامل ہیں۔ اس لیے معمول کا دن میں دو بار چلنے والا timer آپ کی مدد کے بغیر certificate کی تجدید کر دیتا ہے۔ پورے عمل کو staging environment کے خلاف آزمائیں:

sudo certbot renew --dry-run

کامیاب نتیجے کا مطلب ہے کہ credential کام کر رہا ہے اور validation ابتدا سے آخر تک مکمل ہو رہی ہے۔ 60 دن بعد ہونے والی حقیقی تجدید بھی اسی عمل کی پیروی کرے گی۔ آج ہی دو مزید اقدامات کریں۔ اول، disk پر renewed certificate موجود ہونے سے کچھ تبدیل نہیں ہوتا، جب تک web server اسے دوبارہ load نہ کرے۔ اس لیے nginx اور Apache guides میں بیان کردہ deploy hook شامل کریں۔ دوم، credentials file کو حساس سمجھیں۔ جو شخص اسے پڑھ سکتا ہے، وہ آپ کے DNS zone میں ترمیم کر سکتا ہے۔ اس سے وہ آپ کی mail کو redirect کر سکتا ہے یا اپنے DNS-01 challenges مکمل کر سکتا ہے۔ اسے /root کے تحت mode 600 کے ساتھ رکھیں، token کو صرف ایک zone تک محدود کریں، اور اگر کبھی leak کا شبہ ہو تو اسے rotate کریں۔

جب wildcard کی ضرورت نہ ہو

بہت سے subdomains کے لیے، یا ایسے subdomains کے لیے جن کا پہلے سے اندازہ نہ لگایا جا سکے، wildcard درست انتخاب ہے۔ باقی تمام صورتوں میں اسے default انتخاب نہیں ہونا چاہیے۔

• ایک subdomain، یا چند معلوم subdomains: ایک عام SAN (subject alternative name) certificate زیادہ سادہ ہوتا ہے۔ certbot --nginx -d example.com -d www.example.com -d app.example.com عام HTTP-01 کے ذریعے 100 names تک cover کرتا ہے، اور DNS API credential کبھی بھی server پر موجود نہیں رہتا۔
• ایک wildcard صرف ایک label سے match کرتا ہے۔ *.example.com bare example.com کو cover نہیں کرتا، اسی لیے اوپر دیے گئے commands دونوں کے لیے request بھیجتے ہیں، اور یہ a.b.example.com کو بھی cover نہیں کرتا؛ اس کے لیے *.b.example.com درکار ہوگا۔
• ہر subdomain کے پیچھے ایک ہی private key استعمال ہوتی ہے۔ اگر وہ machine compromise ہو جائے جس پر یہ key موجود ہے، تو wildcard سے cover ہونے والے تمام names ایک ہی وقت میں متاثر ہو جاتے ہیں۔
• اگر Traefik آپ کے containers کے لیے TLS (transport layer security) terminate کرتا ہے تو اس پورے عمل میں Certbot کی ضرورت نہیں: Traefik خود DNS-01 کے ذریعے wildcard certificates طلب کرتا ہے، اور اسی قسم کا provider token استعمال کرتا ہے۔

وہ صورتیں جہاں wildcard واقعی مفید ہے: فی customer یا فی app ایسے subdomains جو آپ کی جانب سے certificates دوبارہ جاری کرنے کی رفتار سے زیادہ تیزی سے بنائے جاتے ہوں، اور ایسے internal hosts جن پر public port 80 موجود نہ ہو، مثلاً وہ services جو صرف WireGuard VPN کے ذریعے قابل رسائی ہوں۔ DNS-01 اس host سے کبھی connect نہیں ہوتا جس کے لیے certificate جاری کیا جا رہا ہو، اس لیے مکمل طور پر private machine بھی public trust والا certificate رکھ سکتی ہے۔

FAQ

کیا Certbot، HTTP-01 کے ذریعے wildcard certificate جاری کر سکتا ہے؟

نہیں۔ HTTP-01 صرف ایک hostname کے کنٹرول کی تصدیق کرتا ہے، کیونکہ validation server اسی نام سے token file حاصل کرتا ہے۔ wildcard ہر subdomain نام پر لاگو ہوتا ہے، اس لیے Let's Encrypt اس کے لیے DNS-01 challenge لازم قرار دیتا ہے، جبکہ --nginx، --apache، --webroot اور --standalone authenticators سب HTTP-based ہیں۔ واحد طریقہ یہ ہے کہ _acme-challenge.example.com پر TXT record بنائی جائے، جو دستی طور پر یا DNS plugin کے ذریعے بنائی جا سکتی ہے۔

کیا wildcard certificate root domain کو بھی cover کرتا ہے؟

نہیں۔ wildcard صرف ایک label سے match کرتا ہے، اس لیے *.example.com، www.example.com کو cover کرتا ہے، لیکن bare example.com کو نہیں، اور a.b.example.com کو بھی نہیں۔ -d example.com -d '*.example.com' کے ذریعے دونوں نام ایک certificate میں request کریں۔ اس سے دو challenges بنتے ہیں، اور دونوں TXT records ایک ہی _acme-challenge.example.com نام پر رہتے ہیں؛ اس لیے پہلی record حذف کیے بغیر دوسری record شامل کریں۔

میرا wildcard certificate خودکار طور پر renew کیوں نہیں ہوتا؟

کیونکہ اسے --manual کے ساتھ جاری کیا گیا تھا۔ ہر renewal کے لیے بالکل نئی TXT value درکار ہوتی ہے، اور unattended timer کے پاس اسے شامل کرنے کا کوئی طریقہ نہیں ہوتا۔ اس لیے renewal An authentication script must be provided with --manual-auth-hook when using the manual plugin non-interactively error کے ساتھ رک جاتا ہے۔ certificate کو certbot-dns-cloudflare جیسے DNS plugin کے ساتھ دوبارہ جاری کریں، یا --manual-auth-hook اور --manual-cleanup-hook scripts فراہم کریں جو آپ کے provider کے API کے ذریعے record میں ترمیم کریں۔

_acme-challenge TXT record ظاہر ہونے میں کتنا وقت لگتا ہے؟

یہ آپ کے DNS provider پر منحصر ہے: چند seconds سے کئی minutes تک۔ Validation آپ کے zone کے authoritative servers سے data پڑھتی ہے، اس لیے dig +short TXT _acme-challenge.example.com @1.1.1.1 سے جانچ کریں اور manual run جاری رکھنے سے پہلے متوقع value ظاہر ہونے تک انتظار کریں۔ Plugin استعمال کرتے وقت، اگر validation بتائے کہ record نہیں ملی، تو plugin کے propagation option کے ذریعے built-in wait بڑھائیں، مثلاً --dns-cloudflare-propagation-seconds 60۔

کیا wildcard certificate عام certificate سے کم محفوظ ہوتا ہے؟

Cryptography یکساں ہوتی ہے۔ فرق operational ہوتا ہے: ایک private key ہر subdomain کو cover کرتی ہے، اس لیے compromise کی صورت میں اثر زیادہ وسیع ہو سکتا ہے۔ اس کے علاوہ automation کے لیے درکار DNS API credential خود ایک حساس secret ہے، جو server پر stored ہوتا ہے۔ اگر آپ صرف چند معلوم subdomains چلاتے ہیں تو SAN certificate دونوں خدشات سے بچاتا ہے۔ اسی صورت میں یہ guide wildcard استعمال نہ کرنے کی سفارش کرتی ہے۔