Ubuntu 24.04-এ nginx-এর জন্য Certbot ইনস্টল

Certbot ইনস্টল করুন: apt অথবা snap

Ubuntu 24.04-এ, sudo apt install certbot python3-certbot-nginx ব্যবহার করে আপনি একটি কার্যকরী Certbot পাবেন যা Let's Encrypt-এর আসল এবং পাবলিকলি ট্রাস্টেড সার্টিফিকেট প্রদান করে। Certbot-এর অফিসিয়াল ডকুমেন্টেশন snap ব্যবহারের পরামর্শ দেয়; এদের মধ্যে পার্থক্য খুবই সামান্য — snap সরাসরি আপস্ট্রিম রিলিজ অনুসরণ করে, আর আর্কাইভ প্যাকেজটি LTS-এর সাথে আসা ভার্সনটি অনুসরণ করে এবং সিকিউরিটি ফিক্স পায়।

যেকোনো একটি বেছে নিন। Certbot-এর দুটি কপি থাকলে একই /etc/letsencrypt ট্রি-তে দুটি রিনিউয়াল টাইমার কাজ করবে, যার ফলে আপনি ভুলে যাওয়া টাইমারটি সমস্যা তৈরি করতে পারে।

apt পদ্ধতি:

sudo apt update
sudo apt install certbot python3-certbot-nginx

এটি /usr/bin/certbot, nginx প্লাগইন, একটি certbot.service + certbot.timer জোড়া এবং একটি /etc/cron.d/certbot এন্ট্রি ইনস্টল করে যা systemd-এর অধীনে কোনো কাজ করে না।

snap পদ্ধতি:

sudo apt remove certbot python3-certbot-nginx
sudo snap install core && sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

snap এর নিজস্ব টাইমার, snap.certbot.renew.timer, সাথে নিয়ে আসে। snap ইনস্টল করার আগে apt প্যাকেজটি রিমুভ করে দিন।

পরবর্তীতে উভয় ইনস্টলেশন একইভাবে কাজ করে। Certbot 2.x ডিফল্টভাবে ECDSA (P-256) কী ব্যবহার করে — যদি কোনো ক্লায়েন্ট ECDSA সাপোর্ট না করে, তবে শুধুমাত্র তখনই --key-type rsa ব্যবহার করুন। সমস্ত স্টেট /etc/letsencrypt-এর অধীনে থাকে: archive/ আসল কী এবং সার্টিফিকেট ফাইলগুলো ধারণ করে, live/ বর্তমান ফাইলগুলোর জন্য symlink হিসেবে কাজ করে, renewal/ প্রতিটি সার্টিফিকেটের জন্য একটি কনফিগ ফাইল এবং accounts/ আপনার ACME অ্যাকাউন্ট কী।

HTTP-01 আসলে কী করে এবং কেন port 80 অপশনাল নয়

HTTP-01 challenge হলো একটি callback। আপনি Let's Encrypt-এর কাছে example.com এর জন্য একটি certificate চান; এটি public DNS-এ নামটি resolve করে, প্রাপ্ত ঠিকানায় port 80-এ একটি connection খোলে এবং http://example.com/.well-known/acme-challenge/<token> রিকোয়েস্ট করে। আপনার server-টি Certbot মাত্র যে token content-টি disk-এ লিখেছে, ঠিক সেটিই প্রদান করে। এটাই পুরো প্রক্রিয়া। এর ফলে তিনটি ফলাফল দেখা দেয়, যা বেশিরভাগ failed issuance-এর কারণ।

• Port 80 অবশ্যই public internet থেকে reachable হতে হবে, শুধুমাত্র আপনার laptop থেকে নয়। একটি ufw rule, cloud-provider security group, অথবা VPS-console firewall যা শুধুমাত্র 443 ওপেন করে, তা issuance এবং এর পরবর্তী প্রতিটি renewal নষ্ট করে দেয়।
• DNS অবশ্যই ইতিমধ্যে এই box-টির দিকে পয়েন্ট করা থাকতে হবে। validation server বাইরে থেকে নিজস্ব lookup করে; আপনার /etc/hosts entry এবং browser cache এর কাছে কোনো গুরুত্ব রাখে না।
• আপনি যদি AAAA record পাবলিশ করেন, তবে IPv6 প্রথমে চেষ্টা করা হবে। IPv6 connection সম্পূর্ণ ব্যর্থ হলে Let's Encrypt IPv4 দিয়ে পুনরায় চেষ্টা করে — কিন্তু একটি stale AAAA যা এমন একটি host-এর দিকে পয়েন্ট করা যা connection গ্রহণ করে এবং অন্য কিছু সার্ভ করে, তা আপনাকে একটি hard failure দেবে।

Redirects অনুমোদিত: validation একটি HTTP redirect অনুসরণ করে HTTPS-এ এবং অন্য প্রান্তে certificate অনুপস্থিত, expired বা self-signed কি না তা নিয়ে এটি কোনো গুরুত্ব দেয় না। তবে এটি port 80 ছাড়া অন্য কোনো port থেকে শুরু হবে না। Certbot-এ TLS-ALPN-01 implementation নেই, তাই "শুধু 443 ব্যবহার করুন" কোনো সমাধান নয়।

একটি authenticator নির্বাচন করা: --nginx, --webroot, --standalone

যদি nginx ইতিমধ্যে চলমান থাকে এবং ইতিমধ্যে domain সার্ভ করছে, তবে --nginx ব্যবহার করা সঠিক ডিফল্ট। Certbot আপনার config ফাইলটি বিশ্লেষণ করে, একটি সাময়িক challenge location যুক্ত করে, nginx রিলোড করে, ভ্যালিডেশন সম্পন্ন করে এবং তারপর আপনার server block-এ TLS directives লিখে দেয়। এতে কোনো downtime হয় না।

sudo certbot --nginx -d example.com -d www.example.com

নতুন সার্ভারের জন্য স্ক্রিপ্টেড পদ্ধতি:

sudo certbot --nginx \
  -d example.com -d www.example.com \
  --agree-tos -m ops@example.com --no-eff-email \
  --redirect --non-interactive

আপনি যদি nginx config-এর সাথে Certbot ব্যবহার করতে না চান, তবে --webroot সঠিক বিকল্প — যেমন আপনি যদি template থেকে config তৈরি করেন, সেটি git-এ রাখেন বা Ansible দিয়ে পুশ করেন। Certbot শুধুমাত্র challenge ফাইলটি আপনার নির্ধারিত directory-তে লিখে দেয় যা আপনি ইতিমধ্যে সার্ভ করছেন।

sudo certbot certonly --webroot -w /var/www/example.com \
  -d example.com -d www.example.com \
  --deploy-hook "systemctl reload nginx"

যদি port 80-এ কোনো সার্ভিস না চলে, তবে --standalone সঠিক বিকল্প: যেমন একটি mail server, শুধুমাত্র 443 পোর্টে চলা কোনো API, অথবা nginx চালু হওয়ার আগের কোনো first-boot script। Certbot কয়েক সেকেন্ডের জন্য নিজেই port 80 bind করে। যদি nginx ইতিমধ্যে চলমান থাকে, তবে এটি ব্যর্থ হবে — তাই চালানোর সময় nginx বন্ধ রাখুন:

sudo certbot certonly --standalone -d mail.example.com \
  --pre-hook "systemctl stop nginx" \
  --post-hook "systemctl start nginx"

এই hook গুলো সার্টিফিকেটের renewal config-এ সংরক্ষিত থাকে, তাই renewal-এর সময় এগুলো স্বয়ংক্রিয়ভাবে কাজ করে।

সার্টিফিকেট থাকার আগে এবং পরে কাজ করে এমন একটি server block

chicken-and-egg সমস্যা: nginx শুরু হতে অস্বীকার করে কারণ ssl_certificate এমন একটি ফাইলের দিকে নির্দেশ করছে যা বিদ্যমান নেই, আবার nginx বন্ধ থাকায় Certbot ভ্যালিডেশন করতে পারে না। প্রথমে port 80-এ সাইটটি চালু করুন।

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    root /var/www/example.com;
    index index.html;

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/example.com;
        default_type "text/plain";
        try_files $uri =404;
    }

    location / {
        try_files $uri $uri/ =404;
    }
}

sudo nginx -t && sudo systemctl reload nginx চালান, outside দ্য বক্স থেকে curl -I http://example.com/ উত্তরটি নিশ্চিত করুন, তারপর ইস্যু করুন। এরপর:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/example.com;
        default_type "text/plain";
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    root /var/www/example.com;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

ACME location-এ ^~ প্রিফিক্সটি অত্যন্ত গুরুত্বপূর্ণ: এটি return 301 ব্লকটিকে challenge request গ্রহণ করা থেকে বিরত রাখে। port 80-এ ওই location-টি রাখা মানে হলো সাইটের বাকি অংশ HTTPS-only হয়ে গেলেও রিনিউয়াল কাজ করতে থাকবে।

HTTP/2 সিনট্যাক্স আপনার nginx ভার্সনের ওপর নির্ভর করে, এবং দুটি ফরম্যাট মিলিয়ে লিখলে startup error তৈরি হয়। Ubuntu 24.04-এ nginx 1.24 থাকে, যা inline ফরম্যাট চায় — listen 443 ssl http2;। Debian 13-এ নতুন nginx থাকে, যা আলাদা http2 on; ডিরেক্টিভ চায়। প্রথমে nginx -v চেক করুন।

nginx-কে live/-এর দিকে নির্দেশ করুন, কখনো archive/-এর দিকে নয়। প্রতিটি রিনিউয়ালের সময় live/ symlink গুলো পরিবর্তন করা হয়; archive/-এ একটি hard path ব্যবহার করলে আপনি একটি নির্দিষ্ট সার্টিফিকেটে আটকে থাকবেন যা মেয়াদোত্তীর্ণ হয়ে যাবে।

Wildcards মানে DNS-01, এবং DNS-01 মানে একটি plugin

একটি wildcard certificate (*.example.com) HTTP-01 এর মাধ্যমে validate করা সম্ভব নয় — কারণ ফাইলটি fetch করার জন্য কোনো নির্দিষ্ট hostname নেই। DNS-01 হলো একমাত্র উপায়: একটি _acme-challenge.example.com TXT record পাবলিশ করার মাধ্যমে আপনি মালিকানা প্রমাণ করতে পারেন। Certbot কে এই কাজটি স্বয়ংক্রিয়ভাবে করার জন্য আপনার DNS provider-এর API credentials প্রয়োজন হয়, আর এই কারণেই provider plugins গুলো তৈরি করা হয়েছে। The full wildcard certificate walkthrough এ TXT record এর কার্যপদ্ধতি এবং manual mode-এ renewal সংক্রান্ত সমস্যা নিয়ে আলোচনা করা হয়েছে; এরপর Cloudflare এর সংক্ষিপ্ত সংস্করণটি দেওয়া হলো।

sudo snap set certbot trust-plugin-with-root=ok
sudo snap install certbot-dns-cloudflare

sudo apt install python3-certbot-dns-cloudflare প্যাকেজ ব্যবহার করলে পদ্ধতিটি ভিন্ন। Credentials গুলো শুধুমাত্র root ব্যবহারকারী পড়তে পারে এমন একটি ফাইলে রাখতে হয়:

# /root/.secrets/cloudflare.ini
# then: sudo chmod 600 /root/.secrets/cloudflare.ini
dns_cloudflare_api_token = your_scoped_token_here

Token-টির অনুমতি শুধুমাত্র ওই নির্দিষ্ট zone-এর DNS-edit করার জন্য সীমাবদ্ধ রাখুন। এটি আপনার DNS-এর একটি চাবিকাঠি; একে চাবিকাঠির মতোই সাবধানে ব্যবহার করুন।

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

Wildcard-টি quote দিয়ে লিখুন যাতে আপনার shell এটি glob না করে। DNS-01 সেই সমস্যাও সমাধান করে যা HTTP-01 পারে না: যেসব host-এ কোনো public port 80 নেই তাদের জন্য certificate প্রদান করা — যেমন কোনো internal service, self-hosted WireGuard VPN on a VPS এর মাধ্যমে কানেক্ট করা কোনো ডিভাইস, অথবা একটি private interface-এ থাকা admin panel।

Renewal: 90 দিন, টাইমার এবং deploy hook

Let's Encrypt সার্টিফিকেট 90 দিনের জন্য বৈধ থাকে। Certbot তখনই renewal শুরু করে যখন ৩০ দিনের কম সময় বাকি থাকে। এর ফলে আপনি ৩০ দিনের একটি সময়সীমা পান, যেখানে renewal ব্যর্থ হলেও সেটি বড় কোনো outage নয়, বরং একটি ছোট সমস্যা হিসেবে সমাধান করা সম্ভব। Let's Encrypt এখন আর expiry-warning ইমেইল পাঠায় না — তাই মনিটরিং করার দায়িত্ব এখন আপনার।

আপনার ইনস্টলেশন থেকে আসা টাইমারটি পরীক্ষা করুন:

systemctl list-timers 'certbot*' 'snap.certbot*'
sudo certbot certificates

certbot renew ফাইলটি /etc/letsencrypt/renewal/ এর প্রতিটি config পরীক্ষা করে, ৩০ দিনের সীমার বাইরের সবকিছু এড়িয়ে যায় এবং বাকিগুলোর জন্য মূল রান-এর flag গুলো ব্যবহার করে renewal সম্পন্ন করে। তাই প্রথম রানটি গুরুত্বপূর্ণ: কারণ সেটিই রেকর্ড করা হয়।

ডিস্কের ফাইলটি renew করলে নিজে থেকে কোনো পরিবর্তন হয় না — nginx মেমোরিতে থাকা পুরনো সার্টিফিকেটটিই প্রদান করতে থাকে যতক্ষণ না এটিকে reload করার নির্দেশ দেওয়া হয়। একবার একটি deploy hook সেটআপ করে নিন:

sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh >/dev/null <<'EOF'
#!/bin/sh
set -e
nginx -t && systemctl reload nginx
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

renewal-hooks/deploy/ ফোল্ডারের যেকোনো executable ফাইল সফল renewal এর পরে রান করে। --deploy-hook flag একটি সার্টিফিকেটের জন্য একই কাজ করে এবং এর renewal config-এ renew_hook = ... সংরক্ষণ করে। certbot --nginx আপনার জন্য reload করে দেয়; কিন্তু --webroot এবং --standalone সেটআপগুলো তা করে না। একটি hook না থাকার কারণেই অনেক সময় certbot certificates নতুন সার্টিফিকেট দেখায় কিন্তু সাইটটি expired সার্টিফিকেট প্রদর্শন করে। স্টার্টআপের সময় সার্টিফিকেট রিড করে এমন যেকোনো কিছুর জন্য একই hook প্রয়োজন — যেমন একটি Nextcloud VPS install with Docker, TLS and backups এর জন্য এখানে নিজস্ব restart বা reload ধাপ যুক্ত করতে হবে।

বাস্তব ক্ষেত্রে রিনিউয়াল পরীক্ষা করা

sudo certbot renew --dry-run

এটি Let's Encrypt-এর staging environment-এ সম্পূর্ণ challenge সম্পন্ন করে: একই code path, একই firewall, একই DNS ব্যবহার করা হয়। এতে কোনো rate-limit খরচ হয় না এবং ডিস্কে কিছু লেখা হয় না। আজ এটি সফলভাবে সম্পন্ন হলে, আগামী 60 দিন পর unattended renewal-ও সফল হবে, যদি না সার্ভারের কোনো সেটিংস পরিবর্তিত হয়।

একটি dry run আপনার reload hook সঠিকভাবে কাজ করছে কিনা তা প্রমাণ করে না — কারণ এটি Certbot version অনুযায়ী ভিন্ন হতে পারে। এই অংশটি হাতে পরীক্ষা করুন: সরাসরি hook script-টি চালান, নিশ্চিত করুন যে systemctl reload nginx সফল হয়েছে, এবং sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf পরীক্ষা করুন।

আপনি যে error গুলোর সম্মুখীন হবেন

Could not bind to IPv4 or IPv6. — nginx ইতিমধ্যে port 80 ব্যবহার করছে তাই --standalone হচ্ছে। --nginx অথবা --webroot ব্যবহার করুন, অথবা nginx বন্ধ করে দিন। sudo ss -lntp | grep ':80' দিয়ে নিশ্চিত করুন কোন processটি port টি ব্যবহার করছে।

Timeout during connect (likely firewall problem) — Let's Encrypt port 80-এ পৌঁছাতে পারছে না। ধাপগুলো পরীক্ষা করুন: sudo ufw status (sudo ufw allow 'Nginx Full' দিয়ে এটি open করুন), তারপর VPS provider-এর নিজস্ব firewall, এবং সবশেষে DNS। আপনার server ছাড়া অন্য কোনো জায়গা থেকে পরীক্ষা করুন: curl -sSv http://example.com/.well-known/acme-challenge/test। একটি stale AAAA record-এর কারণেও এই একই message আসতে পারে।

unauthorized :: Invalid response from http://example.com/.well-known/acme-challenge/xyz: 404 — port 80 reachable, কিন্তু token টি পাওয়া যাচ্ছে না। request টি অন্য কোনো server block-এ চলে গেছে (চেক করুন default_server কোনটির অধীনে), অথবা -w-এ দেওয়া directory টি nginx দ্বারা serve করা হচ্ছে না। /var/www/example.com/.well-known/acme-challenge/test-এ একটি file রাখুন এবং বাইরে থেকে সেটি fetch করার চেষ্টা করুন; যদি 404 error দেখায়, তবে certificate কোনো সমস্যা ছিল না।

DNS problem: NXDOMAIN looking up A for example.com — নামটি পাবলিকলি resolve হচ্ছে না। নতুন record যা এখনো propagate হয়নি, অথবা আপনার registrar দ্বারা serve করা হচ্ছে না এমন কোনো zone-এর record।

too many certificates already issued for: example.com — এটি একটি rate limit, যা বারবার debugging করার সময় দেখা যায়। Let's Encrypt duplicate certificates (একই নামের সেট) সপ্তাহে ৫ বার পর্যন্ত সীমাবদ্ধ রাখে, এবং প্রতি registered domain-এর জন্য সপ্তাহে ৫০টি নতুন certificate দেয়; সময় ছাড়া অন্য কিছু দিয়ে এগুলো সমাধান করা সম্ভব নয়। --dry-run ব্যবহার করে staging environment-এ debug করুন।

nginx: [emerg] cannot load certificate "/etc/letsencrypt/live/example.com/fullchain.pem": No such file or directory — nginx এমন একটি certificate-এর জন্য configure করা হয়েছে যা কখনো issue করা হয়নি, অথবা certbot delete দিয়ে রিমুভ করা হয়েছে। TLS server block টি comment করে দিন, nginx চালু করুন, certificate issue করুন, তারপর block টি restore করুন।

open() "/etc/letsencrypt/options-ssl-nginx.conf" failed — এই file টি nginx plugin package-এর সাথে আসে। certonly box-এ যদি python3-certbot-nginx না থাকে, তবে plugin টি যোগ করুন অথবা include line টি আপনার নিজস্ব ssl_protocols এবং ssl_ciphers settings দিয়ে পরিবর্তন করুন।

বড় পরিসরে এটি পরিচালনা করা

একটি certificate-এ সর্বোচ্চ 100টি name থাকতে পারে। একটি মাত্র certbot --nginx -d a.example.com -d b.example.com ... ব্যবহার করা সুবিধাজনক মনে হতে পারে — কিন্তু একটি stale DNS record validation-এ ব্যর্থ হলে সেই certificate-এর অন্তর্ভুক্ত অন্য সব name-ও অচল হয়ে যায়। প্রতিটি site-এর জন্য আলাদা certificate ব্যবহার করলে সেগুলো স্বাধীনভাবে কাজ করে, যা একাধিক service হোস্ট করা সার্ভারের জন্য প্রয়োজন। অনেক বেশি site থাকলে একটি ACME-aware front door ব্যবহার করা বুদ্ধিমানের কাজ: যেমন একটি Docker Compose-এর অধীনে একাধিক app চালানোর Traefik reverse proxy নিজেই certificate request এবং renew করতে পারে, ফলে Certbot-এর আর প্রয়োজন হয় না।

পুরো /etc/letsencrypt ব্যাকআপ নিন — sudo tar -czf letsencrypt-$(date +%F).tar.gz -C /etc letsencrypt symlinks সহ। এই tree-টিতে আপনার ACME account key বা accounts/ থাকে, যা আপনি হুবহু পুনরায় তৈরি করতে পারবেন না। নতুন VPS-এ স্থানান্তর করার প্রক্রিয়াটি হলো: -a ব্যবহার করে tree-টি rsync করুন, Certbot ইনস্টল করুন, DNS আপডেট করুন এবং cut over করার আগে certbot renew --dry-run চালান।

সার্ভার রিবিল্ড করলে বা নতুন LTS-এ মাইগ্রেট করলে renewal timer আপনার সাথে আসবে না। যেকোনো migration, snapshot restore, বা distro upgrade করার পর, systemctl list-timers 'certbot*' এবং একটি --dry-run চালান। এটি না করলে ৮৯ দিন পর রাত ৩টায় একটি সাইট অচল হয়ে যাবে, কারণ সবাই ধরে নিয়েছিল যে certificate-টি নিজে নিজেই renew হচ্ছে।

এই সবকিছুর জন্য একটি পাবলিক IP এবং বিশ্বজুড়ে উন্মুক্ত port 80 যুক্ত একটি machine প্রয়োজন — সহজ কথায় একটি VPS। উপরের পদ্ধতিগুলো যেকোনো VPS-এর ক্ষেত্রেই একইভাবে কাজ করে।

একই certificate ধাপগুলো nginx-এর পরিবর্তে Apache-এর ক্ষেত্রেও প্রযোজ্য, এবং যখন public certificate সম্ভব নয়, তখন Ubuntu-তে একটি self-signed certificate দিয়ে internal service চালানো যায়।

FAQ

আমার সাইট যদি শুধুমাত্র HTTPS ব্যবহার করে, তবে কি port 80 খোলা রাখা প্রয়োজন?

হ্যাঁ, HTTP-01 challenge-এর জন্য প্রয়োজন। Let's Encrypt সবসময় port 80-এ তাদের validation request শুরু করে। Certbot-এ TLS-ALPN-01 implementation নেই, তাই শুধুমাত্র 443 খোলা রাখা firewall প্রথমবার certificate ইস্যু করা এবং পরবর্তী সকল unattended renewal আটকে দেবে। port 80 থেকে HTTPS-এ redirect রাখা যাবে — validation সেটি অনুসরণ করবে। port 80 সম্পূর্ণভাবে এড়ানোর একমাত্র উপায় হলো provider plugin সহ DNS-01 ব্যবহার করা।

Ubuntu 24.04-এ nginx-এর জন্য আমি কি apt নাকি snap দিয়ে Certbot ইনস্টল করব?

apt ব্যবহার করুন। Ubuntu 24.04-এ sudo apt install certbot python3-certbot-nginx আপনাকে Certbot 2.9.0 প্রদান করে, যা এই গাইডের সকল কাজের জন্য যথেষ্ট। এটি unattended-upgrades-এর মাধ্যমে security patches পায় এবং এর জন্য snapd প্রয়োজন হয় না। শুধুমাত্র যদি আপনার অবিলম্বে একদম নতুন release অথবা শুধুমাত্র snap-এ পাওয়া যায় এমন কোনো DNS plugin প্রয়োজন হয়, তবেই snap বেছে নিন। যেকোনো একটি পদ্ধতি বেছে নিন: দুটি ইনস্টলেশন মানে একই /etc/letsencrypt tree-তে দুটি renewal timer সেট হয়ে যাবে, যার ফলে একটিটি ভুলে গেলে সমস্যা হতে পারে।

Certbot কি nginx-এর জন্য wildcard certificate ইস্যু করতে পারে?

শুধুমাত্র DNS-01-এর মাধ্যমে। *.example.com-এর মতো wildcard-এর জন্য কোনো নির্দিষ্ট hostname নেই যেখান থেকে challenge file সংগ্রহ করা যায়, তাই --nginx, --webroot এবং --standalone কোনোটিই কাজ করবে না। আপনার DNS provider-এর plugin ইনস্টল করুন, একটি root-only credentials file-এ একটি scoped API token রাখুন, এবং wildcard-টি shell globbing থেকে বাঁচাতে উদ্ধৃতি চিহ্ন দিয়ে certbot certonly --dns-cloudflare -d example.com -d '*.example.com' চালান।

সফলভাবে renewal হওয়ার পরেও nginx কেন পুরনো certificate প্রদর্শন করে?

nginx certificate-টি memory-তে রাখে এবং reload না হওয়া পর্যন্ত disk-এ থাকা নতুন ফাইলটি শনাক্ত করতে পারে না। certbot --nginx আপনার হয়ে reload করে দেয়, কিন্তু --webroot এবং --standalone রান করলে তা হয় না। ফলে renewal সফল হলেও ব্রাউজার তখনও মেয়াদোত্তীর্ণ certificate দেখতে পারে। /etc/letsencrypt/renewal-hooks/deploy/ ডিরেক্টরিতে একটি executable script রাখুন যা nginx -t && systemctl reload nginx রান করে, যাতে প্রতিটি সফল renewal-এর পরে এটি কার্যকর হয়।

certbot renew --dry-run কি নিশ্চিত করে যে renewal কাজ করবে?

বেশিরভাগ ক্ষেত্রে। এটি staging environment-এ আসল challengeটি চালায় — একই firewall, একই DNS, এবং একই code path — যেখানে কোনো rate-limit বা disk writing হয় না। তাই এটি সফল হওয়া মানে নেটওয়ার্ক সংক্রান্ত কোনো সমস্যা নেই। তবে এটি আপনার deploy hook সঠিকভাবে কাজ করছে কি না তা নিশ্চিতভাবে প্রমাণ করে না। সেটি আলাদাভাবে পরীক্ষা করুন: hook script-টি ম্যানুয়ালি চালান এবং sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf চেক করুন।