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

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

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

এই একটি শর্তই এই পৃষ্ঠার বাকি সবকিছু নির্ধারণ করে। DNS-01 সফল করতে হলে আপনাকে domain-এর zone-এ TXT record তৈরি করতে সক্ষম হতে হবে। অথবা একটি আলাদা validation zone ব্যবহার করতে হবে, যেটির দিকে _acme-challenge একটি CNAME দিয়ে নির্দেশ করে; এটি নিচে ব্যাখ্যা করা হয়েছে। 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-এর rules Ubuntu 24.04-এ Certbot সহ nginx এবং Ubuntu 24.04-এ Certbot সহ Apache-এ ব্যাখ্যা করা হয়েছে।

_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 install করুন। তার আগে 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-কে সম্প্রসারিত করতে পারে না। তাই দুটি installation একসঙ্গে রাখা যাবে না। আপনার DNS host কোনো API না দিলে তিনটি বাস্তবসম্মত বিকল্প আছে। আপনি domain-এর DNS এমন provider-এ স্থানান্তর করতে পারেন যার API আছে। আপনি নিজস্ব name server চালিয়ে rfc2136 plugin-কে সেটির দিকে নির্দেশ করতে পারেন। অথবা বর্তমান DNS host রেখে _acme-challenge.example.com থেকে এমন একটি validation zone-এ একবারের জন্য CNAME যোগ করতে পারেন যার API আছে। উদাহরণ হিসেবে hosted acme-dns service বা আপনার নিজের চালানো acme-dns server ব্যবহার করা যায়। Validation-এর সময় Let's Encrypt এই CNAME অনুসরণ করে। তাই TXT record delegated zone-এ থাকে এবং আপনার main zone-এ আর কোনো পরিবর্তন করতে হয় না।

নবায়ন: 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

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

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

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

কারণ এটি --manual ব্যবহার করে ইস্যু করা হয়েছিল। প্রতিটি renewal-এর জন্য নতুন TXT value প্রয়োজন। Unattended timer সেই value 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 আবার issue করুন। অথবা provider-এর API ব্যবহার করে record পরিবর্তন করে এমন --manual-auth-hook এবং --manual-cleanup-hook script দিন।

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