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 অবস্থায় কাজ করে।

Prerequisites, এবং Certbot চালু হওয়ার আগেই এটি ব্যর্থ হওয়ার তিনটি উপায়

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

ufw-এ এবং আপনার provider-এর network firewall-এ port 80 এবং 443 খোলা থাকতে হবে। অধিকাংশ 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 সংস্করণ এসেছিল এবং এরপর আর পরিবর্তন হয়নি। প্রকল্পটি পাঁচ বছর পুরোনো bug debug করতে করতে ক্লান্ত হয়ে পড়েছিল। 24.04-এ সেই কারণ আর নেই। Archive-এ Certbot 2.9.0 রয়েছে, যা আধুনিক 2.x line-এর February 2024 release। আর unattended-upgrades Ubuntu প্রকাশ করা যেকোনো security update ইনস্টল করে। Upstream ইতিমধ্যে 5.x series-এ চলে গেছে, কিন্তু এই guide-এর কোনো কিছুর জন্য সেটি প্রয়োজন নেই। এই OS-এর জন্য আমার পরামর্শ: apt ব্যবহার করুন। এতে snapd daemon-এর প্রয়োজন হয় না, Apache plugin একই transaction-এ ইনস্টল হয়, এবং 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 হওয়ার দিনই সর্বশেষ version চান, অথবা এমন 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 যে certbot খুঁজে পায়, সেটি PATH-এর 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টি বিষয় জানতে চায়: একটি email address (Let's Encrypt এখন আর এটি আপনার ACME account-এর সঙ্গে সংরক্ষণ করে না এবং expiry warning-ও পাঠায় না, তাই renewal monitor করার দায়িত্ব আপনার), Let's Encrypt-এর শর্তে সম্মতি, এবং আপনার email EFF-এর সঙ্গে share করবেন কি না। এখন আর redirect সম্পর্কিত প্রশ্ন নেই: Certbot 1.0 থেকে Apache installer ডিফল্টভাবে HTTP থেকে HTTPS-এ redirect করে (প্রশ্নটি 1.4-এ বাদ দেওয়া হয়েছিল), এবং আপনার ক্ষেত্রে এটিই প্রয়োজন। যদি সত্যিই plain HTTP দিয়ে content পরিবেশন চালু রাখতে হয়, তাহলে --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 2027-01-09.

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

ওই message-এর আড়ালে Certbot 4টি কাজ করেছে: আগে সক্রিয় না থাকলে Apache-এর ssl module সক্রিয় করেছে, example.com-le-ssl.conf লিখেছে, *:443-এর উপর আপনার vhost-এর একটি copy তৈরি করেছে এবং সেখানে SSLEngine on ও certificate path যোগ করেছে, সেটি সক্রিয় করেছে, এবং মূল port-80 vhost-এ একটি RewriteRule block যোগ করেছে, যা সবকিছুকে HTTPS-এ 301 redirect করে। আপনার original vhost file edit করা হয়েছে, replace করা হয়নি। SSL twin file-টি তার পাশেই রয়েছে, তাই Certbot যোগ করা প্রতিটি 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 করতে পারে।

Renewal আগে থেকেই নির্ধারিত আছে, এটি যাচাই করুন; নতুন করে তৈরি করবেন না

Let's Encrypt-এর certificate নকশাগতভাবে বর্তমানে 90 দিন কার্যকর থাকে, এবং apt package ইতিমধ্যে প্রয়োজনীয় ব্যবস্থা ইনস্টল করেছে: একটি systemd timer, যা প্রতিদিন দুইবার এলোমেলো সময়ে চলে এবং মেয়াদ শেষ হতে 30 দিন বা তার কম বাকি থাকা certificate নবায়ন করে। এর ওপর অতিরিক্ত cron job যোগ করবেন না; দ্বিতীয় scheduler কোনো সুবিধা দেয় না, শুধু log বাড়ায় এবং rate-limit-এর ঝুঁকি তৈরি করে। Let's Encrypt ঘোষণা করেছে যে February 10, 2027 থেকে নতুন certificate-এর default lifetime হবে 64 দিন। এই certificate-গুলোর ক্ষেত্রেও 30 দিনের window কার্যকর থাকবে। শুধু renewal day 60-এর বদলে প্রায় day 34-এ হবে। তাই এই server-এ কোনো পরিবর্তন করার দরকার নেই।

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

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

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

Dry run ব্যর্থ হলে প্রায় 60 দিন পরে প্রকৃত renewal-ও একইভাবে ব্যর্থ হবে। বর্তমান certificate-এর সম্পূর্ণ মেয়াদ এখনও বাকি থাকতেই এখন সমস্যাটি সমাধান করুন। সাধারণ কারণ হলো certificate issue হওয়ার পরে যোগ করা firewall rule, যা আবার port 80 বন্ধ করে দিয়েছে।

curl দিয়ে যাচাই করুন, এবং padlock-এ কী দেখানোর কথা

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/ header থাকা উচিত। এটিই Certbot ইনস্টল করা redirect। দ্বিতীয় কমান্ডে HTTP/1.1 200 OK ফেরত আসা উচিত এবং curl-এর কাছ থেকে কোনো TLS অভিযোগ থাকা উচিত নয়। তৃতীয় কমান্ডটি issuer দেখায়। এতে O = Let's Encrypt line থাকবে, যেখানে YE1 বা YE2-এর মতো সংক্ষিপ্ত CN (ECDSA keys-এর ক্ষেত্রে), অথবা YR1 বা YR2-এর মতো CN (RSA keys-এর ক্ষেত্রে) দেখা যাবে। notAfter-ও প্রায় 90 দিন পরের তারিখ দেখাবে। Let's Encrypt পুরোনো intermediate অবসর নেওয়ার আগে জারি করা কোনো certificate পরবর্তী renewal না হওয়া পর্যন্ত R12 বা E7-এর মতো CN দেখাতে পারে; এটি কোনো error নয়। Browser-এ padlock দেখা যাবে। সেটিতে click করলে একই issuer দেখা যাবে। curl কাজ করলেও browser warning দেখালে প্রায় নিশ্চিতভাবে আপনি 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-এর configuration নষ্ট থাকায় 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')

কোনো কাজ করার আগে plugin-টি configtest চালায়। Apache নিজেই সমস্যায় থাকলে এটি সঙ্গে সঙ্গে বন্ধ হয়ে যায়। \n-গুলো অপরিবর্তিত থাকে, কারণ Certbot exception-এর repr প্রিন্ট করে। নিজে sudo apache2ctl configtest চালান। এতে file এবং line দেখাবে। সাধারণত hand-edit করার সময় হওয়া typo, এমন একটি SSLCertificateFile যার নির্দেশিত path আর নেই, অথবা enable না করা কোনো module-এর reference এখানে ধরা পড়ে। যতক্ষণ না এটি Syntax OK প্রিন্ট করে, ততক্ষণ ঠিক করুন। তারপর Certbot আবার চালান।

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

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

এটি আগের missing-ServerName failure, যা issue করার সময় ধরা পড়ে। Certbot port-80-এর প্রতিটি enabled vhost-এ আপনার -d-এর সঙ্গে মেলা ServerName/ServerAlias খুঁজেছে, কিন্তু কিছু পায়নি। sudo apache2ctl -S দেখায় Apache আসলে কোন route ব্যবহার করছে। সঠিক vhost-এ ServerName line যোগ করুন, reload করুন এবং আবার চেষ্টা করুন। কাছাকাছি আরেকটি সমস্যা হলো validation ভুল vhost-এ পৌঁছানো। অন্য কোনো site request ধরে ফেলায় challenge response Invalid response ... 404 ফিরে আসে। Diagnosis একই, 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-এ configured থাকে; এমন ufw ruleset যা শুধু 443 বা শুধু SSH অনুমোদন করে; অথবা DNS এখনও আগের server-এ নির্দেশ করছে। শুধু পুরোনো AAAA record সাধারণত এই সমস্যা ঘটায় না। IPv6 attempt-এর সময়সীমা শেষ হলে Let's Encrypt IPv4 দিয়ে আবার চেষ্টা করে। AAAA-সংক্রান্ত সমস্যা সাধারণত তার বদলে Connection refused অথবা ভুল server থেকে আসা Invalid response হিসেবে প্রকাশ পায়। VPS-এর বাইরে থেকে test করুন: আপনার laptop থেকে curl -I http://example.com চালালে validator যা দেখে, তা পুনরায় দেখা যাবে।

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

Error creating new order :: too many failed authorizations (5) for "example.com" in the last 1h0m0s, retry after ... UTC: see https://letsencrypt.org/docs/rate-limits/...

Let's Encrypt প্রতি hostname ও account-এর জন্য প্রতি ঘণ্টায় 5টি ব্যর্থ validation অনুমোদন করে। এটি এমন একটি refill হওয়া 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-এর আলাদা এবং উদার limits আছে, আর এটি কোনো real certificate issue করে না। তাই সেখানে সারা বিকেল ব্যর্থ হলেও সমস্যা নেই। Staging সফল হওয়ার পরেই কেবল real command আবার চালান। অন্য limits-গুলো, প্রতি সপ্তাহে registered domain-পিছু 50টি certificate এবং একই name set-এর 5টি duplicate, কেবল কোনো script loop-এর মধ্যে reissue করতে থাকলে সাধারণত আপনার ক্ষেত্রে প্রযোজ্য হবে।

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

FAQ

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

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

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

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

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

আপনার DNS যে address প্রকাশ করে, সেখানে Let's Encrypt port 80-এ পৌঁছাতে পারেনি। আপনার provider-এর panel-level network firewall এবং ufw—দুটিই পরীক্ষা করুন। dig +short example.com এই VPS-এ নির্দেশ করছে কি না নিশ্চিত করুন। পুরোনো বা ভুল AAAA record সংশোধন করুন বা মুছে দিন, কারণ validation প্রথমে IPv6 ব্যবহার করে এবং timeout হলে তবেই IPv4-এ ফিরে যায়। সার্ভারের বাইরে থেকে 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, যা দিনে দুবার চলে এবং expiry-এর 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-এর জন্য DNS-01 challenge প্রয়োজন। Certbot-কে _acme-challenge.example.com-এ একটি TXT record বসাতে হবে। এর জন্য আপনার DNS provider-এর API credential-সহ একটি certbot-dns-* plugin প্রয়োজন। --manual alternative ব্যবহার করলে প্রতিটি renewal-এর সময় TXT record হাতে সম্পাদনা করতে হয়। আপনার যদি মাত্র কয়েকটি নির্দিষ্ট subdomain থাকে, তাহলে সেগুলো স্পষ্টভাবে তালিকাভুক্ত করা SAN certificate ব্যবহার করা সহজ। এতে DNS API key সার্ভারের বাইরে রাখা যায়।