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

আপনি কী তৈরি করছেন

Ubuntu 24.04-এ একটি Apache সাইট, যা HTTPS-এ সাড়া দেবে এবং Certbot-এর মাধ্যমে ইস্যু করা বিনামূল্যের, ব্রাউজার-অনুমোদিত Let's Encrypt certificate ব্যবহার করবে। একটি systemd timer certificate-টি স্বয়ংক্রিয়ভাবে নবায়ন করবে, তাই পরে আপনাকে এটি নিয়ে ভাবতে হবে না। কাজটি সম্পন্ন করার command-টি এক লাইনের। যা কিছু ব্যর্থ হয়, তা ওই লাইনের আগেই ব্যর্থ হয়: ServerName ছাড়া একটি vhost, provider firewall-এ বন্ধ port 80, অথবা এখনও পুরোনো server-এ নির্দেশ করা DNS। তাই এই guide-এ precondition-গুলোর ওপর বেশি গুরুত্ব দেওয়া হয়েছে এবং প্রতিটি ভুলে যে নির্দিষ্ট error string প্রদর্শিত হয়, তা উল্লেখ করা হয়েছে।

পরিধি সম্পর্কে দুটি কথা। আপনার web server যদি nginx হয়, তাহলে প্রবাহের কাঠামো একই, কিন্তু plugin এবং configuration আলাদা। সে ক্ষেত্রে এই guide-এর nginx সংস্করণ ব্যবহার করুন। আর আপনি যদি শুধু অভ্যন্তরীণ ব্যবহারের কোনো সিস্টেম সুরক্ষিত করেন—যেমন private address-এ থাকা একটি admin panel বা এমন একটি staging box যেটিতে অন্য কেউ প্রবেশ করে না—তাহলে কোনো certificate authority প্রয়োজন নেই; একটি self-signed certificate কম ব্যবস্থা লাগে এবং offline অবস্থায় কাজ করে।

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

• Apache-এ আপনার সাইট ইতিমধ্যে সাধারণ HTTP-এর মাধ্যমে পরিবেশিত হতে হবে। Certbot-এর Apache plugin বিদ্যমান সাইটের কনফিগারেশন সম্পাদনা করে; এটি নতুন সাইট তৈরি করে না। আপনি যদি খালি VPS থেকে শুরু করেন, আগে Ubuntu 24.04-এ LAMP stack তৈরি করুন, তারপর এখানে ফিরে আসুন। এই নির্দেশিকায় সেই stack-এর অনুপস্থিত TLS অধ্যায়টি রয়েছে।
• আপনার VPS-এর ঠিকানায় A record-সহ একটি সর্বজনীন domain থাকতে হবে। Let's Encrypt-এর HTTP-01 challenge-এর অর্থ হলো তাদের validation server ইন্টারনেট থেকে আপনার server-এ সংযোগ করবে। তাই port forward ছাড়া NAT-এর পেছনে থাকা homelab, কোনো .local নাম বা সরাসরি IP address ব্যবহার করা যাবে না। dig +short example.com-কে আপনার VPS-এর address ফেরত দিতে হবে। আপনি গত এক ঘণ্টায় DNS পরিবর্তন করে থাকলে certificate issue করার আগে পুরোনো record-এর TTL শেষ হওয়া পর্যন্ত অপেক্ষা করুন।
• AAAA record থাকলে সেটি সঠিক হতে হবে। কোনো AAAA record প্রকাশিত থাকলে Let's Encrypt IPv6-কে অগ্রাধিকার দেয়। তাই আপনার laptop থেকে, সম্ভবত IPv4 ব্যবহার করে, curl ঠিকমতো কাজ করলেও পুরোনো AAAA record validation ব্যর্থ করাতে পারে। সঠিক AAAA record প্রকাশ করুন, অথবা কোনো AAAA record রাখবেন না।

Port 80 এবং 443-কে ufw-তে এবং আপনার provider-এর network firewall-এ open থাকতে হবে। বেশিরভাগ hosting panel-এ একটি দ্বিতীয় firewall থাকে, যা OS দেখতে পায় না। HTTP-01 নির্দিষ্টভাবে port 80-এর মাধ্যমে validation করে; এটি শুধু 443-এ চালানো যাবে না।

sudo ufw allow "Apache Full"
sudo ufw status

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

Snap নাকি apt Certbot? 24.04-এ apt অবশেষে উপযুক্ত

Certbot ভালো কারণেই কয়েক বছর আগে snap distribution-এ চলে যায়: distro package-গুলো পুরোনো হয়ে স্থবির হয়ে পড়েছিল। Ubuntu 20.04-এ Certbot 0.40 সরবরাহ করা হয়েছিল এবং আর আপডেট করা হয়নি। ফলে project-টি পাঁচ বছর পুরোনো bug debug করতে করতে ক্লান্ত হয়ে পড়ে। 24.04-এ সেই কারণ আর নেই। archive-এ Certbot 2.9.0, অর্থাৎ বর্তমান প্রজন্মের release, সরবরাহ করা হয়েছে এবং unattended-upgrades এটিকে patch করে রাখে। এই OS-এর জন্য আমার পরামর্শ: apt ব্যবহার করুন। এতে snapd daemon এড়ানো যায়, Apache plugin একই transaction-এ install হয় এবং renewal timer সাধারণ Debian পদ্ধতিতে systemd-এর সঙ্গে যুক্ত হয়।

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

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

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

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

যেটিই বেছে নিন, কখনও দুটিই একসঙ্গে চালাবেন না। দুটি installation থাকলে /etc/letsencrypt নিয়ে দুটি renewal scheduler পরস্পরের সঙ্গে সংঘর্ষে জড়ায়। আপনার shell PATH-এ যে certbot খুঁজে পায়, সেটি আপনার certificate-এর মালিক নাও হতে পারে। উপরের apt remove line-টি ঐচ্ছিক কোনো সাজসজ্জা নয়।

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

certbot --apache প্রতিটি পাস করা -d ডোমেনের সঙ্গে ServerName বা ServerAlias মিলে যায় এমন port-80 virtual host খুঁজে কাজ করে। এরপর এটি সেই 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 এটি পার্স করছে ও নামটি সঠিক vhost-এ পাঠাচ্ছে:

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 দেখা গেলে, সেটি আপনার vhost-এর নয়, global ServerName-এর জন্য একটি সতর্কতা। এই ক্ষেত্রে তা ক্ষতিকর নয়। echo "ServerName $(hostname -f)" | sudo tee /etc/apache2/conf-available/servername.conf && sudo a2enconf servername && sudo systemctl reload apache2 ব্যবহার করলে সতর্কতাটি আর দেখাবে না।

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

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

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

প্রথমবার চালালে 3টি বিষয় জানতে চায়: একটি ইমেল ঠিকানা (এটি আপনার ACME অ্যাকাউন্ট এবং জরুরি CA বিজ্ঞপ্তির জন্য ব্যবহৃত হয়; Let's Encrypt এখন আর মেয়াদ শেষ হওয়ার সতর্কবার্তা পাঠায় না, তাই renewal মনিটর করার দায়িত্ব আপনার), Let's Encrypt-এর শর্তাবলিতে সম্মতি, এবং আপনার ইমেল EFF-এর সঙ্গে শেয়ার করবেন কি না। এখন আর redirect-সংক্রান্ত প্রশ্ন নেই: Certbot 2.0 থেকে Apache installer ডিফল্টভাবে HTTP-কে HTTPS-এ redirect করে, যা আপনার প্রয়োজন। plain 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 4টি কাজ করেছে: Apache-এর ssl module আগে সক্রিয় না থাকলে সক্রিয় করেছে, example.com-le-ssl.conf লিখেছে—*:443-এর ওপর আপনার vhost-এর একটি কপি, যেখানে SSLEngine on এবং certificate path রয়েছে—এটি সক্রিয় করেছে, এবং মূল port-80 vhost-এ একটি RewriteRule block যোগ করেছে, যা সবকিছুকে HTTPS-এ 301 redirect করে। আপনার মূল vhost file সম্পাদনা করা হয়েছে, প্রতিস্থাপন করা হয়নি। SSL-এর সমান্তরাল কপিটি একই স্থানে রয়েছে, তাই এতে যোগ করা প্রতিটি line পড়ে দেখতে পারবেন।

শংসাপত্রটি আসলে কোথায় থাকে এবং কেন এটি কখনও কপি করবেন না

সবকিছু /etc/letsencrypt/live/example.com/-এর অধীনে থাকে: fullchain.pem (শংসাপত্র এবং intermediate chain, যে ফাইলের দিকে server-গুলোর নির্দেশ করা উচিত), privkey.pem (private key, যা কেবল root পড়তে পারে), এবং আলাদা অংশ প্রয়োজন এমন software-এর জন্য cert.pem ও chain.pem। এগুলো /etc/letsencrypt/archive/-এর দিকে নির্দেশ করা symlink। এই indirection-ই renewal প্রক্রিয়া: renewal archive/-এ নতুন file লেখে এবং symlink-গুলো নতুন file-এর দিকে নির্দেশ করে। অন্য যেকোনো software-কে live/ path-গুলোর দিকে নির্দেশ করুন। তাহলে কোনো অতিরিক্ত কাজ ছাড়াই সেটি renewal গ্রহণ করবে। File-গুলো অন্য কোথাও কপি করলে 90 দিন পরে service outage তৈরি হবে।

জানার মতো আরেকটি file হলো /etc/letsencrypt/renewal/example.com.conf। এতে এই certificate কীভাবে জারি করা হয়েছিল, authenticator = apache, installer = apache এবং domain-গুলোর তথ্য থাকে। ফলে renewal unattended অবস্থায় একই প্রক্রিয়া পুনরাবৃত্তি করতে পারে এবং পরে Apache reload করতে পারে।

নবীকরণ ইতিমধ্যে নির্ধারিত আছে, তা যাচাই করুন; নতুন করে তৈরি করবেন না

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

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

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

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

dry run ব্যর্থ হলে প্রায় 60 দিন পর প্রকৃত renewal-ও একইভাবে ব্যর্থ হবে। বর্তমান সার্টিফিকেটের পুরো মেয়াদ এখনও বাকি থাকতেই এখন সমস্যাটি ঠিক করুন। সাধারণ কারণ হলো সার্টিফিকেট ইস্যু হওয়ার পরে যোগ করা firewall rule, যা আবার 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 ইনস্টল করা redirect। দ্বিতীয় কমান্ডে HTTP/1.1 200 OK ফলাফল আসা উচিত এবং curl-এর কোনো TLS অভিযোগ থাকা উচিত নয়। তৃতীয় কমান্ডটি issuer প্রদর্শন করে। এতে O = Let's Encrypt লাইন থাকবে, যেখানে R12 বা E7-এর মতো সংক্ষিপ্ত CN এবং আনুমানিক 90 দিন পরের notAfter থাকবে। ব্রাউজারে তালার চিহ্ন দেখা যাবে। সেটিতে ক্লিক করলে একই issuer প্রদর্শিত হবে। curl কাজ করলেও ব্রাউজার সতর্কতা দেখালে, প্রায় নিশ্চিতভাবে আপনি cached page বা ভুল hostname দেখছেন। এটি certificate-এর সমস্যা নয়।

একাধিক সাইট: একটি SAN certificate নাকি প্রতি সাইটে একটি certificate

দুটিই কাজ করে এবং উভয়ের renewal একইভাবে হয়। একই server-এ থাকা পরস্পর-সম্পর্কহীন সাইটগুলোর জন্য প্রতি সাইটে একবার করে issue command চালান। প্রতিটি সাইট live/-এর অধীনে নিজস্ব directory এবং নিজস্ব renewal config পাবে। একটি domain-এর সমস্যা অন্য domain-এর renewal কখনও বন্ধ করবে না। এটিই আমার default পদ্ধতি।

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

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

Certbot পরিবর্তিত domain set শনাক্ত করবে এবং certificate সম্প্রসারণের অনুমোদন চাইবে। এরপর এটি একই live/ path-এ certificate প্রতিস্থাপন করবে। তাই অন্য কিছু পরিবর্তন করতে হবে না। মনে রাখবেন, এই তালিকাটি replacement হিসেবে কাজ করে, append হিসেবে নয়। ওই command থেকে www বাদ দিলে নতুন certificate থেকে সেটি নীরবে বাদ পড়বে।

Wildcard-এর জন্য DNS-01 প্রয়োজন, এবং সাধারণত আপনার wildcard প্রয়োজন হয় না

HTTP-01 *.example.com ইস্যু করতে পারে না। Web server-এ একটি ফাইল রাখলে একটি hostname-এর নিয়ন্ত্রণ প্রমাণিত হয়, সম্পূর্ণ namespace-এর নয়। Wildcard-এর জন্য DNS-01 challenge প্রয়োজন। Certbot _acme-challenge.example.com-এ একটি TXT record সেট করে। বাস্তবে এর জন্য আপনার DNS provider-এর API credentials-সহ একটি certbot-dns-* plugin প্রয়োজন, অথবা প্রতিটি renewal-এর সময় --manual ব্যবহার করে হাতে TXT record সম্পাদনা করতে হবে। এই পদ্ধতি অত্যন্ত কষ্টসাধ্য, তাই এর ওপর নির্ভর করে পরিকল্পনা করবেন না। TXT record কীভাবে কাজ করে থেকে শুরু করে unattended renewal সম্পন্ন করে এমন plugin পর্যন্ত সম্পূর্ণ নির্দেশিকা DNS-01-এর মাধ্যমে Certbot দিয়ে wildcard certificate-এ রয়েছে। বাস্তব পরামর্শ: আপনার চারটি নির্দিষ্ট subdomain থাকলে, চারটিকেই তালিকাভুক্ত করা একটি SAN certificate wildcard-এর চেয়ে সহজ এবং server-এ DNS API key রাখার প্রয়োজন হয় না।

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

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

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

কোনো vhost domain-এর সঙ্গে মেলে না।

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

এটি আগে উল্লেখ করা missing-ServerName ত্রুটি, যা issue করার সময় ধরা পড়ে। Certbot প্রতিটি enabled port-80 vhost-এ আপনার -d-এর সঙ্গে মেলা ServerName/ServerAlias খুঁজেছে, কিন্তু কিছু পায়নি। Apache বাস্তবে কীভাবে route করছে, তা sudo apache2ctl -S দেখায়। সঠিক vhost-এ ServerName line যোগ করুন, reload করুন, তারপর আবার চেষ্টা করুন। এর কাছাকাছি আরেকটি সমস্যা হলো validation ভুল vhost-এ পৌঁছানো। অন্য site request গ্রহণ করায় challenge response Invalid response ... 404 ফিরে আসে। নির্ণয় একই, tool-ও একই: apache2ctl -S।

Validation-এর সময়সীমা শেষ হয়ে যায়।

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

আপনার DNS যে address প্রকাশ করছে, সেখানে Let's Encrypt port 80-এ TCP connection খুলতে পারেনি। সম্ভাবনার ক্রমে কারণগুলো হলো: আপনার provider-এর network firewall, যা ufw থেকে আলাদা এবং hosting panel-এ কনফিগার করা; এমন ufw ruleset যা শুধু 443 বা শুধু SSH অনুমোদন করে; DNS এখনও আগের server-এ নির্দেশ করছে; অথবা পুরোনো AAAA সমস্যা। তাদের server IPv6 ব্যবহার করে চেষ্টা করেছে, কিন্তু আপনার server শুধু IPv4-এ উত্তর দেয়। VPS-এর বাইরে থেকে পরীক্ষা করুন: আপনার laptop থেকে curl -I http://example.com চালালে তাদের validator যা দেখে, সেটিই পুনরুৎপাদন হবে।

বারবার retry করতে করতে rate limit-এ পৌঁছে গেছেন।

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

Let's Encrypt প্রতি account-এ প্রতি hostname-এর জন্য প্রতি ঘণ্টায় 5টি failed validation অনুমোদন করে। 2025 সালের rate-limit পুনর্গঠনের পর এটি একটি refilling bucket। প্রায় প্রতি 12 মিনিটে 1টি retry-এর সুযোগ ফিরে আসে। নষ্ট firewall-এর বিরুদ্ধে দ্রুত retry করলে bucket দ্রুত শেষ হয়ে যায়। অপেক্ষা করলে কাজ হবে। তবে প্রকৃত সমাধান হলো পদ্ধতি পরিবর্তন করা: যেকোনো failure-এর পর staging environment ব্যবহার করে debug করুন, যতক্ষণ না এটি সফল হয়।

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

certonly লক্ষ্য করুন: --dry-run শুধু certonly এবং renew subcommand-এর সঙ্গে গ্রহণ করা হয়। খালি certbot --apache --dry-run form একেবারেই চালানো যায় না এবং --dry-run currently only works with the 'certonly' or 'renew' subcommands বার্তা দেখায়। Dry run staging-এর বিরুদ্ধে validation করে। Staging-এর নিজস্ব উদার limit আছে এবং এটি কোনো real certificate issue করে না। তাই সেখানে সারাদিন failure হলেও সমস্যা নেই। Staging সফল হওয়ার পরেই কেবল real command আবার চালান। অন্য limit-গুলো হলো: প্রতি registered domain-এ প্রতি সপ্তাহে 50টি certificate এবং একই name set-এর প্রতি সপ্তাহে 5টি duplicate। কোনো script loop-এর মধ্যে certificate reissue না করলে সাধারণত এই limit-এ পৌঁছাবেন না।

HTTPS চালু হওয়ার পর মনে রাখুন, certificate শুধু transport সুরক্ষিত করে, server-কে নয়। Port 22-এ এখনও সারাদিন password guess করা হতে পারে। এর সঙ্গে Ubuntu 24.04-এ Fail2ban যুক্ত করা পরবর্তী স্বাভাবিক 30 মিনিটের কাজ।

FAQ

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

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

Certbot কেন "Unable to find a virtual host listening on port 80" দেখায়?

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

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

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

Ubuntu 24.04-এ Certbot কি স্বয়ংক্রিয়ভাবে certificate renew করে?

হ্যাঁ। apt package certbot.timer ইনস্টল করে। এটি একটি systemd timer, যা দিনে দুবার চলে এবং মেয়াদ শেষ হতে 30 দিন বা তার কম বাকি থাকা যেকোনো certificate renew করে। এরপর এটি Apache reload করে। একই কাজের জন্য snap snap.certbot.renew.timer ব্যবহার করে। systemctl list-timers certbot.timer দিয়ে যাচাই করুন এবং sudo certbot renew --dry-run দিয়ে পরীক্ষা করুন। এর পাশাপাশি নিজের cron job যোগ করবেন না।

Certbot এবং Apache দিয়ে wildcard certificate কীভাবে পাব?

Wildcard certificate-এর জন্য DNS-01 challenge প্রয়োজন। Certbot-কে _acme-challenge.example.com-এ একটি TXT record স্থাপন করতে হয়। এর জন্য আপনার DNS provider-এর API credentials-সহ একটি certbot-dns-* plugin প্রয়োজন। --manual বিকল্প ব্যবহার করলে প্রতিবার renewal-এর সময় TXT record হাতে সম্পাদনা করতে হয়। আপনার যদি অল্প কয়েকটি নির্দিষ্ট subdomain থাকে, তাহলে সেগুলো স্পষ্টভাবে তালিকাভুক্ত করে একটি SAN certificate ব্যবহার করা সহজ। এতে DNS API key সার্ভারে রাখারও প্রয়োজন হয় না।