Certbot দিয়ে Wildcard Certificate করার নিয়ম

Why a wildcard certificate needs DNS-01

A wildcard certificate covers every first-level subdomain of a domain: *.example.com matches app.example.com, blog.example.com, and any other name one label deep. Let's Encrypt issues wildcard certificates only through the DNS-01 challenge, so Certbot has to prove control of the domain's DNS by publishing a TXT record at _acme-challenge.example.com. The HTTP-01 challenge cannot qualify, because serving a token file proves control of one hostname, the one the validation server fetched the file from. A wildcard is a claim about every possible name under the domain, and the only public record that speaks for the whole namespace is DNS itself.

That one requirement decides everything else on this page. To pass DNS-01 you must be able to create TXT records in the domain's zone, either by hand or through your DNS provider's API (application programming interface). The by-hand route works once and then fails at renewal, for a concrete reason shown below. The API route, through a Certbot DNS plugin, renews unattended, and it is the setup you should end with.

This is the wildcard chapter of our Certbot guides. Ordinary single-hostname certificates, the web server configuration and the port 80 rules are covered in Certbot with nginx on Ubuntu 24.04 and Certbot with Apache on Ubuntu 24.04.

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

Certbot যখন *.example.com রিকোয়েস্ট করে, Let's Encrypt একটি র‍্যান্ডম টোকেন দিয়ে তার উত্তর দেয়। Certbot সেই টোকেনটি আপনার ACME (automatic certificate management environment) অ্যাকাউন্ট কী-এর সাথে যুক্ত করে, ফলাফলটিকে SHA-256 দিয়ে হ্যাশ করে এবং একটি ছোট টেক্সট ভ্যালু তৈরি করে। সেই ভ্যালুটি অবশ্যই _acme-challenge.example.com-এ একটি TXT রেকর্ড হিসেবে থাকতে হবে। এরপর Let's Encrypt তার নিজস্ব ইনফ্রাস্ট্রাকচার থেকে আপনার ডোমেইনের অথরিটেটিভ নেম সার্ভারগুলোকে কুয়েরি করে। যদি পড়া রেকর্ডটি প্রত্যাশিত ভ্যালুর সাথে মিলে যায়, তবে আপনি প্রমাণ করেছেন যে আপনি জোনটি নিয়ন্ত্রণ করেন; এবং জোন নিয়ন্ত্রণ করা মানে তার নিচের প্রতিটি নেম নিয়ন্ত্রণ করা হিসেবে গণ্য করা হয়।

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

• একই সার্টিফিকেটের জন্য example.com এবং *.example.com রিকোয়েস্ট করা মানে হলো দুটি আলাদা চ্যালেঞ্জ, এবং উভয় TXT রেকর্ডই একই নামে, অর্থাৎ _acme-challenge.example.com-এ থাকে। উভয় রেকর্ডকেই একই সময়ে বিদ্যমান থাকতে হবে। দ্বিতীয় রেকর্ডটি যোগ করা সঠিক পদ্ধতি; কিন্তু প্রথমটির পরিবর্তে দ্বিতীয়টি বসিয়ে দিলে প্রথম চ্যালেঞ্জটি ব্যর্থ হবে।
• ভ্যালিডেশন আপনার অথরিটেটিভ সার্ভারগুলো থেকে তথ্য পড়ে, কিন্তু প্রোভাইডারের কন্ট্রোল প্যানেল থেকে নতুন রেকর্ড সার্ভারে পৌঁছাতে এক মিনিট বা তার বেশি সময় নিতে পারে। ভ্যালিডেশন শুরু করার আগে বাইরে থেকে এটি পরীক্ষা করে নিন:

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

যখন এটি Certbot-এর চাওয়া ভ্যালুটি প্রিন্ট করবে, তখন ভ্যালিডেশন সফল হতে পারে। যদি এটি কিছু প্রিন্ট না করে, তবে কিছুক্ষণ অপেক্ষা করুন এবং পুনরায় কমান্ডটি চালান।

একবার ম্যানুয়াল মোডে পরীক্ষা করে দেখুন

ম্যানুয়াল মোডে আপনাকে নিজে DNS এডিট করতে হবে। অটোমেশন করার আগে এই প্রক্রিয়াটি বোঝার জন্য এটি সবচেয়ে ভালো পদ্ধতি:

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

ওয়াইল্ডকার্ডের চারপাশের কোটেশন মার্কস আপনার শেলকে * কে ফাইলনেম প্যাটার্ন হিসেবে গণ্য করতে বাধা দেয়। Certbot নির্দেশনাসহ থেমে যাবে:

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

আপনার DNS প্রোভাইডারের প্যানেলে সেই TXT রেকর্ডটি তৈরি করুন। উপরে দেওয়া dig কমান্ড দিয়ে নিশ্চিত করুন যে এটি দৃশ্যমান। এরপর Enter চাপুন। যেহেতু এই রানটি bare domain এবং wildcard উভয়টিই চাইছে, তাই Certbot দুবার প্রম্পট দেবে; সার্টিফিকেট ইস্যু হওয়া পর্যন্ত উভয় রেকর্ডই বজায় রাখুন। সফলভাবে সম্পন্ন হলে নিচের লাইনগুলো দেখতে পাবেন:

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 দিনে দুবার unattended ভাবে renewal timer চালায়, কিন্তু নতুন value paste করার জন্য কেউ কিবোর্ডের সামনে থাকে না। তাই manually ইস্যু করা certificate এই error টি দিয়ে renewal এ ব্যর্থ হয়:

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.')

আপনি আপনার DNS provider-এর API কল করার জন্য --manual-auth-hook script লিখে এই requirement পূরণ করতে পারেন, কিন্তু সেক্ষেত্রে আপনি হাতে একটি DNS plugin তৈরি করছেন। flow শেখার জন্য অথবা যে domain-এর DNS আপনি এখনও automate করতে পারছেন না তার জন্য একবারের ব্যবহারের জন্য manual mode ব্যবহার করুন। Let's Encrypt এখন আর expiry email পাঠায় না, তাই ৯০ দিন শেষ হওয়ার অনেক আগেই একটি reminder সেট করে রাখুন। অন্য সব ক্ষেত্রে, একটি plugin ব্যবহার করুন।

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

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

আমাদের Certbot গাইডগুলোতে Ubuntu 24.04-এর জন্য apt packages ব্যবহারের পরামর্শ দেওয়া হয়েছে, যা Cloudflare-এর ক্ষেত্রেও প্রযোজ্য:

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

ভার্সন সম্পর্কে একটি তথ্য। 24.04 archive-এ Certbot 2.9.0-এর সাথে এই plugin-টি version 2.0.0 হিসেবে থাকে; apt policy python3-certbot-dns-cloudflare আপনার ভার্সনটি দেখাবে। এই ভার্সনের অমিলটি ক্ষতিকারক নয় এবং scoped API tokens কাজ করবে, কারণ 24.04-এ underlying python3-cloudflare library হলো 2.11.1, যা token support-এর জন্য প্রয়োজনীয় 2.3.1 ভার্সনের চেয়ে বেশি। পুরনো Ubuntu release-গুলোতে এই library-টি token-এর জন্য অনেক পুরনো ছিল, যার কারণে অনলাইনে apt plugin ব্যবহারের সময় Global API Key ব্যবহার করতে বাধ্য করার বিষয়ে সতর্কতা দেখা যায়। 24.04-এ এই সমস্যা আর নেই।

Cloudflare dashboard-এ একটি scoped API token তৈরি করুন, Global API Key নয়: My Profile, তারপর API Tokens, তারপর Create Token, যেখানে শুধুমাত্র Zone / DNS / Edit permission থাকবে এবং এটি শুধুমাত্র আপনার নির্দিষ্ট 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 ফাইলের mode চেক করে এবং ফাইলটি অন্য কেউ পড়তে পারলে 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 তৈরি করে, কিছু সময়ের জন্য propagation delay অপেক্ষা করে, validation সম্পন্ন হতে দেয় এবং তারপর পুনরায় record-গুলো মুছে ফেলে। যদি আপনার zone-এর name servers পরিবর্তন গ্রহণ করতে দেরি করে, তবে --dns-cloudflare-propagation-seconds 60 ব্যবহার করে wait সময় বাড়িয়ে দিন। Certificate-টি /etc/letsencrypt/live/example.com/-এ জমা হবে, এবং আপনি nginx বা Apache-কে base guides-এ দেখানো পদ্ধতি অনুযায়ী ঠিক fullchain.pem এবং privkey.pem-এ নির্দেশিত করবেন, deploy hook সহ।

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

24.04 archive-এ শুধুমাত্র অল্প কিছু provider-এর plugin প্যাকেজ হিসেবে দেওয়া আছে। এর মধ্যে 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 version-টিকে extend করতে পারে না। এই কারণেই দুটি install একসাথে রাখা যাবে না। আর যদি আপনার DNS host কোনো API প্রদান না করে, তবে আপনার বাস্তবসম্মত বিকল্প হলো ডোমেইনের DNS এমন একটি provider-এ সরিয়ে নেওয়া যার API আছে, অথবা নিজের name server চালানো এবং rfc2136 plugin-টিকে সেটির দিকে পয়েন্ট করা।

Renewal: ৬০ দিন পর নয়, এখনই পরীক্ষা করুন

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

sudo certbot renew --dry-run

যদি পরীক্ষাটি সফল হয়, তবে এর অর্থ হলো credential সঠিকভাবে কাজ করছে এবং validation সম্পূর্ণ হয়েছে; ৬০ দিন পর আসল renewal প্রক্রিয়াটিও একইভাবে সম্পন্ন হবে। আজই নিচের দুটি পদক্ষেপ নেওয়া উচিত। প্রথমত, ডিস্কে রিনিউ করা সার্টিফিকেটটি web server রিলোড না করা পর্যন্ত কোনো পরিবর্তন আনে না; তাই nginx এবং Apache গাইডে বর্ণিত deploy hook টি সেটআপ করুন। দ্বিতীয়ত, credentials file-এর নিরাপত্তার দিকে নজর দিন: যে কেউ এটি পড়তে পারলে আপনার DNS zone এডিট করতে পারবে, যা আপনার mail redirect করা বা নিজস্ব DNS-01 challenges পাস করার জন্য যথেষ্ট। ফাইলটি /root-এর অধীনে mode 600 হিসেবে রাখুন, token-টি শুধুমাত্র একটি zone-এর জন্য সীমাবদ্ধ রাখুন এবং কোনো লিক হওয়ার সন্দেহ হলে এটি rotate করুন।

যখন আপনার wildcard প্রয়োজন নেই

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

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

যেখানে wildcard সত্যিই কার্যকর: গ্রাহক বা অ্যাপ অনুযায়ী তৈরি হওয়া subdomain গুলো যা দ্রুত তৈরি করা হয় এবং সার্টিফিকেট রিলোড করার সময় থাকে না, এবং এমন internal host যেগুলোর কোনো public port 80 নেই, যেমন a WireGuard VPN এর মাধ্যমে কানেক্ট করা যায় এমন services। DNS-01 কখনোই যে host-এর জন্য certificate ইস্যু করা হচ্ছে তার সাথে কানেক্ট হয় না, তাই একটি সম্পূর্ণ private machine-এও publicly trusted certificate রাখা সম্ভব।

FAQ

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

না। HTTP-01 শুধুমাত্র একটি hostname-এর নিয়ন্ত্রণ প্রমাণ করে, কারণ validation server সরাসরি সেই নামটি থেকেই একটি token file সংগ্রহ করে। Wildcard ডোমেইনের অধীনে থাকা প্রতিটি নামকে কভার করে, তাই 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' ব্যবহার করে একটি সার্টিফিকেটেই উভয় নাম রিকোয়েস্ট করুন। এতে দুটি challenge তৈরি হবে এবং উভয় TXT record একই _acme-challenge.example.com নামে থাকবে, তাই প্রথমটি ডিলিট না করে দ্বিতীয়টি যোগ করুন।

আমার wildcard certificate কেন অটোমেটিক রিনিউ হয় না?

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

_acme-challenge TXT record দৃশ্যমান হতে কত সময় লাগে?

এটি আপনার DNS provider-এর ওপর নির্ভর করে: কয়েক সেকেন্ড থেকে কয়েক মিনিট পর্যন্ত হতে পারে। Validation আপনার zone-এর authoritative server গুলো থেকে তথ্য পড়ে, তাই ম্যানুয়ালি রান করার আগে dig +short TXT _acme-challenge.example.com @1.1.1.1 দিয়ে চেক করুন এবং প্রত্যাশিত value না আসা পর্যন্ত অপেক্ষা করুন। যদি validation জানায় যে রেকর্ডটি পাওয়া যায়নি, তবে plugin ব্যবহার করলে plugin-এর propagation option (যেমন: --dns-cloudflare-propagation-seconds 60) এর মাধ্যমে ওয়েটিং টাইম বাড়িয়ে দিন।

Wildcard certificate কি সাধারণ সার্টিফিকেটের চেয়ে কম নিরাপদ?

ক্রিপ্টোগ্রাফি একই রকম। পার্থক্য হলো অপারেশনে: একটি private key দিয়ে সব subdomain কভার করা হয়, তাই এটি compromised হলে ক্ষতির পরিধি অনেক বেশি হয়। এছাড়া অটোমেশনের জন্য প্রয়োজনীয় DNS API credential সার্ভারে একটি সংবেদনশীল secret হিসেবে থাকে। আপনি যদি শুধুমাত্র কয়েকটি নির্দিষ্ট subdomain ব্যবহার করেন, তবে SAN certificate ব্যবহার করা ভালো। এই কারণেই এই গাইডে wildcard এড়িয়ে চলার পরামর্শ দেওয়া হয়েছে।