Certbot wildcard certificate DNS-01 طریقہ کار

Wildcard certificate کے لیے DNS-01 کیوں ضروری ہے

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

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

یہ ہمارے Certbot guides کا wildcard باب ہے۔ عام single-hostname certificates، web server configuration اور port 80 rules کو Certbot with nginx on Ubuntu 24.04 اور Certbot with Apache on Ubuntu 24.04 میں کور کیا گیا ہے۔

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

جب Certbot *.example.com کی درخواست کرتا ہے، تو Let's Encrypt ایک رینڈم ٹوکن کے ساتھ جواب دیتا ہے۔ Certbot اس ٹوکن کو آپ کی ACME (automatic certificate management environment) اکاؤنٹ کی (key) کے ساتھ ملا دیتا ہے، نتیجے کو SHA-256 کے ساتھ ہیش کرتا ہے، اور ایک مختصر ٹیکسٹ ویلیو تیار کرتا ہے۔ وہ ویلیو _acme-challenge.example.com پر ایک TXT ریکارڈ کے طور پر موجود ہونی چاہیے۔ اس کے بعد Let's Encrypt اپنے انفراسٹرکچر سے آپ کے ڈومین کے authoritative name servers سے معلومات حاصل کرتا ہے۔ اگر پڑھا گیا ریکارڈ مطلوبہ ویلیو کے مطابق ہو، تو اس کا مطلب ہے کہ آپ نے证明 کر دیا ہے کہ آپ اس zone کے کنٹرول میں ہیں۔ zone کا کنٹرول ہونا اس کے تحت موجود تمام ناموں کے کنٹرول کے طور پر تسلیم کیا جاتا ہے۔

زیادہ تر ناکامیوں کی دو وجوہات ہیں:

• ایک ہی سرٹیفکیٹ پر example.com اور *.example.com کی درخواست کرنے کا مطلب ہے دو الگ الگ چیلنجز، اور دونوں TXT ریکارڈز ایک ہی نام _acme-challenge.example.com پر ہوتے ہیں۔ دونوں کا ایک ہی وقت میں موجود ہونا ضروری ہے۔ دوسرا ریکارڈ شامل کرنا درست طریقہ ہے؛ پہلے ریکارڈ کو دوسرے سے بدلنے سے پہلا چیلنج فیل ہو جائے گا۔
• ویلیڈیشن آپ کے authoritative servers کو پڑھتی ہے، لیکن provider control panels کو نیا ریکارڈ ان تک پہنچانے میں ایک منٹ یا اس سے زیادہ وقت لگ سکتا ہے۔ ویلیڈیشن چلانے سے پہلے باہر سے چیک کریں:

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

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

ایک بار دستی طور پر چلا کر دیکھیں: manual mode

Manual mode میں آپ کو DNS خود ایڈٹ کرنا پڑتا ہے۔ آٹومیشن سے پہلے اس میکانزم کو سمجھنے کا یہ بہترین طریقہ ہے:

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 کے پینل میں وہ TXT record بنائیں، اوپر دیے گئے dig کمانڈ سے اس کے نظر آنے کی تصدیق کریں، اور اس کے بعد ہی Enter دبائیں۔ چونکہ یہ عمل bare domain اور wildcard دونوں کے لیے ہے، اس لیے Certertbot دو بار پرامپٹ کرے گا؛ جب تک issuance مکمل نہ ہو جائے، دونوں records کو برقرار رکھیں۔ کامیابی کے بعد یہ لائنیں ظاہر ہوں گی:

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

Manual mode خودکار طور پر renew کیوں نہیں ہو سکتا

ہر renewal ایک نیا چیلنج ہے جس میں نیا token استعمال ہوتا ہے، اس لیے TXT value ہر بار تبدیل ہو جاتی ہے۔ آج آپ نے جو record paste کیا ہے وہ 60 دنوں کے بعد بیکار ہو جائے گا۔ Certbot کا renewal timer دن میں 2 بار خودکار طریقے سے چلتا ہے، اور اس وقت کوئی نیا value paste کرنے کے لیے موجود نہیں ہوتا۔ اسی وجہ سے manually جاری کردہ certificate اس error کے ساتھ fail ہو جاتا ہے:

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 لکھ کر اس ضرورت کو پورا کر سکتے ہیں جو آپ کے DNS provider کی API کو call کرتی ہیں، لیکن اس صورت میں آپ خود سے ایک DNS plugin بنا رہے ہیں۔ Manual mode کو صرف طریقہ کار سیکھنے کے لیے، یا ایسے domain کے لیے استعمال کریں جس کا DNS ابھی automate نہیں کیا جا سکتا، اور 90 دن سے کافی پہلے ایک reminder سیٹ کر لیں، کیونکہ Let's Encrypt اب expiry emails نہیں بھیجتا۔ باقی تمام کاموں کے لیے plugin استعمال کریں۔

The plugin route: certbot-dns-cloudflare on Ubuntu 24.04

DNS plugin آپ کے DNS فراہم کنندہ کے API credentials استعمال کرتا ہے اور TXT record کے عمل کو خود مکمل کرتا ہے، یہ عمل سرٹیفکیٹ کے اجرا اور ہر تجدید (renewal) کے وقت ہوتا ہے۔ یہاں Cloudflare کی مثال دی گئی ہے کیونکہ زیادہ تر صارفین کو اسی کی ضرورت ہوتی ہے اور یہ Ubuntu میں دستیاب ہے۔

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

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

ورژن کے بارے میں ایک اہم وضاحت۔ 24.04 کے آرکائیو میں یہ plugin ورژن 2.0.0 کے ساتھ آتا ہے جبکہ Certbot 2.9.0 ہے؛ apt policy python3-certbot-dns-cloudflare آپ کا ورژن دکھاتا ہے۔ یہ فرق نقصان دہ نہیں ہے، اور scoped API tokens کام کریں گے، کیونکہ 24.04 میں موجود python3-cloudflare لائبریری ورژن 2.11.1 ہے، جو کہ plugin کے لیے درکار ورژن 2.3.1 سے زیادہ ہے۔ پرانے Ubuntu ورژن میں یہ لائبریری tokens کے لیے پرانی تھی، اسی وجہ سے انٹرنیٹ پر apt plugin کے ذریعے Global API Key استعمال کرنے کے بارے میں انتباہ ملتے ہیں۔ 24.04 میں یہ مسائل نہیں ہیں۔

Cloudflare ڈیش بورڈ میں scoped API token بنائیں، Global API Key نہیں۔ My Profile، پھر API Tokens، پھر Create Token پر جائیں، اور صرف ایک permission Zone / DNS / Edit منتخب کریں، جسے صرف آپ کے مطلوبہ zone تک محدود رکھا گیا ہو۔ اسے ایک ایسی فائل میں رکھیں جسے صرف 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

Certbot فائل کے permissions چیک کرتا ہے اور اگر فائل دوسروں کے لیے قابلِ رسائی ہو تو Unsafe permissions on credentials configuration file کے بارے میں خبردار کرتا ہے۔ اب یہ کمانڈ چلائیں:

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

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

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

24.04 آرکائیو میں صرف چند فراہم کنندگان کے plugins دستیاب ہیں، جن میں Cloudflare، Route 53، DigitalOcean اور generic RFC 2136 interface شامل ہیں۔ فہرست دیکھنے کے لیے apt search certbot-dns چلائیں۔ اگر آپ کا فراہم کنندہ فہرست میں نہیں ہے، تو ہمارا 'apt-first' مشورہ تبدیل ہو جاتا ہے: Certbot اور plugin کو snap کے ذریعے انسٹال کریں، اور پہلے سے موجود apt Certbot کو ہٹا دیں تاکہ دو 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 کے ساتھ منسلک ہوتا ہے؛ یہ apt plugin کی صلاحیتوں میں اضافہ نہیں کر سکتا، اسی لیے دونوں انسٹالیشنز کا ایک ساتھ ہونا درست نہیں ہے۔ اگر آپ کا DNS host کوئی API فراہم نہیں کرتا، تو آپ کے پاس دو ہی عملی حل ہیں: ڈومین کے DNS کو کسی ایسے فراہم کنندہ پر منتقل کریں جس کے پاس API موجود ہو، یا اپنا نام سرور (name server) چلائیں اور rfc2136 plugin کو اس کی طرف پوائنٹ کریں۔

Renewal: اسے ابھی آزمائیں، 60 دنوں بعد نہیں

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

sudo certbot renew --dry-run

اگر یہ عمل کامیاب رہتا ہے تو اس کا مطلب ہے کہ credentials درست کام کر رہے ہیں اور validation مکمل ہو گیا ہے؛ 60 دنوں بعد ہونے والا اصل renewal بھی اسی طریقے سے ہوگا۔ آج ہی یہ 2 کام مکمل کرنا ضروری ہیں۔ پہلا، disk پر موجود renewed certificate تب تک تبدیل نہیں ہوتا جب تک web server اسے reload نہ کر لے۔ اس لیے 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 ایک بہترین ٹول ہے۔ لیکن باقی تمام صورتوں کے لیے یہ غلط انتخاب ہے۔

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

wildcard کا اصل استعمال وہاں ہوتا ہے جہاں: ہر customer یا app کے لیے subdomains اتنی تیزی سے بنتے ہوں کہ آپ سرٹیفکیٹ دوبارہ جاری (reissue) نہ کر سکیں، یا وہ internal hosts ہوں جن کا public port 80 نہ ہو، جیسے کہ وہ services جو صرف a WireGuard VPN کے ذریعے دستیاب ہوں۔ DNS-01 کبھی بھی اس host سے منسلک نہیں ہوتا جس کا سرٹیفکیٹ جاری کیا جا رہا ہے، اس لیے ایک مکمل طور پر private مشین بھی publicly trusted certificate رکھ سکتی ہے۔

FAQ

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

نہیں۔ HTTP-01 صرف ایک hostname کے کنٹرول کو ثابت کرتا ہے، کیونکہ validation server اسی مخصوص نام سے ایک token file حاصل کرتا ہے۔ wildcard ڈومین کے تحت موجود ہر نام کو کور کرتا ہے، اس لیے 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 کو کور کرتا ہے؟

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

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

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

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

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

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

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