Ubuntu 24.04 Apache Let's Encrypt সার্টিফিকেট সেটআপ

আপনি যা তৈরি করছেন

Ubuntu 24.04-এ একটি Apache সাইট HTTPS-এ সাড়া দেবে, যেখানে একটি ফ্রি, ব্রাউজার-বিশ্বস্ত Let's Encrypt সার্টিফিকেট থাকবে — এটি Certbot দ্বারা ইস্যু করা হবে, এবং একটি systemd timer দ্বারা স্বয়ংক্রিয়ভাবে নবায়ন করা হবে যা আপনাকে আর ভাবতে হবে না। মূল কাজটি করে এমন কমান্ডটি মাত্র এক লাইনের। যে সমস্ত ভুল হতে পারে, সেগুলো সবই ওই লাইনের আগে ঘটে: ServerName ছাড়া একটি vhost, প্রোভাইডার ফায়ারওয়ালে বন্ধ থাকা port 80, পুরোনো সার্ভারের দিকে এখনও নির্দেশ করা DNS। তাই এই গাইডটি তার বেশিরভাগ সময় পূর্বশর্তগুলোর ওপর ব্যয় করে, এবং প্রতিটি ভুলের ফলে ঠিক কী এরর স্ট্রিং প্রিন্ট হয় তা উল্লেখ করে।

দুটি স্কোপ নোট। আপনার ওয়েব সার্ভার যদি nginx হয়, তাহলে প্রক্রিয়াটির ধরন একই কিন্তু প্লাগইন এবং কনফিগ আলাদা — সেক্ষেত্রে এই গাইডের nginx সংস্করণ ব্যবহার করুন। আর যদি আপনি যা নিরাপদ করছেন তা শুধু অভ্যন্তরীণ হয় — একটি প্রাইভেট ঠিকানায় অ্যাডমিন প্যানেল, এমন একটি স্টেজিং বক্স যাতে অন্য কেউ ভিজিট করে না — তাহলে আপনার কোনো সার্টিফিকেট অথরিটির দরকার নেই; একটি সেলফ-সাইনড সার্টিফিকেট কম যন্ত্রপাতি জড়িত এবং অফলাইনে কাজ করে।

পূর্বশর্ত, এবং Certbot চলার আগেই এটি ব্যর্থ হওয়ার তিনটি কারণ

• Apache ইতিমধ্যে আপনার সাইটটি সাধারণ HTTP-এ পরিবেশন করছে। Certbot-এর Apache প্লাগইন একটি বিদ্যমান সাইট সম্পাদনা করে; এটি নতুন সাইট তৈরি করে না। আপনি যদি একটি নতুন VPS থেকে শুরু করেন, তাহলে প্রথমে Ubuntu 24.04-এ LAMP স্ট্যাক তৈরি করুন এবং এখানে ফিরে আসুন — এই নির্দেশিকাটি হলো সেই গাইডের অসম্পূর্ণ TLS অধ্যায়।
• আপনার VPS ঠিকানায় একটি A রেকর্ড সহ একটি পাবলিক ডোমেইন। Let's Encrypt-এর HTTP-01 চ্যালেঞ্জের অর্থ হলো তাদের যাচাইকরণ সার্ভারগুলো ইন্টারনেট থেকে আপনার সার্ভারে সংযুক্ত হয়: পোর্ট ফরওয়ার্ড ছাড়া NATed হোমল্যাব চলবে না, .local নাম চলবে না, বেয়ার IP চলবে না। dig +short example.com অবশ্যই আপনার VPS ঠিকানা প্রদান করবে, এবং আপনি যদি গত এক ঘণ্টায় DNS পরিবর্তন করে থাকেন, তাহলে সার্টিফিকেট ইস্যু করার আগে পুরোনো রেকর্ডের TTL অপেক্ষা করুন।
• AAAA রেকর্ড বিদ্যমান থাকলে, সেটি অবশ্যই সঠিক হতে হবে। AAAA রেকর্ড প্রকাশিত হলে Let's Encrypt IPv6 পছন্দ করে, তাই একটি পুরোনো AAAA যাচাইকরণ ব্যর্থ করে দেয় এমনকি যখন আপনার ল্যাপটপ থেকে curl — সম্ভবত IPv4-এ — ঠিকঠাক কাজ করে। একটি সঠিক AAAA প্রকাশ করুন বা একেবারে প্রকাশ করবেন না।

ufw-এ এবং আপনার প্রোভাইডারের নেটওয়ার্ক ফায়ারওয়ালে 80 ও 443 পোর্ট খোলা প্রয়োজন — বেশিরভাগ হোস্টিং প্যানেলে একটি দ্বিতীয় ফায়ারওয়াল থাকে যা OS কখনো দেখতে পায় না। HTTP-01 নির্দিষ্টভাবে 80 পোর্টে যাচাই করে; আপনি এটি শুধু 443-এ চালাতে পারবেন না।

sudo ufw allow "Apache Full"
sudo ufw status

এগুলো প্রস্তুত থাকলে পুরো কাজটি পনেরো মিনিটের, এবং তার মধ্যে দশ মিনিট পড়ার।

Snap নাকি apt Certbot? 24.04-এ, অবশেষে apt গ্রহণযোগ্য

বছর আগে Certbot একটি বৈধ কারণে snap ডিস্ট্রিবিউশনে চলে গেছিল: distro প্যাকেজগুলো পুরোনো হয়ে গিয়েছিল। Ubuntu 20.04-এ Certbot 0.40 ছিল এবং তা আর কখনো আপডেট হয়নি, ফলে প্রকল্পটি পাঁচ বছরের পুরোনো বাগ ডিবাগ করতে করতে ক্লান্ত হয়ে পড়েছিল। 24.04-এ সেই কারণ আর নেই — আর্কাইভে রয়েছে Certbot 2.9.0, যা একটি বর্তমান প্রজন্মের রিলিজ, এবং unattended-upgrades এটিকে প্যাচ করে রাখে। এই OS-এর জন্য আমার সুপারিশ: apt ব্যবহার করুন। এতে আপনি snapd ডেমন এড়াতে পারবেন, Apache প্লাগইন একই লেনদেনে ইনস্টল হবে, এবং রিনিউয়াল টাইমারটি সাধারণ Debian পদ্ধতিতে systemd-এর সাথে যুক্ত হবে।

sudo apt update
sudo apt install -y certbot python3-certbot-apache
certbot --version

সঠিক ফলাফল: certbot 2.9.0। python3-certbot-apache প্যাকেজটি এমন একটি প্লাগইন যা আপনার Apache কনফিগ পড়ে এবং সম্পাদনা করে — এটি ছাড়া, certbot --apache কাজ করতে ব্যর্থ হয় এবং The requested apache plugin does not appear to be installed দেখায়।

দুটি ক্ষেত্রে snap এখনও সঠিক পছন্দ: আপনি রিলিজের দিনই সর্বনতুন Certbot চান, অথবা আপনার এমন একটি DNS প্লাগইন প্রয়োজন যা কেবল snap হিসেবেই বিতরণ করা হয় (certbot-dns-* প্রোভাইডার প্লাগইনগুলোর মধ্যে কয়েকটি এমন)। আপনি যদি সেই পথে যান:

sudo apt remove -y certbot python3-certbot-apache
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

আপনি যাই বেছে নিন না কেন, কখনোই দুটো একসাথে চালাবেন না। দুটি ইনস্টল মানে দুটি রিনিউয়াল শিডিউলার, যারা /etc/letsencrypt-এর নিয়ন্ত্রণ নিয়ে পরস্পরের সাথে দ্বন্দ্বে লিপ্ত হবে, এবং আপনার শেল PATH-এ যে certbot খুঁজে পাবে সেটি হয়তো সেই Certbot নয় যে আপনার সার্টিফিকেটগুলো নিয়ন্ত্রণ করে। উপরের apt remove লাইনটি কোনো ঐচ্ছিক সাজসজ্জা নয়।

Certbot যে vhost সম্পাদনা করে তা আগেই বিদ্যমান থাকতে হবে — ServerName-ই মূল বিষয়

certbot --apache কাজ করে এভাবে: এটি port-80 এর এমন একটি virtual host খুঁজে বের করে যার ServerName বা ServerAlias আপনার উল্লেখিত প্রতিটি -d ডোমেইনের সাথে মেলে, সেই vhost-এর মাধ্যমে ডোমেইনের নিয়ন্ত্রণ প্রমাণ করে, এবং তারপর সেই vhost-এর একটি SSL অনুরূপ তৈরি করে। মিল না থাকলে ServerName কাজ করবে না — এবং Ubuntu-এর ডিফল্ট 000-default.conf-এ ServerName কমেন্ট করা অবস্থায় থাকে। এই একটি কমেন্ট করা লাইনই এই গাইডের একটি বড় কমান্ড ব্যর্থ হওয়ার সবচেয়ে সাধারণ কারণ।

তাই Certbot নিয়ে কাজ করার আগে, সাইটটিকে একটি সঠিক name-based vhost দিন। /etc/apache2/sites-available/example.com.conf তৈরি করুন:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com
    ErrorLog ${APACHE_LOG_DIR}/example.com-error.log
    CustomLog ${APACHE_LOG_DIR}/example.com-access.log combined
</VirtualHost>

এটি সক্রিয় করুন এবং নিশ্চিত করুন যে Apache এটি পার্স করতে পারছে এবং নামটিকে এতে রাউট করছে:

sudo a2ensite example.com.conf
sudo apache2ctl configtest
sudo systemctl reload apache2
sudo apache2ctl -S

configtest অবশ্যই Syntax OK প্রিন্ট করবে। যদি এটি AH00558: apache2: Could not reliably determine the server's fully qualified domain name-ও প্রিন্ট করে, তবে সেটি global ServerName সম্পর্কিত একটি সতর্কতা, আপনার vhost-এর নয় — এখানে এটি ক্ষতিকর নয়, এবং echo "ServerName $(hostname -f)" | sudo tee /etc/apache2/conf-available/servername.conf && sudo a2enconf servername && sudo systemctl reload apache2 দিয়ে এটি নীরব করা যায়।

-S আউটপুটটিই মূল চেক। আপনি port 80 namevhost example.com (/etc/apache2/sites-enabled/example.com.conf:1)-এর মতো একটি লাইন চান যার নিচে alias www.example.com থাকবে — Apache আসলে যে sites-enabled সিমলিংকটি পড়েছে তা রিপোর্ট করে, sites-available-এ আপনি যে ফাইল সম্পাদনা করেছেন তা নয়। যদি example.com port 80-এর বিপরীতে তালিকাভুক্ত না থাকে, তবে Certbot-ও সেটি খুঁজে পাবে না।

সার্টিফিকেট ইস্যু করুন: certbot --apache

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

প্রথম চালানোর সময় তিনটি জিনিস জানতে চাওয়া হয়: একটি ইমেল ঠিকানা (আপনার ACME অ্যাকাউন্ট এবং জরুরি CA নোটিশের জন্য ব্যবহৃত হয়; Let's Encrypt আর মেয়াদ শেষ হওয়ার সতর্কতা পাঠায় না, তাই রিনিউয়াল নজরদারি আপনার দায়িত্ব), Let's Encrypt-এর শর্তাবলীতে সম্মতি, এবং আপনার ইমেল EFF-এর সাথে শেয়ার করবেন কি না। এখন আর কোনো রিডাইরেক্ট প্রশ্ন নেই: Certbot 2.0 থেকে Apache ইনস্টলার ডিফল্টভাবে HTTP থেকে HTTPS-এ রিডাইরেক্ট করে, যা আপনার প্রয়োজন। আপনার যদি সত্যিই প্লেইন HTTP-এ কন্টেন্ট পরিবেশন করতে হয়, তাহলে --no-redirect পাস করুন।

সফল হলে এরকম দেখায়, এবং আপনার এটি ভালোভাবে পড়া উচিত, শুধু চোখ বুলিয়ে দেখা উচিত নয়:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/example.com/privkey.pem
This certificate expires on 2026-10-14.

Deploying certificate
Successfully deployed certificate for example.com to /etc/apache2/sites-available/example.com-le-ssl.conf
Successfully deployed certificate for www.example.com to /etc/apache2/sites-available/example.com-le-ssl.conf
Congratulations! You have successfully enabled HTTPS on https://example.com and https://www.example.com

এই বার্তার পেছনে Certbot চারটি কাজ করেছে: Apache-এর ssl মডিউল চালু করেছে (যদি আগে থেকে চালু না থাকে), example.com-le-ssl.conf লিখেছে — আপনার vhost-এর একটি কপি *:443-এ, SSLEngine on এবং সার্টিফিকেট পাথ সহ — এটি চালু করেছে, এবং মূল port-80 vhost-এ একটি RewriteRule ব্লক যোগ করেছে যা সবকিছু 301 করে HTTPS-এ পাঠায়। আপনার মূল vhost ফাইলটি সম্পাদনা করা হয়েছে, প্রতিস্থাপন করা হয়নি, এবং SSL টুইনটি এর পাশেই রাখা হয়েছে যেখানে আপনি এটি যোগ করা প্রতিটি লাইন পড়তে পারবেন।

সার্টিফিকেট আসলে কোথায় থাকে, এবং কেন আপনি এটি কখনোই কপি করবেন না

সবকিছু /etc/letsencrypt/live/example.com/-এর অধীনে রাখা হয়: fullchain.pem (সার্টিফিকেট এবং ইন্টারমিডিয়েট চেইন — সার্ভারগুলিকে এখানেই নির্দেশ করা উচিত), privkey.pem (প্রাইভেট কী, শুধুমাত্র root-এ পঠনযোগ্য), এবং যেসফটওয়্যার এই অংশগুলি আলাদাভাবে চায় তার জন্য cert.pem ও chain.pem। এগুলি /etc/letsencrypt/archive/-এর ভেতরে সিমলিংক। এই ইন্ডিরেকশনই হলো রিনিউয়াল মেকানিজম: রিনিউয়ালের সময় archive/-এ নতুন ফাইল লেখা হয় এবং সিমলিংকগুলি পুনঃনির্দেশিত হয়। অন্য যেকোনো সফটওয়্যারকে live/ পাথে নির্দেশ করুন, আর এটি স্বয়ংক্রিয়ভাবে রিনিউয়াল পেয়ে যাবে। ফাইলগুলি অন্য কোথাও কপি করলে আপনি 90 দিন পর নিজেই একটি আউটেজ তৈরি করেছেন।

জেনে রাখার মতো আরেকটি ফাইল হলো /etc/letsencrypt/renewal/example.com.conf। এটি রেকর্ড করে যে এই সার্টিফিকেটটি কীভাবে ইস্যু করা হয়েছিল — authenticator = apache, installer = apache, ডোমেইনগুলি — যাতে রিনিউয়াল স্বয়ংক্রিয়ভাবে প্রক্রিয়াটি পুনরাবৃত্তি করতে পারে, যার মধ্যে পরে Apache রিলোড করাও অন্তর্ভুক্ত।

নবায়ন ইতিমধ্যেই নির্ধারিত — এটি যাচাই করুন, নতুন করে তৈরি করবেন না

Let's Encrypt সার্টিফিকেট ডিজাইন অনুসারে 90 দিন টিকে থাকে। apt প্যাকেজ ইতিমধ্যেই প্রয়োজনীয় ব্যবস্থা ইনস্টল করেছে: একটি systemd টাইমার যা দিনে দুবার এলোমেলো সময়ে Certbot চালায় এবং মেয়াদ শেষ হওয়ার 30 দিনের মধ্যে যেকোনো সার্টিফিকেট নবায়ন করে। এর উপর কোনো cron job যোগ করবেন না; দ্বিতীয় একটি শিডিউলার কেবল লগ বিভ্রাট এবং rate-limit ঝুঁকি বাড়ায়, আর কিছুই না।

systemctl list-timers certbot.timer
sudo certbot renew --dry-run

প্রথম কমান্ডটি দেখায় যে টাইমারটি সক্রিয় আছে, এবং আগামী 24 ঘণ্টার মধ্যে কোনো এক NEXT সময় নির্ধারিত আছে — শিডিউলটি দিনে দুবার এলোমেলো বিলম্বসহ চলে, তাই সঠিক সময়টি ইচ্ছাকৃতভাবে অনির্দিষ্ট (snap ইনস্টলেশনে টাইমারটি হলো snap.certbot.renew.timer)। dry run একটি সম্পূর্ণ নবায়ন রিহার্সাল Let's Encrypt-এর staging পরিবেশের বিরুদ্ধে সম্পন্ন করে — আসল চ্যালেঞ্জ হয়, কিন্তু কোনো সার্টিফিকেট ইস্যু হয় না এবং কোনো rate-limit খরচ হয় না। সঠিক ফলাফল এভাবে শেষ হয়:

Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/example.com/fullchain.pem (success)

dry run ব্যর্থ হলে, আনুমানিক 60 দিন পরে আসল নবায়নও একইভাবে ব্যর্থ হবে — এটি এখনই ঠিক করুন, যখন বর্তমান সার্টিফিকেটের পুরো মেয়াদ এখনও বাকি আছে। সাধারণ কারণ হলো ইস্যুর পরে যোগ করা একটি firewall নিয়ম যা port 80 আবার বন্ধ করে দিয়েছে।

curl দিয়ে যাচাই করুন, এবং প্যাডলকে কী দেখানো উচিত

curl -sI http://example.com | head -n 3
curl -I https://example.com
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -issuer -dates

প্রথমটি HTTP/1.1 301 Moved Permanently এবং একটি Location: https://example.com/ হেডার ফেরত দেবে — এটি সেই রিডাইরেক্ট যা Certbot ইনস্টল করেছে। দ্বিতীয়টি HTTP/1.1 200 OK ফেরত দেবে এবং curl থেকে কোনো TLS সম্পর্কিত অভিযোগ আসবে না। তৃতীয়টি ইস্যুয়ার প্রিন্ট করে — একটি O = Let's Encrypt লাইন, যেখানে R12 বা E7-এর মতো একটি ছোট CN থাকবে — এবং notAfter প্রায় 90 দিন পরের একটি তারিখ হবে। ব্রাউজারে আপনি প্যাডলক দেখতে পাবেন, এবং সেটিতে ক্লিক করলে একই ইস্যুয়ার দেখাবে। যদি curl কাজ করে কিন্তু ব্রাউজার সতর্কতা দেখায়, তবে আপনি সম্ভবত একটি ক্যাশ করা পেজ বা ভুল হোস্টনাম দেখছেন, সার্টিফিকেটে কোনো সমস্যা নেই।

একাধিক সাইট: একটি SAN সার্টিফিকেট নাকি প্রতিটি সাইটের জন্য আলাদা সার্টিফিকেট

দুটিই কাজ করে। দুটির রিনিউয়াল পদ্ধতিও একই। একই সার্ভারে আলাদা সাইট থাকলে, প্রতিটির জন্য আলাদা করে issue কমান্ড চালান। প্রতিটি সাইট live/-এর অধীনে নিজস্ব ডিরেক্টরি এবং নিজস্ব রিনিউয়াল কনফিগ পাবে। একটি ডোমেইনে সমস্যা হলে বাকিগুলোর রিনিউয়াল বাধাগ্রস্ত হবে না। এটিই আমার ডিফল্ট পছন্দ।

একটি সাইটের একাধিক নাম থাকলে, সেগুলো একটি SAN সার্টিফিকেটে রাখুন। একটি সার্টিফিকেটে সর্বোচ্চ 100টি নাম রাখা যায়। আপনি উপরে ইতিমধ্যেই example.com এবং www.example.com দিয়ে এটি করেছেন। পরে কোনো বিদ্যমান সার্টিফিকেটে নতুন নাম যোগ করতে, সার্টিফিকেটটির নাম এবং সম্পূর্ণ নতুন তালিকা উল্লেখ করে পুনরায় issue করুন:

sudo certbot --apache --cert-name example.com -d example.com -d www.example.com -d blog.example.com

Certbot পরিবর্তিত ডোমেইন তালিকা শনাক্ত করবে। এটি আপনাকে সম্প্রসারণ নিশ্চিত করতে বলবে এবং সার্টিফিকেটটি সেখানেই প্রতিস্থাপন করবে। পথ একই থাকবে — live/, তাই অন্য কিছু পরিবর্তন করতে হবে না। মনে রাখবেন, এই তালিকাটি একটি প্রতিস্থাপন, যোগ নয়। সেই কমান্ড থেকে www বাদ দিলে নতুন সার্টিফিকেটটি নীরবে এটিকে বাদ দেবে।

ওয়াইল্ডকার্ডের জন্য DNS-01 প্রয়োজন, এবং সাধারণত আপনার কোনো ওয়াইল্ডকার্ডের দরকার হয় না

HTTP-01 দ্বারা *.example.com ইস্যু করা যায় না — ওয়েব সার্ভারে একটি ফাইল রাখলে একটি নির্দিষ্ট hostname-এর নিয়ন্ত্রণ প্রমাণিত হয়, পুরো namespace-এর নয়। ওয়াইল্ডকার্ডের জন্য DNS-01 চ্যালেঞ্জ প্রয়োজন: Certbot এ _acme-challenge.example.com-এ একটি TXT রেকর্ড সেট করে। বাস্তবে এর অর্থ হলো আপনার DNS প্রোভাইডারের জন্য API ক্রেডেনশিয়াল সহ একটি certbot-dns-* প্লাগইন, অথবা প্রতিবার নবায়নের সময় --manual দিয়ে TXT রেকর্ড নিজে হাতে এডিট করা (অত্যন্ত কষ্টকর — এটির ওপর নির্ভর করে পরিকল্পনা করবেন না)। TXT রেকর্ডের প্রক্রিয়া থেকে শুরু করে স্বয়ংক্রিয়ভাবে নবায়ন করতে সক্ষম একটি প্লাগইন পর্যন্ত সম্পূর্ণ প্রক্রিয়া DNS-01 এর মাধ্যমে Certbot দিয়ে ওয়াইল্ডকার্ড সার্টিফিকেট নামক নির্দেশিকায় দেওয়া আছে। সৎ পরামর্শ: আপনার যদি চারটি নির্দিষ্ট সাবডোমেইন থাকে, তবে চারটিকে অন্তর্ভুক্ত করে একটি SAN সার্টিফিকেট তৈরি করা একটি ওয়াইল্ডকার্ডের চেয়ে সহজ, এবং এতে সার্ভারে কোনো DNS API কী রাখার প্রয়োজন হয় না।

ব্যর্থতার ধরন, আপনি যে স্ট্রিংগুলো দেখবেন

Apache-এর কনফিগ ভাঙা থাকার কারণে Certbot শুরু হতে অস্বীকার করে।

The apache plugin is not working; there may be problems with your existing configuration.
The error was: MisconfigurationError('Error while running apache2ctl configtest.\n\nAction \'configtest\' failed.\nThe Apache error log may have more information.\n\nAH00526: Syntax error on line 12 of /etc/apache2/sites-enabled/example.com.conf')

প্লাগিনটি কিছু পরিবর্তন করার আগে configtest চালায় এবং Apache নিজে অসন্তুষ্ট থাকলে বেরিয়ে যায় — \n-গুলো আক্ষরিক, কারণ Certbot এক্সেপশনের repr প্রিন্ট করে। নিজে sudo apache2ctl configtest চালান: এটি ফাইল ও লাইন নাম বলবে — সাধারণত হাতে এডিট করার কারণে টাইপো, এমন একটি SSLCertificateFile যা একটি আর নেই এমন পাথ নির্দেশ করছে, বা একটি মডিউল যা উল্লেখ করা হয়েছে কিন্তু চালু নেই। এটি না হওয়া পর্যন্ত ঠিক করুন যতক্ষণ না এটি Syntax OK প্রিন্ট করে, তারপর Certbot আবার চালান।

কোনো vhost ডোমেইনের সাথে মেলে না।

Unable to find a virtual host listening on port 80 which is currently the only challenge port.

এটি আগের অনুপস্থিত-ServerName ব্যর্থতা, ইস্যুর সময় ধরা পড়েছে। Certbot প্রতিটি চালু port-80 vhost-এ আপনার -d-এর সাথে মেলানোর জন্য ServerName/ServerAlias খুঁজেছে এবং কিছুই পায়নি। sudo apache2ctl -S দেখায় Apache আসলে কী রাউট করে; সঠিক vhost-এ ServerName লাইন যোগ করুন, রিলোড করুন, আবার চেষ্টা করুন। এর একটি কাছাকাছি রূপ হলো ভ্যালিডেশন ভুল vhost-এ পৌঁছানো — চ্যালেঞ্জ রেসপন্স Invalid response ... 404 ফিরে আসে কারণ অন্য একটি সাইট অনুরোধটি ধরে নিয়েছে। একই ডায়াগনসিস, একই টুল: apache2ctl -S।

ভ্যালিডেশন টাইমআউট হয়।

Certbot failed to authenticate some domains (authenticator: apache).
...
Detail: ...: Timeout during connect (likely firewall problem)

Let's Encrypt আপনার DNS যে ঠিকানা বিজ্ঞাপন করে সেখানে port 80-এ একটি TCP সংযোগ খুলতে পারেনি। সম্ভাবনার ক্রম অনুযায়ী: আপনার প্রোভাইডারের নেটওয়ার্ক ফায়ারওয়াল (ufw থেকে আলাদা, হোস্টিং প্যানেলে কনফিগার করা), একটি ufw রুলসেট যা শুধু 443 বা শুধু SSH অনুমোদন করে, DNS এখনও একটি পূর্ববর্তী সার্ভারে নির্দেশ করছে, বা পুরোনো-AAAA সমস্যা — তাদের সার্ভার IPv6 চেষ্টা করেছে, আপনারটি শুধু IPv4-এ উত্তর দেয়। VPS-এর বাইরে থেকে পরীক্ষা করুন: আপনার ল্যাপটপ থেকে curl -I http://example.com তাদের ভ্যালিডেটর যা দেখে তা পুনরুৎপাদন করে।

আপনি এতবার চেষ্টা করেছেন যে একটি রেট লিমিটে পৌঁছে গেছেন।

Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/

Let's Encrypt প্রতি হোস্টনাম প্রতি অ্যাকাউন্ট প্রতি ঘণ্টায় 5টি ব্যর্থ ভ্যালিডেশন অনুমোদন করে — তাদের 2025 সালের রেট-লিমিট পুনর্গঠনের পর এটি একটি রিফিলিং বাকেট, প্রায় প্রতি 12 মিনিটে একটি করে রিট্রাই ফিরে পাওয়া যায় — এবং একটি ভাঙা ফায়ারওয়ালের বিরুদ্ধে বারবার চেষ্টা করলে এটি দ্রুত শেষ হয়ে যায়। অপেক্ষা করা কাজ করে, কিন্তু আসল সমাধান হলো আচরণগত: যেকোনো ব্যর্থতার পরে, স্টেজিং পরিবেশে ডিবাগ করুন যতক্ষণ না এটি সফল হয়।

sudo certbot certonly --apache --dry-run -d example.com -d www.example.com

certonly নোট করুন: --dry-run শুধুমাত্র certonly এবং renew সাবকমান্ড দ্বারা গৃহীত হয়, এবং খালি certbot --apache --dry-run ফর্ম একেবারেই চলতে অস্বীকার করে, আপনাকে --dry-run currently only works with the 'certonly' or 'renew' subcommands বলে। ড্রাই রান স্টেজিং-এর বিরুদ্ধে ভ্যালিডেট করে, যার নিজস্ব উদার লিমিট রয়েছে এবং কোনো বাস্তব সার্টিফিকেট ইস্যু করে না, তাই আপনি সেখানে সারাদিন ব্যর্থ হতে পারেন। স্টেজিং পাস করার পরেই কেবল আসল কমান্ড আবার চালান। অন্যান্য লিমিট — প্রতি নিবন্ধিত ডোমেইন প্রতি সপ্তাহে 50টি সার্টিফিকেট, সপ্তাহে একই নাম সেটের 5টি ডুপ্লিকেট — আপনি শুধুমাত্র তখনই সম্মুখীন হবেন যদি কোনো স্ক্রিপ্ট লুপে পুনরায় ইস্যু করছে।

HTTPS চালু হওয়ার পরে, মনে রাখবেন সার্টিফিকেট ট্রান্সপোর্ট নিরাপদ করে, সার্ভারকে নয়: port 22 এখনও সারাদিন পাসওয়ার্ড অনুমান গ্রহণ করছে। এর সাথে Ubuntu 24.04-এ Fail2ban যুক্ত করাই হলো পরবর্তী প্রাকৃতিক ত্রিশ মিনিট।

FAQ

Ubuntu 24.04-এ Apache-এর জন্য Certbot snap বা apt দিয়ে ইনস্টল করা উচিত?

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

Certbot কেন "Unable to find a virtual host listening on port 80" বলে?

কারণ কোনো সক্রিয় port-80 vhost-এ ServerName বা ServerAlias নেই যা -d-এ দেওয়া ডোমেইনের সাথে মেলে। Ubuntu-এর ডিফল্ট vhost-এ ServerName কমেন্ট করা থাকে। sudo apache2ctl -S চালান। যে vhost-এ এই নামটি থাকা উচিত, সেটি খুঁজুন বা তৈরি করুন। ServerName example.com যোগ করুন। Apache রিলোড করুন। তারপর Certbot আবার চালান।

"Timeout during connect (likely firewall problem)" কীভাবে ঠিক করব?

Let's Encrypt আপনার DNS-এ প্রকাশিত ঠিকানার port 80-এ পৌঁছাতে পারেনি। আপনার প্রোভাইডারের প্যানেল-স্তরের নেটওয়ার্ক ফায়ারওয়াল এবং ufw দুটোই পরীক্ষা করুন। নিশ্চিত করুন যে dig +short example.com এই VPS ফেরত দেয়। কোনো পুরোনো AAAA রেকর্ড মুছুন বা ঠিক করুন — AAAA রেকর্ড থাকলে ভ্যালিডেশন IPv6 বেছে নেয়। সার্ভারের বাইরে থেকে curl -I http://example.com দিয়ে সমাধান যাচাই করুন। তারপর আসল ইস্যু হওয়ার আগে sudo certbot certonly --apache --dry-run -d example.com দিয়ে রিহার্স করুন।

Certbot কি Ubuntu 24.04-এ স্বয়ংক্রিয়ভাবে সার্টিফিকেট রিনিউ করে?

হ্যাঁ। apt প্যাকেজটি certbot.timer ইনস্টল করে। এটি একটি systemd টাইমার যা দিনে দুবার চলে। মেয়াদ শেষ হওয়ার 30 দিনের মধ্যে যেকোনো সার্টিফিকেট রিনিউ করে। এরপর Apache রিলোড করে। snap একই কাজের জন্য snap.certbot.renew.timer ব্যবহার করে। systemctl list-timers certbot.timer দিয়ে যাচাই করুন এবং sudo certbot renew --dry-run দিয়ে রিহার্স করুন — এর ওপর নিজের কোনো cron জব যোগ করবেন না।

Certbot এবং Apache দিয়ে ওয়াইল্ডকার্ড সার্টিফিকেট কীভাবে পাব?

ওয়াইল্ডকার্ডের জন্য DNS-01 চ্যালেঞ্জ দরকার। Certbot-কে _acme-challenge.example.com-এ একটি TXT রেকর্ড রাখতে হবে। এর মানে হলো আপনার DNS প্রোভাইডারের জন্য API ক্রেডেনশিয়াল সহ একটি certbot-dns-* প্লাগইন দরকার (--manual বিকল্পে প্রতিবার রিনিউয়ালে হাতে টেক্সট রেকর্ড এডিট করতে হয়)। যদি কয়েকটি নির্দিষ্ট সাবডোমেইন থাকে, তবে একটি SAN সার্টিফিকেট সেগুলো স্পষ্টভাবে তালিকাভুক্ত করলে সহজ হয়। এতে সার্ভারে DNS API কী রাখতে হয় না।