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) কী ব্যবহার করে, শুধুমাত্র এমন ক্লায়েন্টের জন্য --key-type rsa ব্যবহার করুন যা ECDSA সমর্থন করে না। সমস্ত স্টেট /etc/letsencrypt-এর অধীনে থাকে: archive/-এ প্রকৃত কী এবং সার্টিফিকেট ফাইলগুলো থাকে, live/ বর্তমান ফাইলগুলোর দিকে সিমলিঙ্ক (symlink) করে, renewal/-এ প্রতিটি সার্টিফিকেটের জন্য একটি কনফিগারেশন ফাইল থাকে এবং accounts/-এ আপনার ACME অ্যাকাউন্টের কী থাকে।

HTTP-01 আসলে কী করে এবং কেন পোর্ট 80 ঐচ্ছিক নয়

HTTP-01 চ্যালেঞ্জ হলো একটি কলব্যাক। আপনি Let's Encrypt-এর কাছে example.com কভার করে এমন একটি সার্টিফিকেটের অনুরোধ করেন; এটি পাবলিক DNS-এ নামটিকে রেজলভ করে, প্রাপ্ত ঠিকানায় port 80-এ একটি সংযোগ খোলে এবং http://example.com/.well-known/acme-challenge/<token> অনুরোধ করে। আপনার সার্ভার সেই সঠিক টোকেন কন্টেন্ট দিয়ে উত্তর দেয় যা Certbot কিছুক্ষণ আগেই ডিস্কে লিখেছে। পুরো প্রক্রিয়াটি এটাই। এর থেকে তিনটি ফলাফল আসে, যা বেশিরভাগ ব্যর্থ ইস্যুয়েন্সের কারণ।

• Port 80 অবশ্যই পাবলিক ইন্টারনেট থেকে অ্যাক্সেসযোগ্য হতে হবে, শুধু আপনার ল্যাপটপ থেকে নয়। একটি ufw রুল, ক্লাউড-প্রোভাইডার সিকিউরিটি গ্রুপ বা VPS-কনসোল ফায়ারওয়াল যা শুধুমাত্র 443 পোর্ট খোলে, তা ইস্যুয়েন্স এবং ভবিষ্যতের প্রতিটি রিনিউয়াল প্রক্রিয়াকে বাধাগ্রস্ত করে।
• DNS অবশ্যই এই বক্সে পয়েন্ট করা থাকতে হবে। ভ্যালিডেশন সার্ভার বাইরে থেকে নিজস্ব লুকআপ চালায়; আপনার /etc/hosts এন্ট্রি এবং ব্রাউজার ক্যাশে এর কাছে অর্থহীন।
• যদি আপনি একটি AAAA রেকর্ড পাবলিশ করেন, তবে IPv6 প্রথমে চেষ্টা করা হয়। IPv6 সংযোগ সরাসরি ব্যর্থ হলে Let's Encrypt IPv4-এর মাধ্যমে পুনরায় চেষ্টা করে, কিন্তু একটি পুরনো AAAA রেকর্ড যদি এমন কোনো হোস্টের দিকে নির্দেশ করে যা সংযোগ গ্রহণ করে এবং অন্য কিছু সার্ভ করে, তবে আপনি একটি হার্ড ফেইলিয়র পাবেন।

রিডাইরেক্ট অনুমোদিত: ভ্যালিডেশন প্রক্রিয়া HTTP রিডাইরেক্ট অনুসরণ করে HTTPS-এ যায় এবং অপর প্রান্তে সার্টিফিকেট নেই, মেয়াদোত্তীর্ণ বা সেলফ-সাইন করা—তা নিয়ে চিন্তা করে না। তবে এটি পোর্ট 80 ছাড়া অন্য কোথাও শুরু হবে না। Certbot-এ কোনো TLS-ALPN-01 ইমপ্লিমেন্টেশন নেই, তাই "শুধু 443 ব্যবহার করুন" কোনো বিকল্প পথ নয়।

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

--nginx হলো সঠিক ডিফল্ট অপশন যখন Nginx আগে থেকেই চলছে এবং ডোমেইনটি সার্ভ করছে। Certbot আপনার কনফিগারেশন পার্স করে, একটি সাময়িক চ্যালেঞ্জ লোকেশন ইনজেক্ট করে, Nginx রিলোড করে, ভ্যালিডেশন সম্পন্ন করে এবং তারপর TLS ডিরেক্টিভগুলো আপনার সার্ভার ব্লকে লিখে দেয়। এতে কোনো ডাউনটাইম হয় না।

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

--webroot তখন সঠিক যখন আপনি চান না যে Certbot আপনার Nginx কনফিগারেশনের আশেপাশে থাকুক। এটি এমন ক্ষেত্রে কার্যকর যখন আপনি টেমপ্লেট থেকে কনফিগারেশন তৈরি করেন, git-এ রাখেন অথবা Ansible দিয়ে পুশ করেন। Certbot শুধুমাত্র চ্যালেঞ্জ ফাইলটি আপনার সার্ভ করা একটি ডিরেক্টরিতে লিখে দেয়।

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

--standalone তখন সঠিক যখন পোর্ট 80-এ কোনো কিছু লিসেন করছে না: যেমন একটি মেইল সার্ভার, এমন একটি API যা শুধুমাত্র 443 পোর্টে কথা বলে, অথবা Nginx ইনস্টল হওয়ার আগে চালানো প্রথম বুট স্ক্রিপ্ট। Certbot নিজেই কয়েক সেকেন্ডের জন্য পোর্ট 80 বাইন্ড করে। যদি Nginx আগে থেকেই চলতে থাকে, তবে এটি ব্যর্থ হবে; তাই রান করার সময় সেটি বন্ধ রাখুন:

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

এই হুকগুলো সার্টিফিকেটের রিনিউয়াল কনফিগারেশনে রেকর্ড করা থাকে, তাই রিনিউয়ালের সময় একই স্টপ/স্টার্ট প্রক্রিয়া স্বয়ংক্রিয়ভাবে সম্পন্ন হয়।

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

মুরগি-ডিম সমস্যা: Nginx এমন কোনো ফাইলের দিকে নির্দেশ করা ssl_certificate নিয়ে চালু হতে অস্বীকার করে যা অস্তিত্বহীন, আবার Nginx বন্ধ থাকলে Certbot ভ্যালিডেশন করতে পারে না। তাই প্রথমে পোর্ট 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 চালান, নিশ্চিত করুন যে বক্সের বাইরে থেকে 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 লোকেশনের ওপর ^~ প্রিফিক্সটি তার প্রয়োজনীয়তা প্রমাণ করে: এটি return 301 ব্লকটিকে চ্যালেঞ্জ রিকোয়েস্ট গিলে ফেলা থেকে বিরত রাখে। পোর্ট 80-এ সেই লোকেশনটি বজায় রাখলে সাইটের বাকি অংশ HTTPS-only হয়ে যাওয়ার পরেও রিনিউয়াল কাজ করতে থাকে।

উপরের উভয় ব্লকই ডিস্ক থেকে ফাইল সার্ভ করে; যদি Nginx কোনো অ্যাপ্লিকেশনের সামনে থাকে, তবে location / একটি proxy_pass ব্লকে পরিণত হয় এবং রিভার্স প্রক্সি সার্ভার ব্লক, লাইন বাই লাইন সেই অ্যাপের প্রয়োজনীয় হেডারগুলো কভার করে, যেখানে ACME লোকেশন এবং TLS ডিরেক্টিভগুলো ঠিক আগের মতোই থাকে।

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

Nginx-কে live/-এর দিকে নির্দেশ করুন, কখনোই archive/-এর দিকে নয়। live/ সিমলিঙ্কগুলো প্রতিটি রিনিউয়ালের সময় নতুন করে পয়েন্ট করা হয়; archive/-এর ভেতরে কোনো হার্ড পাথ ব্যবহার করলে আপনি এমন একটি সার্টিফিকেটে আটকে যাবেন যা আপনার অজান্তেই মেয়াদোত্তীর্ণ হয়ে যাবে।

Wildcard মানেই DNS-01, আর DNS-01 মানেই একটি plugin

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

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

apt পাথের ক্ষেত্রে এটি 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 নেই, কোনো internal service, শুধুমাত্র VPS-এ self-hosted WireGuard VPN-এর মাধ্যমে পৌঁছানো যায় এমন কোনো সার্ভার, অথবা private interface-এ থাকা কোনো admin panel-এর জন্য certificate তৈরি করা।

রিনিউয়াল: 90 দিন, টাইমার এবং ডিপ্লয় হুক

Let's Encrypt সার্টিফিকেট 90 দিনের জন্য বৈধ থাকে। Certbot যখন দেখে যে মেয়াদের আর 30 দিনের কম বাকি আছে, তখন এটি রিনিউয়াল প্রক্রিয়া শুরু করে। এর ফলে আপনি 30 দিনের একটি উইন্ডো পান, যেখানে রিনিউয়াল ব্যর্থ হলেও তা ঠিক করার জন্য যথেষ্ট সময় থাকে এবং কোনো বড় ধরনের বিভ্রাট (outage) ঘটে না। Let's Encrypt এখন আর মেয়াদের শেষ হওয়ার সতর্কবার্তা ইমেইল পাঠায় না, তাই কেউ আপনাকে মনে করিয়ে দেবে না; মনিটরিংয়ের দায়িত্ব এখন আপনার।

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

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

certbot renew কমান্ডটি /etc/letsencrypt/renewal/ ডিরেক্টরির প্রতিটি কনফিগারেশন ফাইল যাচাই করে। এটি 30 দিনের উইন্ডোর বাইরের সার্টিফিকেটগুলো এড়িয়ে যায় এবং বাকিগুলো রিনিউ করে। রিনিউ করার সময় এটি ঠিক সেই ফ্ল্যাগগুলোই ব্যবহার করে যা প্রথমবার রান করার সময় দেওয়া হয়েছিল। এই কারণেই প্রথমবার রান করাটি গুরুত্বপূর্ণ: কারণ সেটিই রেকর্ড হিসেবে থেকে যায়।

ডিস্কে থাকা ফাইলটি রিনিউ করলেই নিজে থেকে কোনো পরিবর্তন হয় না। Nginx মেমোরি থেকে পুরনো সার্টিফিকেটই সার্ভ করতে থাকে যতক্ষণ না তাকে রিলোড করার নির্দেশ দেওয়া হয়। তাই একবার একটি ডিপ্লয় হুক সেট করে নিন:

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/ ডিরেক্টরির মধ্যে থাকা যেকোনো এক্সিকিউটেবল ফাইল সফল রিনিউয়ালের পরে রান করে। --deploy-hook ফ্ল্যাগটি একটি নির্দিষ্ট সার্টিফিকেটের জন্য একই কাজ করে এবং এটি renew_hook = ...-এ রিনিউয়াল কনফিগারেশনে জমা রাখে। certbot --nginx আপনার জন্য রিলোড সম্পন্ন করে; তবে --webroot এবং --standalone সেটআপগুলো তা করে না। হুক না থাকার কারণেই অনেক সময় সাইট মেয়াদোত্তীর্ণ সার্টিফিকেট সার্ভ করে, অথচ certbot certificates আনন্দের সাথে রিপোর্ট করে যে সার্টিফিকেটটি নতুন। যেসব অ্যাপ্লিকেশন স্টার্টআপের সময় সার্টিফিকেট পড়ে, তাদের সবার জন্যই একই হুকের প্রয়োজন হয়। যেমন, কন্টেইনারাইজড অ্যাপ, যেমন Docker, TLS এবং ব্যাকআপসহ Nextcloud VPS ইন্সটলেশন, সেগুলোর ক্ষেত্রেও এখানে রিস্টার্ট বা রিলোড ধাপটি যুক্ত করা প্রয়োজন।

রিনিউয়াল প্রক্রিয়া পরীক্ষা করা

sudo certbot renew --dry-run

এটি Let's Encrypt-এর স্টেজ এনভায়রনমেন্টে সম্পূর্ণ চ্যালেঞ্জটি রান করে: একই কোড পাথ, একই ফায়ারওয়াল, একই DNS, কোনো রেট-লিমিট খরচ নেই এবং ডিস্কে কোনো কিছু লেখা হয় না। যদি এটি আজ সফল হয়, তবে 60 দিন পর স্বয়ংক্রিয় রিনিউয়ালও সফল হবে, যদি সার্ভারের নিচের স্তরের কনফিগারেশনে কোনো পরিবর্তন না আসে।

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

যেসব ত্রুটির সম্মুখীন আপনি হবেন

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

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

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

DNS problem: NXDOMAIN looking up A for example.com, নামটি পাবলিকলি রিজলভ হচ্ছে না। নতুন রেকর্ড যা এখনো প্রোপাগেট হয়নি, অথবা এমন কোনো জোনের রেকর্ড যা আপনার রেজিস্টার সার্ভ করছে না।

too many certificates already issued for: example.com, একটি রেট লিমিট, যা ডিবাগিং করার সময় মানুষ প্রায়ই পেয়ে থাকে। Let's Encrypt প্রতি সপ্তাহে পাঁচটি পর্যন্ত ডুপ্লিকেট সার্টিফিকেট (একই নামের সেট) অনুমোদন করে এবং আলাদাভাবে প্রতি সপ্তাহে প্রতিটি রেজিস্টার্ড ডোমেইনের জন্য 50টি নতুন সার্টিফিকেট অনুমোদন করে; সময় পার হওয়া ছাড়া এটি খোলার আর কোনো উপায় নেই। --dry-run ব্যবহার করে staging-এর বিপরীতে ডিবাগ করুন।

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

open() "/etc/letsencrypt/options-ssl-nginx.conf" failed, এই ফাইলটি nginx প্লাগইন প্যাকেজের সাথে আসে। python3-certbot-nginx ছাড়া কোনো certonly বক্সে, হয় প্লাগইনটি যোগ করুন অথবা include লাইনটি আপনার নিজস্ব ssl_protocols এবং ssl_ciphers সেটিংস দিয়ে প্রতিস্থাপন করুন।

বড় পরিসরে ব্যবস্থাপনা

একটি সার্টিফিকেটে 100টি পর্যন্ত নাম রাখা যায় এবং একটি certbot --nginx -d a.example.com -d b.example.com ... ব্যবহার করা লোভনীয় মনে হতে পারে, কিন্তু কোনো একটি পুরনো DNS রেকর্ড ভ্যালিডেশনে ব্যর্থ হলে সার্টিফিকেটের অন্য সব নামও অকার্যকর হয়ে পড়ে। প্রতিটি সাইটের জন্য আলাদা সার্টিফিকেট ব্যবহার করলে সেগুলো স্বাধীনভাবে কাজ করে, যা একাধিক সার্ভিস হোস্ট করা সার্ভারের জন্য জরুরি। অল্প কিছু সাইটের বেশি হয়ে গেলে, একটি ACME-সচেতন ফ্রন্ট ডোর ব্যবহার করা লাভজনক: একটি Docker Compose-এর অধীনে একাধিক অ্যাপ চালানো Traefik reverse proxy নিজেই সার্টিফিকেট রিকোয়েস্ট ও রিনিউ করে, ফলে Certbot-এর আর প্রয়োজন হয় না। কোন প্রক্সিটি ফ্রন্ট ডোরে ব্যবহার করবেন তা আপনার সিদ্ধান্তের বিষয়, এবং Nginx, Caddy ও Traefik-এর মধ্যে তুলনা মূলত নির্ভর করে আপনি প্রক্সির ওপর কতটা সার্টিফিকেট ও অ্যাপ-ভিত্তিক কনফিগারেশনের দায়িত্ব দিতে চান তার ওপর।

/etc/letsencrypt-কে সম্পূর্ণভাবে ব্যাকআপ রাখুন, sudo tar -czf letsencrypt-$(date +%F).tar.gz -C /etc letsencrypt ব্যবহার করে এবং symlink অক্ষুণ্ণ রেখে। এই ডিরেক্টরিতে accounts/ থাকে, যা আপনার ACME অ্যাকাউন্ট কি (key); এটি হুবহু পুনরায় তৈরি করা সম্ভব নয়। নতুন VPS-এ স্থানান্তরের প্রক্রিয়াটি সহজ: -a ব্যবহার করে ডিরেক্টরিটি rsync করুন, Certbot ইনস্টল করুন, DNS আপডেট করুন এবং সার্ভিস চালু করার আগে certbot renew --dry-run চালান।

সার্ভার রিবিল্ড করলে বা নতুন LTS ভার্সনে গেলে রিনিউয়াল টাইমার নিজে থেকে স্থানান্তরিত হয় না। যেকোনো মাইগ্রেশন, স্ন্যাপশট রিস্টোর বা ডিস্ট্রো আপগ্রেডের পর systemctl list-timers 'certbot*' এবং একটি --dry-run চালান। এটি না করলে 89 দিন পর রাত 3টার সময় সাইট ডাউন হয়ে যেতে পারে, অথচ সবাই ধরে নিয়েছিল যে সার্টিফিকেটটি স্বয়ংক্রিয়ভাবে রিনিউ হচ্ছে।

এই পুরো প্রক্রিয়াটি এমন একটি মেশিনের জন্য প্রযোজ্য যা আপনার নিয়ন্ত্রণে আছে, যার একটি পাবলিক IP আছে এবং পোর্ট 80 ইন্টারনেটের জন্য উন্মুক্ত—অর্থাৎ একটি VPS। যেকোনো VPS-এই এই পদ্ধতিগুলো একইভাবে কাজ করে।

একই সার্টিফিকেট সংক্রান্ত ধাপগুলো Nginx-এর পরিবর্তে Apache-তে প্রযোজ্য, এবং যখন পাবলিক সার্টিফিকেট ব্যবহার করা সম্ভব হয় না, তখন Ubuntu-তে self-signed certificate অভ্যন্তরীণ সার্ভিসগুলোর জন্য কার্যকর সমাধান।

FAQ

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

হ্যাঁ, HTTP-01 চ্যালেঞ্জের জন্য এটি প্রয়োজন। Let's Encrypt সবসময় পোর্ট 80-এ তাদের ভ্যালিডেশন অনুরোধ শুরু করে। Certbot-এ TLS-ALPN-01 ইমপ্লিমেন্টেশন নেই, তাই শুধুমাত্র 443 পোর্ট খোলা থাকলে তা প্রথম ইস্যুয়েন্স এবং পরবর্তী প্রতিটি স্বয়ংক্রিয় রিনিউয়ালকে বাধাগ্রস্ত করবে। পোর্ট 80 থেকে HTTPS-এ রিডাইরেক্ট করা যেতে পারে, ভ্যালিডেশন সেই রিডাইরেক্ট অনুসরণ করবে। পোর্ট 80 পুরোপুরি এড়িয়ে যাওয়ার একমাত্র উপায় হলো DNS-01 চ্যালেঞ্জ ব্যবহার করা, যার জন্য একটি প্রোভাইডার প্লাগইন প্রয়োজন।

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

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

Certbot কি nginx-এর জন্য ওয়াইল্ডকার্ড সার্টিফিকেট ইস্যু করতে পারে?

শুধুমাত্র DNS-01 চ্যালেঞ্জের মাধ্যমে এটি সম্ভব। *.example.com-এর মতো ওয়াইল্ডকার্ডের ক্ষেত্রে চ্যালেঞ্জ ফাইলটি ফেচ করার জন্য কোনো নির্দিষ্ট হোস্টনাম থাকে না, তাই --nginx, --webroot এবং --standalone এখানে কাজ করবে না। আপনার DNS প্রোভাইডারের জন্য প্লাগইন ইনস্টল করুন, একটি রুট-অনলি ক্রেডেনশিয়াল ফাইলে স্কোপড API টোকেন রাখুন এবং certbot certonly --dns-cloudflare -d example.com -d '*.example.com' চালান। শেল যেন এটিকে গ্লোব (glob) না করে, সেজন্য ওয়াইল্ডকার্ডটিকে কোটেশনের ভেতরে রাখুন।

সফলভাবে রিনিউয়াল হওয়ার পরেও nginx কেন পুরনো সার্টিফিকেট দেখাচ্ছে?

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

certbot renew --dry-run কি প্রমাণ করে যে রিনিউয়াল কাজ করবে?

বেশিরভাগ ক্ষেত্রে হ্যাঁ। এটি স্টেজিং এনভায়রনমেন্টের বিপরীতে আসল চ্যালেঞ্জটি চালায়—একই ফায়ারওয়াল, একই DNS এবং একই কোড পাথ ব্যবহার করে। এতে কোনো রেট-লিমিট খরচ নেই এবং ডিস্কে কিছু লেখা হয় না, তাই এটি পাস হওয়া মানে নেটওয়ার্কের দিকটি ঠিক আছে। তবে এটি নিশ্চিতভাবে প্রমাণ করে না যে আপনার ডিপ্লয় হুকটি কাজ করবে। এটি আলাদাভাবে পরীক্ষা করুন: হুক স্ক্রিপ্টটি নিজে চালিয়ে দেখুন এবং sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf চেক করুন।