Certbot দিয়ে DNS-01 ব্যবহার করে wildcard certificate

একটি wildcard certificate-এর জন্য DNS-01 কেন প্রয়োজন

একটি wildcard certificate কোনো domain-এর প্রতিটি first-level subdomain কভার করে: *.example.com, app.example.com, blog.example.com এবং একই domain-এর অধীনে এক label গভীরতার অন্য যেকোনো নামের সঙ্গে মিলে। Let's Encrypt শুধু DNS-01 challenge-এর মাধ্যমে wildcard certificate ইস্যু করে। তাই Certbot-কে _acme-challenge.example.com-এ একটি TXT record প্রকাশ করে domain-এর DNS নিয়ন্ত্রণের প্রমাণ দিতে হয়। HTTP-01 challenge এ ক্ষেত্রে যথেষ্ট নয়, কারণ একটি token file পরিবেশন করা শুধু একটি hostname নিয়ন্ত্রণের প্রমাণ দেয়—যে hostname থেকে validation server file-টি সংগ্রহ করেছে। একটি wildcard domain-এর অধীনে সম্ভাব্য প্রতিটি নামের দাবি করে। পুরো namespace-এর পক্ষে কথা বলতে পারে এমন একমাত্র public record হলো DNS।

এই একটি শর্তই এই পৃষ্ঠার অন্য সব বিষয় নির্ধারণ করে। DNS-01 সফল করতে domain-এর zone-এ TXT record তৈরি করার সক্ষমতা থাকতে হবে। এটি হাতে করে বা DNS provider-এর API (application programming interface) ব্যবহার করে করা যায়। হাতে করার পদ্ধতি একবার কাজ করে, কিন্তু renewal-এর সময় ব্যর্থ হয়। নিচে এর নির্দিষ্ট কারণ দেখানো হয়েছে। Certbot DNS plugin-এর মাধ্যমে API পদ্ধতিতে unattended renewal করা যায়। শেষ পর্যন্ত আপনার এই setup-ই ব্যবহার করা উচিত।

এটি আমাদের Certbot guide-এর wildcard অধ্যায়। সাধারণ single-hostname certificate, web server configuration এবং port 80-এর নিয়ম Ubuntu 24.04-এ nginx সহ Certbot এবং Ubuntu 24.04-এ Apache সহ Certbot-এ আলোচনা করা হয়েছে।

_acme-challenge TXT record কীভাবে কাজ করে

Certbot যখন *.example.com-এর জন্য অনুরোধ করে, তখন Let's Encrypt একটি এলোমেলো token পাঠায়। Certbot সেই token-কে আপনার ACME (automatic certificate management environment) account key-এর সঙ্গে একত্র করে, SHA-256 দিয়ে hash করে এবং একটি সংক্ষিপ্ত text value তৈরি করে। এই value-টি _acme-challenge.example.com-এ একটি TXT record হিসেবে থাকতে হবে। এরপর Let's Encrypt নিজস্ব infrastructure থেকে আপনার domain-এর authoritative name server-গুলোতে query পাঠায়। পড়া record-টির value প্রত্যাশিত value-এর সঙ্গে মিললে আপনি প্রমাণ করেছেন যে zone-টি আপনার নিয়ন্ত্রণে আছে। Zone-এর নিয়ন্ত্রণকে তার অধীনস্থ প্রতিটি name-এর নিয়ন্ত্রণ হিসেবেও গ্রহণ করা হয়।

বেশিরভাগ ব্যর্থতার কারণ দুটি:

• একই certificate-এ example.com এবং *.example.com অনুরোধ করলে দুটি আলাদা challenge তৈরি হয়, এবং উভয় TXT record একই name, _acme-challenge.example.com-এ থাকে। উভয় record একই সময়ে থাকতে হবে। দ্বিতীয় record যোগ করা সঠিক। প্রথম record-টি দ্বিতীয়টি দিয়ে প্রতিস্থাপন করলে প্রথম challenge ব্যর্থ হয়।
• Validation আপনার authoritative server-গুলো পড়ে। কিন্তু provider control panel নতুন record সেখানে পাঠাতে এক মিনিট বা তার বেশি সময় নিতে পারে। Validation চালানোর আগে বাইরে থেকে পরীক্ষা করুন:

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

এতে Certbot যে value চেয়েছে সেটি দেখা গেলে validation সফল হতে পারে। কিছুই দেখা না গেলে অপেক্ষা করুন এবং আবার চালান।

একবার কাজ করতে দেখুন: manual mode

manual mode-এ DNS edit আপনাকেই করতে হবে। Automation করার আগে এই পদ্ধতিতে mechanism বোঝা সবচেয়ে সহজ:

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

Wildcard-কে ঘিরে থাকা quote আপনার 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 দিয়ে record-টি দৃশ্যমান কি না নিশ্চিত করুন। এরপর Enter চাপুন। এই run-এ bare domain এবং wildcard—দুটির জন্য অনুরোধ করা হয়। তাই Certbot দুইবার prompt দেখায়। Issuance শেষ না হওয়া পর্যন্ত উভয় record রেখে দিন। সফল হলে শেষে পরিচিত লাইনগুলো দেখা যাবে:

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

ম্যানুয়াল মোড নিজে থেকে renew করতে পারে না

প্রতিটি renewal-এ নতুন token-সহ নতুন challenge তৈরি হয়। তাই TXT value প্রতিবার পরিবর্তিত হয়। আজ যে record paste করেছেন, 60 দিন পরে সেটি আর কার্যকর থাকবে না। Renewal timer দিনে দুবার Certbot unattended অবস্থায় চালায়। তখন নতুন value paste করার জন্য keyboard-এর সামনে কেউ থাকে না। ফলে ম্যানুয়ালি issue করা certificate renewal-এর সময় এই নির্দিষ্ট 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 লিখে DNS provider-এর API কল করলে এই requirement পূরণ করতে পারেন। তবে তখন আপনি হাতে করে একটি DNS plugin পুনর্নির্মাণ করছেন। Flow বোঝার জন্য manual mode ব্যবহার করুন। অথবা এমন domain-এর ক্ষেত্রে সত্যিকারের একবারের কাজ হিসেবে এটি ব্যবহার করুন, যার DNS এখনো automate করা যাচ্ছে না। 90তম দিনের অনেক আগে একটি reminder সেট করুন, কারণ Let's Encrypt এখন আর expiry email পাঠায় না। অন্য সব ক্ষেত্রে plugin ব্যবহার করুন।

Ubuntu 24.04-এ plugin পদ্ধতি: certbot-dns-cloudflare

একটি DNS plugin আপনার DNS provider-এর API credential সংরক্ষণ করে এবং certificate issue করার সময় ও প্রতিটি renewal-এর সময় পুরো TXT record প্রক্রিয়া নিজেই সম্পন্ন করে। এখানে Cloudflare-কে উদাহরণ হিসেবে ব্যবহার করা হয়েছে, কারণ অধিকাংশ ব্যবহারকারীর এই provider plugin প্রয়োজন হয় এবং এটি Ubuntu-তে package হিসেবে পাওয়া যায়।

আমাদের Certbot guide-গুলো Ubuntu 24.04-এ apt package ব্যবহারের পরামর্শ দেয়। Cloudflare-এর ক্ষেত্রেও এই পরামর্শ প্রযোজ্য:

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

Version সম্পর্কে একটি গুরুত্বপূর্ণ তথ্য: 24.04 archive-এ এই plugin-এর version 2.0.0, আর এর সঙ্গে Certbot 2.9.0 থাকে; apt policy python3-certbot-dns-cloudflare আপনার version দেখায়। এই অমিলের কারণে সমস্যা হয় না। Scoped API token-ও কাজ করে, কারণ 24.04-এ ব্যবহৃত অন্তর্নিহিত python3-cloudflare library-এর version 2.11.1। Token support-এর জন্য plugin-এর প্রয়োজন 2.3.1, তাই এটি যথেষ্ট নতুন। পুরোনো Ubuntu release-গুলোতে এই library token support-এর জন্য খুব পুরোনো ছিল। অনলাইনে apt plugin Global API Key ব্যবহারে বাধ্য করে—এমন সতর্কবার্তার উৎস সেটিই। Ubuntu 24.04-এ সেই সতর্কবার্তা আর প্রযোজ্য নয়।

Cloudflare dashboard-এ Global API Key নয়, একটি scoped API token তৈরি করুন: My Profile, এরপর API Tokens, তারপর Create Token নির্বাচন করুন। শুধু Zone / DNS / Edit permission দিন এবং যে zone-এর জন্য certificate issue করছেন, token-টি শুধু সেই zone-এ সীমাবদ্ধ রাখুন। Credential-টি এমন একটি 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-টি পড়তে পারলে Certbot mode পরীক্ষা করে Unsafe permissions on credentials configuration file সম্পর্কে সতর্কবার্তা দেখায়। এখন issue করুন:

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

Plugin API-এর মাধ্যমে TXT record তৈরি করে, propagation-এর জন্য অল্প সময় অপেক্ষা করে, validation চালানোর সুযোগ দেয়, তারপর record-গুলো আবার মুছে ফেলে। আপনার zone-এর name server পরিবর্তন গ্রহণ করতে ধীর হলে --dns-cloudflare-propagation-seconds 60 দিয়ে অপেক্ষার সময় বাড়ান। Certificate /etc/letsencrypt/live/example.com/-এ তৈরি হবে। এরপর base guide-এ দেখানো পদ্ধতি অনুযায়ী nginx বা Apache-কে fullchain.pem এবং privkey.pem ব্যবহার করতে configure করুন। Deploy hook-ও একইভাবে যুক্ত করুন।

আপনার provider-এর plugin যদি apt-এ না থাকে

24.04 archive-এ অল্প কয়েকটি provider-এর plugin package করা আছে। এর মধ্যে Cloudflare, Route 53, DigitalOcean এবং generic RFC 2136 interface রয়েছে। তালিকা দেখতে apt search certbot-dns চালান। আপনার provider তালিকায় না থাকলে, এই ক্ষেত্রেই আমাদের apt-first পরামর্শে ব্যতিক্রম আছে: পরিবর্তে snap থেকে Certbot ও plugin ইনস্টল করুন। আগে apt-এর Certbot সরিয়ে ফেলুন, যাতে দুটি renewal timer কখনোই /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-এর Certbot-এ plugin যোগ করতে পারে না। তাই দুটি installation একসঙ্গে রাখা যাবে না। আপনার DNS host কোনো API না দিলে বাস্তবসম্মত বিকল্প দুটি: এমন provider-এ domain-এর DNS সরিয়ে নেওয়া যেখানে API আছে, অথবা নিজস্ব name server চালিয়ে rfc2136 plugin-কে সেটির দিকে নির্দেশ করা।

নবায়ন: 60 দিন পরে নয়, এখনই পরীক্ষা করুন

Certbot প্রতিটি certificate কীভাবে জারি করা হয়েছে, তা /etc/letsencrypt/renewal/example.com.conf-এ সংরক্ষণ করে। এর মধ্যে authenticator = dns-cloudflare এবং credentials path-ও থাকে। তাই প্রতিদিন দুবার চলা standard timer আপনার হস্তক্ষেপ ছাড়াই certificate নবায়ন করে। staging environment ব্যবহার করে পুরো প্রক্রিয়াটি অনুশীলন করুন:

sudo certbot renew --dry-run

পরীক্ষা সফল হওয়ার অর্থ হলো credential কাজ করছে এবং শুরু থেকে শেষ পর্যন্ত validation সম্পন্ন হচ্ছে। 60 দিন পরে প্রকৃত renewal একই প্রক্রিয়া অনুসরণ করবে। আজই আরও দুটি কাজ করা উচিত। প্রথমত, disk-এ renewed certificate এলেও web server reload না করা পর্যন্ত কোনো পরিবর্তন কার্যকর হয় না। তাই nginx এবং Apache guide-এ বর্ণিত deploy hook সংযুক্ত করুন। দ্বিতীয়ত, credentials file-টি অত্যন্ত সতর্কতার সঙ্গে সুরক্ষিত রাখুন। যে কেউ এটি পড়তে পারলে আপনার DNS zone সম্পাদনা করতে পারবে। এর মাধ্যমে তারা আপনার mail redirect করতে পারে অথবা নিজেদের DNS-01 challenge সম্পন্ন করতে পারে। ফাইলটির mode 600 রাখুন এবং এটিকে /root-এর অধীনে সংরক্ষণ করুন। Token-এর scope একটি zone-এ সীমাবদ্ধ রাখুন। কখনও credential ফাঁস হয়েছে বলে সন্দেহ হলে তা rotate করুন।

যখন wildcard প্রয়োজন হয় না

অনেক subdomain বা আগে থেকে নির্ধারণ করা যায় না এমন subdomain-এর জন্য wildcard উপযুক্ত। তবে অন্য সব ক্ষেত্রে এটিকে ডিফল্ট পছন্দ করা ঠিক নয়।

• একটি subdomain বা অল্প কয়েকটি নির্দিষ্ট subdomain থাকলে সাধারণ SAN (subject alternative name) certificate বেশি সরল। certbot --nginx -d example.com -d www.example.com -d app.example.com plain HTTP-01 ব্যবহার করে সর্বোচ্চ 100টি নাম কভার করে, এবং কোনো DNS API credential-ই server-এ সংরক্ষিত থাকে না।
• একটি wildcard ঠিক একটি label কভার করে। *.example.com bare example.com কভার করে না। তাই উপরের command-গুলোতে দুটিই চাওয়া হয়েছে। এটি a.b.example.com-ও কভার করে না; এর জন্য *.b.example.com প্রয়োজন।
• প্রতিটি subdomain-এর পেছনে একই private key থাকে। এটি থাকা machine-টি breached হলে wildcard যে সব নাম কভার করে, সেগুলো একসঙ্গে আক্রান্ত হয়।
• আপনার container-গুলোর জন্য Traefik যদি TLS (transport layer security) termination করে, তাহলে Certbot একেবারেই প্রয়োজন নেই: Traefik নিজেই DNS-01 ব্যবহার করে wildcard certificate-এর অনুরোধ করে, একই ধরনের provider token দিয়ে।

যেসব ক্ষেত্রে wildcard সত্যিই উপকারী: প্রতি customer বা app-এর জন্য এমন subdomain তৈরি করা, যেগুলোর সংখ্যা certificate reissue করার ইচ্ছার চেয়ে দ্রুত বাড়ে; এবং public port 80 না থাকা internal host, যেমন শুধু একটি WireGuard VPN-এর মাধ্যমে পৌঁছানো যায় এমন service। DNS-01 certificate পাওয়া host-এর সঙ্গে কখনও সংযোগ করে না। তাই সম্পূর্ণ private machine-ও public trust-যুক্ত certificate রাখতে পারে।

FAQ

HTTP-01 দিয়ে কি Certbot wildcard certificate ইস্যু করতে পারে?

না। HTTP-01 একটি hostname-এর নিয়ন্ত্রণ প্রমাণ করে, কারণ validation server ওই নির্দিষ্ট নাম থেকে একটি token file সংগ্রহ করে। wildcard পুরো domain-এর অধীনে থাকা সব নামকে কভার করে। তাই Let's Encrypt এর জন্য DNS-01 challenge প্রয়োজন, কিন্তু --nginx, --apache, --webroot এবং --standalone authenticator সবই HTTP-ভিত্তিক। একমাত্র উপায় হলো _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-এ উভয় নামের জন্য অনুরোধ করুন। এতে দুটি challenge তৈরি হবে। উভয় TXT record একই _acme-challenge.example.com নামের অধীনে থাকবে। তাই প্রথম record মুছে না দিয়ে দ্বিতীয় record যোগ করুন।

আমার wildcard certificate স্বয়ংক্রিয়ভাবে renew হয় না কেন?

কারণ এটি --manual দিয়ে ইস্যু করা হয়েছিল। প্রতিটি renewal-এর জন্য একেবারে নতুন TXT value প্রয়োজন। unattended timer সেটি paste করতে পারে না। তাই An authentication script must be provided with --manual-auth-hook when using the manual plugin non-interactively error দিয়ে renewal বন্ধ হয়ে যায়। certbot-dns-cloudflare-এর মতো একটি DNS plugin ব্যবহার করে certificate আবার ইস্যু করুন। অথবা এমন --manual-auth-hook ও --manual-cleanup-hook script দিন, যেগুলো provider-এর API ব্যবহার করে record পরিবর্তন করতে পারে।

_acme-challenge TXT record দেখা দিতে কত সময় লাগে?

এটি আপনার DNS provider-এর ওপর নির্ভর করে। কয়েক সেকেন্ড থেকে কয়েক মিনিট পর্যন্ত সময় লাগতে পারে। Validation আপনার zone-এর authoritative server পড়ে। তাই 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 কভার করে। তাই key compromise হলে প্রভাব আরও বিস্তৃত হয়। এ ছাড়া automation-এর জন্য প্রয়োজনীয় DNS API credential নিজেই একটি sensitive secret, যা server-এ সংরক্ষিত থাকে। আপনি যদি অল্প কয়েকটি পরিচিত subdomain চালান, তাহলে SAN certificate উভয় ঝুঁকি এড়ায়। এই কারণেই এই guide wildcard ব্যবহার না করার পরামর্শ দেয়।