Ubuntu 24.04-ல் Apache-க்கு Certbot நிறுவுவது எப்படி?

நீங்கள் உருவாக்குவது என்ன

Ubuntu 24.04-ல் இயங்கும் ஒரு Apache தளம், HTTPS மூலம் பதிலளிக்கும். இதற்கு உலாவிகளால் அங்கீகரிக்கப்பட்ட Let's Encrypt சான்றிதழ் பயன்படுத்தப்படும். இது Certbot மூலம் வழங்கப்பட்டு, systemd timer மூலம் தானாகவே புதுப்பிக்கப்படும்; நீங்கள் இதைப் பற்றி மீண்டும் கவலைப்படத் தேவையில்லை. இந்த வேலையைச் செய்யும் கட்டளை ஒரே வரியில் அமையும். தவறுகள் ஏதேனும் நடந்தால், அவை அந்த கட்டளைக்கு முன்பே நடக்கும்: ServerName இல்லாத vhost, provider firewall-ல் மூடப்பட்டிருக்கும் port 80, அல்லது பழைய server-ஐக் குறிக்கும் DNS போன்றவை. எனவே, இந்த வழிகாட்டி முன்தேவைகளுக்கு அதிக முக்கியத்துவம் அளிக்கிறது மற்றும் ஒவ்வொரு தவறும் காட்டும் துல்லியமான பிழைச் செய்திகளைப் பட்டியலிடுகிறது.

இரண்டு குறிப்புகள். உங்கள் web server nginx ஆக இருந்தால், செயல்முறை இதே போன்றதுதான், ஆனால் plugin மற்றும் config கோப்புகள் மாறுபடும்; அதற்குப் பதிலாக இந்த வழிகாட்டியின் nginx பதிப்பைப் பயன்படுத்தவும். நீங்கள் பாதுகாக்கும் தளம் உள் பயன்பாட்டிற்கு மட்டுமே என்றால், அதாவது ஒரு private முகவரியில் உள்ள admin panel அல்லது யாரும் பார்க்காத staging box என்றால், உங்களுக்கு certificate authority தேவையில்லை; self-signed certificate குறைந்த வேலைப்பளு கொண்டது மற்றும் offline-லும் செயல்படும்.

முன்நிபந்தனைகள் மற்றும் Certbot இயங்குவதற்கு முன்பே இது தோல்வியடையும் மூன்று வழிகள்

• Apache ஏற்கனவே உங்கள் தளத்தை plain HTTP மூலம் வழங்கிக்கொண்டிருக்க வேண்டும். Certbot-ன் Apache plugin ஏற்கனவே உள்ள ஒரு தளத்தை மட்டுமே மாற்றியமைக்கும்; அது புதிய தளத்தை உருவாக்காது. நீங்கள் ஒரு புதிய VPS-ல் தொடங்குகிறீர்கள் என்றால், முதலில் Ubuntu 24.04-ல் LAMP stack-ஐ உருவாக்கிவிட்டு மீண்டும் வாருங்கள், இந்த வழிகாட்டி அதன் விடுபட்ட TLS அத்தியாயமாகும்.
• உங்கள் VPS முகவரியில் A record கொண்ட ஒரு பொதுவான domain இருக்க வேண்டும். Let's Encrypt-ன் HTTP-01 challenge என்பது, அவர்களின் சரிபார்ப்பு server-கள் இணையத்திலிருந்து உங்கள் server-ஐத் தொடர்பு கொள்ளும் என்பதாகும்: port forwarding இல்லாத NATed homelab, .local பெயர்கள் அல்லது வெறும் IP முகவரிகள் இதில் வேலை செய்யாது. dig +short example.com உங்கள் VPS முகவரியைக் காட்ட வேண்டும், மேலும் நீங்கள் கடந்த ஒரு மணி நேரத்தில் DNS-ஐ மாற்றியிருந்தால், புதிய record-ஐ வெளியிடும் முன் பழைய record-ன் TTL முடியும் வரை காத்திருக்கவும்.
• AAAA record இருந்தால், அது சரியாக இருக்க வேண்டும். AAAA record வெளியிடப்பட்டிருக்கும்போது Let's Encrypt IPv6-க்கு முன்னுரிமை அளிக்கும், எனவே உங்கள் laptop-ல் (பெரும்பாலும் IPv4-ல்) curl வேலை செய்தாலும், பழைய AAAA record சரிபார்ப்பைத் தோல்வியடையச் செய்யும். சரியான AAAA record-ஐ வெளியிடவும் அல்லது அதை நீக்கிவிடவும்.

Ports 80 மற்றும் 443 ஆகியவற்றை ufw-விலும், உங்கள் provider-ன் network firewall-லும் திறக்க வேண்டும். பெரும்பாலான hosting panel-களில் OS-க்குத் தெரியாத இரண்டாவது firewall ஒன்று இருக்கும். HTTP-01 குறிப்பாக port 80 வழியாகவே சரிபார்க்கும்; இதை 443-ல் மட்டும் இயக்க முடியாது.

sudo ufw allow "Apache Full"
sudo ufw status

இவை சரியாக இருந்தால், முழு வேலையும் பதினைந்து நிமிடங்களில் முடிந்துவிடும், அதில் பத்து நிமிடங்கள் வாசிப்பதற்கே ஆகும்.

Certbot-ஐ Snap மூலம் நிறுவுவதா அல்லது apt மூலம் நிறுவுவதா? 24.04-ல் apt இறுதியாகச் சரியாகச் செயல்படுகிறது

Certbot பல ஆண்டுகளுக்கு முன்பே snap விநியோக முறைக்கு மாறியதற்கு ஒரு முக்கிய காரணம் இருந்தது: distro தொகுப்புகள் காலாவதியாகிவிட்டன. Ubuntu 20.04-ல் Certbot 0.40 மட்டுமே இருந்தது, அது மேம்படுத்தப்படவில்லை. ஐந்து ஆண்டுகள் பழமையான பிழைகளைச் சரிசெய்வதில் திட்டக் குழுவினர் சோர்வடைந்தனர். 24.04-ல் அந்தப் பிரச்சினை இல்லை; அதன் களஞ்சியத்தில் (archive) தற்போதைய தலைமுறை வெளியீடான Certbot 2.9.0 உள்ளது, மேலும் unattended-upgrades அதைத் தொடர்ந்து புதுப்பித்து வருகிறது. இந்த OS-க்கு எனது பரிந்துரை: apt-ஐப் பயன்படுத்தவும். இதன் மூலம் நீங்கள் snapd daemon-ஐத் தவிர்க்கலாம், Apache plugin ஒரே நேரத்தில் நிறுவப்படும், மேலும் renewal timer வழக்கமான Debian முறையில் systemd-உடன் ஒருங்கிணைக்கப்படும்.

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

சரியான முடிவு: certbot 2.9.0. python3-certbot-apache தொகுப்புதான் உங்கள் Apache கோப்புகளைப் படித்து மாற்றியமைக்கும் plugin ஆகும். இது இல்லையென்றால், certbot --apache கட்டளை The requested apache plugin does not appear to be installed பிழையுடன் தோல்வியடையும்.

பின்வரும் இரண்டு சூழல்களில் snap-ஐப் பயன்படுத்துவதே சரியான தேர்வாகும்: உங்களுக்கு Certbot வெளியான அன்றே புதிய பதிப்பு தேவைப்பட்டால், அல்லது snap-ஆக மட்டுமே கிடைக்கும் DNS plugin தேவைப்பட்டால் (பல 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

எந்த முறையைத் தேர்ந்தெடுத்தாலும், இரண்டையும் ஒரே நேரத்தில் இயக்க வேண்டாம். இரண்டு நிறுவல்கள் இருந்தால், இரண்டு renewal scheduler-களும் /etc/letsencrypt-க்காகப் போட்டியிடும். மேலும், உங்கள் shell-ல் காணப்படும் certbot, PATH-ல் உள்ள கோப்புகளுக்கு உரிமையாளராக இல்லாமல் இருக்கலாம். மேலே உள்ள apt remove வரி வெறும் அலங்காரத்திற்காக அல்ல, அது அவசியமானது.

The vhost Certbot edits must already exist, ServerName is the whole game

certbot --apache works by finding the port-80 virtual host whose ServerName or ServerAlias matches each -d domain you pass, proving control of the domain through it, then writing an SSL twin of that vhost. No matching ServerName, no match, and Ubuntu's default 000-default.conf ships with ServerName commented out. That single commented line is the most common reason this guide's one big command fails.

So before touching Certbot, give the site a proper name-based vhost. Create /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>

Enable it and confirm Apache both parses it and routes the name to it:

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

configtest must print Syntax OK. If it also prints AH00558: apache2: Could not reliably determine the server's fully qualified domain name, that is a warning about the global ServerName, not your vhost, harmless here, and silenced by echo "ServerName $(hostname -f)" | sudo tee /etc/apache2/conf-available/servername.conf && sudo a2enconf servername && sudo systemctl reload apache2.

The -S output is the check that matters. You want a line like port 80 namevhost example.com (/etc/apache2/sites-enabled/example.com.conf:1) with alias www.example.com under it, Apache reports the sites-enabled symlink it actually read, not the file you edited in sites-available. If example.com is not listed against port 80, Certbot will not find it either.

சான்றிதழை வெளியிடுதல்: certbot --apache

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

முதல்முறை இயக்கும்போது மூன்று விஷயங்கள் கேட்கப்படும்: மின்னஞ்சல் முகவரி (இது உங்கள் ACME கணக்கிற்கும், அவசரமான CA அறிவிப்புகளுக்கும் பயன்படுத்தப்படும்; Let's Encrypt இனி காலாவதி எச்சரிக்கைகளை அனுப்பாது என்பதால், புதுப்பித்தல்களைக் கண்காணிப்பது உங்கள் பொறுப்பு), 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 நான்கு பணிகளைச் செய்கிறது: Apache-ன் ssl module ஏற்கனவே இயங்கவில்லை என்றால் அதைச் செயல்படுத்துகிறது, *:443-ல் உள்ள உங்கள் vhost-ன் நகலான example.com-le-ssl.conf-ஐ உருவாக்கி, அதில் SSLEngine on மற்றும் சான்றிதழ் பாதைகளைச் சேர்க்கிறது, அதைச் செயல்படுத்துகிறது, மேலும் அசல் port-80 vhost-ல் அனைத்து கோரிக்கைகளையும் HTTPS-க்கு 301 redirect செய்யும் RewriteRule தொகுப்பைச் சேர்க்கிறது. உங்கள் அசல் vhost கோப்பு மாற்றியமைக்கப்படுகிறதே தவிர மாற்றீடு செய்யப்படுவதில்லை, மேலும் SSL நகல் அதன் அருகிலேயே அமைகிறது, அங்கு அது சேர்த்த ஒவ்வொரு வரியையும் நீங்கள் வாசிக்க முடியும்.

சான்றிதழ் உண்மையில் எங்கு சேமிக்கப்படுகிறது மற்றும் அதை ஏன் ஒருபோதும் நகலெடுக்கக்கூடாது

அனைத்து கோப்புகளும் /etc/letsencrypt/live/example.com/-ன் கீழ் அமைகின்றன: fullchain.pem (சான்றிதழ் மற்றும் இடைநிலை சங்கிலி, இதைத்தான் server-கள் சுட்டிக்காட்ட வேண்டும்), privkey.pem (private key, இது root பயனரால் மட்டுமே படிக்கக்கூடியது), மற்றும் cert.pem, chain.pem ஆகியவை தனித்தனி கோப்புகளை எதிர்பார்க்கும் மென்பொருள்களுக்காக உள்ளன. இவை /etc/letsencrypt/archive/-க்குச் செல்லும் symlink-கள் ஆகும். இந்த மறைமுகமான அமைப்பே புதுப்பித்தல் (renewal) பொறிமுறையாகும்: புதுப்பித்தல் நடக்கும்போது, புதிய கோப்புகள் archive/-ல் எழுதப்பட்டு, symlink-கள் மீண்டும் அந்த புதிய கோப்புகளைச் சுட்டிக்காட்டும் வகையில் மாற்றப்படும். பிற மென்பொருள்களை live/ பாதைகளுக்குச் சுட்டிக்காட்டினால், அவை தானாகவே புதுப்பிக்கப்பட்ட சான்றிதழ்களைப் பெற்றுக்கொள்ளும். மாறாக, கோப்புகளை வேறு இடத்திற்கு நகலெடுத்தால், 90 நாட்களுக்குப் பிறகு உங்கள் சேவை முடங்கிவிடும்.

தெரிந்துகொள்ள வேண்டிய மற்றொரு கோப்பு /etc/letsencrypt/renewal/example.com.conf ஆகும். இது இந்தச் சான்றிதழ் எவ்வாறு வழங்கப்பட்டது, authenticator = apache, installer = apache மற்றும் domain-கள் குறித்த விவரங்களைப் பதிவு செய்கிறது. இதன் மூலம், Apache-ஐ மீண்டும் ஏற்றுவது (reload) உட்பட, புதுப்பித்தல் செயல்முறையை எந்தவித மனிதத் தலையீடுமின்றி மீண்டும் செய்ய முடியும்.

புதுப்பித்தல் ஏற்கனவே திட்டமிடப்பட்டுள்ளது, அதைச் சரிபார்க்கவும், புதிதாக உருவாக்க வேண்டாம்

Let's Encrypt certificates வடிவமைப்பின்படி 90 நாட்கள் மட்டுமே செல்லுபடியாகும். apt package ஏற்கனவே இதற்கான வசதியை நிறுவியுள்ளது: ஒரு systemd timer, Certbot-ஐ ஒரு நாளைக்கு இரண்டு முறை சீரற்ற நேரங்களில் இயக்கி, காலாவதியாவதற்கு 30 நாட்களுக்குள் இருக்கும் certificates-ஐப் புதுப்பிக்கும். கூடுதலாக ஒரு cron job-ஐச் சேர்க்க வேண்டாம்; இரண்டாவது scheduler-ஆல் எந்தப் பயனும் இல்லை, அது log கோப்புகளில் தேவையற்ற பதிவுகளையும், rate-limit சிக்கல்களையும் மட்டுமே உருவாக்கும்.

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

முதல் கட்டளை timer செயல்பாட்டில் இருப்பதைக் காட்டுகிறது. அடுத்த இயக்கம் (NEXT) வரும் 24 மணி நேரத்திற்குள் இருக்கும். இது சீரற்ற தாமதத்துடன் ஒரு நாளைக்கு இரண்டு முறை இயங்கும் வகையில் திட்டமிடப்பட்டுள்ளது, எனவே சரியான நேரம் முன்கூட்டியே கணிக்க முடியாதபடி இருக்கும் (snap install-ல், timer என்பது snap.certbot.renew.timer ஆக இருக்கும்). dry run என்பது Let's Encrypt-ன் staging சூழலில் முழுமையான புதுப்பித்தல் ஒத்திகையைச் செய்யும்; இது உண்மையான சவாலைச் சந்திக்கும், ஆனால் certificate வழங்கப்படாது, rate-limit பாதிப்பும் ஏற்படாது. சரியான முடிவு இதனுடன் முடிவடையும்:

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

dry run தோல்வியடைந்தால், சுமார் 60 நாட்களில் நடக்கவிருக்கும் உண்மையான புதுப்பித்தலும் அதே காரணத்தால் தோல்வியடையும். தற்போதைய certificate-ன் ஆயுட்காலம் முழுமையாக இருக்கும்போதே அதைச் சரிசெய்யவும். பொதுவாக, certificate வழங்கப்பட்ட பிறகு சேர்க்கப்பட்ட firewall விதி, 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 வரியும், R12 அல்லது E7 போன்ற குறுகிய CN-ம், மற்றும் சுமார் 90 நாட்கள் காலாவதி தேதியைக் கொண்ட notAfter-ம் இருக்கும். உலாவியில் (browser) உங்களுக்கு padlock சின்னம் கிடைக்கும், அதை கிளிக் செய்தால் அதே issuer-ஐக் காணலாம். curl சரியாக வேலை செய்து, உலாவி எச்சரிக்கை விடுத்தால், நீங்கள் பெரும்பாலும் cached பக்கத்தையோ அல்லது தவறான hostname-ஐயோ பார்க்கிறீர்கள் என்று அர்த்தம்; இது certificate பிரச்சினை அல்ல.

பல தளங்கள்: ஒரு SAN certificate அல்லது ஒவ்வொரு தளத்திற்கும் ஒரு certificate

இரண்டு முறைகளும் வேலை செய்யும்; அவை ஒரே முறையில் புதுப்பிக்கப்படும். ஒரே server-ல் தொடர்பில்லாத தளங்கள் இருந்தால், ஒவ்வொரு தளத்திற்கும் தனித்தனியாக issue கட்டளையை இயக்கவும். ஒவ்வொன்றும் live/-ன் கீழ் தனித்தனி directory-யையும், தனித்தனி renewal configuration-ஐயும் பெறும். ஒரு domain-ல் ஏற்படும் சிக்கல் மற்றவற்றின் புதுப்பித்தலை ஒருபோதும் தடுக்காது. இதுவே எனது இயல்புநிலை முறையாகும்.

பல பெயர்களைக் கொண்ட ஒரு தளத்திற்கு, அவற்றை ஒரே SAN certificate-ல் வைக்கவும்; ஒரு single 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 பட்டியலில் ஏற்பட்டுள்ள மாற்றத்தைக் கவனித்து, அதை விரிவுபடுத்த உறுதிப்படுத்துமாறு கேட்கும். பின்னர், அதே live/ பாதையில் certificate-ஐ மாற்றியமைக்கும், எனவே வேறு எதையும் மாற்ற வேண்டியதில்லை. இந்தப் பட்டியல் பழையதை மாற்றுமே தவிர, புதியதை மட்டும் சேர்க்காது என்பதை கவனத்தில் கொள்க: அந்த கட்டளையிலிருந்து www-ஐ விடுபடச் செய்தால், புதிய certificate-லிருந்து அது நீக்கப்படும்.

Wildcards-க்கு DNS-01 தேவை, பொதுவாக உங்களுக்கு wildcard தேவையில்லை

HTTP-01 மூலம் *.example.com-ஐ வழங்க முடியாது. ஒரு web server-ல் கோப்பை வைப்பது அந்த குறிப்பிட்ட hostname-ஐ மட்டுமே கட்டுப்படுத்துவதை உறுதிப்படுத்தும், முழு namespace-ஐயும் அல்ல. Wildcards-க்கு DNS-01 challenge தேவை: Certbot ஆனது _acme-challenge.example.com-ல் ஒரு TXT record-ஐ அமைக்கும். நடைமுறையில் இதற்கு உங்கள் DNS provider-ன் API credentials கொண்ட ஒரு certbot-dns-* plugin தேவைப்படும், அல்லது ஒவ்வொரு முறையும் --manual மூலம் கைமுறையாக TXT record-களை மாற்ற வேண்டியிருக்கும் (இது மிகவும் கடினமானது, இதைத் தவிர்க்கவும்). TXT record செயல்பாடுகள் முதல் தானாகவே புதுப்பிக்கும் plugin வரை அனைத்தையும் DNS-01 மூலம் Certbot-ல் wildcard certificates என்பதில் விரிவாகக் காணலாம். ஒரு நேர்மையான ஆலோசனை: உங்களிடம் நான்கு subdomains இருந்தால், நான்கையும் உள்ளடக்கிய ஒரு SAN certificate-ஐப் பயன்படுத்துவது wildcard-ஐ விட எளிதானது; இதற்கு server-ல் DNS API keys வைத்திருக்க வேண்டிய அவசியமில்லை.

தோல்விக்கான காரணங்கள் மற்றும் நீங்கள் காணும் செய்திகள்

Apache-ன் கட்டமைப்பு (config) சிதைந்துள்ளதால் 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, அல்லது enable செய்யப்படாத ஒரு module-ஐக் குறிப்பிடுவது போன்ற காரணங்களால் இது நிகழும். அது Syntax OK என்று காட்டும் வரை பிழைகளைச் சரிசெய்துவிட்டு, மீண்டும் Certbot-ஐ இயக்கவும்.

Domain-க்கு இணையான vhost எதுவும் இல்லை.

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

இது முன்னரே குறிப்பிட்ட, விடுபட்ட ServerName-ஆல் ஏற்படும் தோல்வியாகும். Certbot உங்கள் -d-க்கு இணையான ServerName/ServerAlias உள்ளதா என, enable செய்யப்பட்ட அனைத்து port-80 vhost-களிலும் தேடி, எதுவும் கிடைக்காதபோது இவ்வாறு நிகழும். Apache எங்கு traffic-ஐ அனுப்புகிறது என்பதை sudo apache2ctl -S காட்டும்; சரியான vhost-ல் ServerName வரியைச் சேர்த்து, reload செய்து மீண்டும் முயற்சிக்கவும். இதேபோன்ற மற்றொரு சிக்கல், validation தவறான vhost-க்குச் செல்வது; மற்றொரு தளம் கோரிக்கையை ஏற்றுக்கொள்வதால், challenge response Invalid response ... 404 என்று வரும். இதற்கும் அதே தீர்வு மற்றும் அதே கருவிதான்: apache2ctl -S.

Validation காலாவதியாகிறது (times out).

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

உங்கள் DNS காட்டும் முகவரியில், port 80-ல் TCP இணைப்பை Let's Encrypt-ஆல் ஏற்படுத்த முடியவில்லை. நிகழ்தகவு வரிசையில்: உங்கள் hosting panel-ல் உள்ள network firewall (இது ufw-லிருந்து தனிப்பட்டது), 443 அல்லது SSH-க்கு மட்டும் அனுமதி அளிக்கும் ufw விதிகள், DNS இன்னும் பழைய server-ஐக் காட்டுவது, அல்லது stale-AAAA சிக்கல் (அவர்கள் IPv6-ல் முயல்கிறார்கள், உங்கள் server IPv4-ல் மட்டுமே பதிலளிக்கிறது). VPS-க்கு வெளியிலிருந்து சோதிக்கவும்: உங்கள் laptop-லிருந்து curl -I http://example.com-ஐ இயக்கினால், அவர்களின் validator எதைக் காண்கிறது என்பதை நீங்களும் அறியலாம்.

மீண்டும் மீண்டும் முயன்றதால் rate limit-ல் சிக்கியுள்ளீர்கள்.

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

ஒரு மணி நேரத்திற்கு, ஒரு hostname-க்கு, ஒரு account-க்கு 5 முறை மட்டுமே தோல்வியடைந்த validation-களை Let's Encrypt அனுமதிக்கிறது. 2025-ன் rate-limit மாற்றத்திற்குப் பிறகு, இது ஒரு நிரப்பப்படும் வாளி (refilling bucket) போல செயல்படுகிறது; ஒவ்வொரு 12 நிமிடத்திற்கும் ஒரு முயற்சி மீண்டும் கிடைக்கும். பழுதடைந்த firewall-ல் தொடர்ந்து முயற்சி செய்வது இந்த வரம்பை விரைவாகக் காலி செய்துவிடும். காத்திருப்பது ஒரு தீர்வுதான், ஆனால் உண்மையான தீர்வு உங்கள் அணுகுமுறையில் உள்ளது: ஏதேனும் தோல்வி ஏற்பட்டால், வெற்றி பெறும் வரை staging environment-ல் debug செய்யவும்.

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

certonly-ஐ கவனிக்கவும்: --dry-run என்பது certonly மற்றும் renew subcommands-களால் மட்டுமே ஏற்றுக்கொள்ளப்படும். வெறும் certbot --apache --dry-run வடிவம் இயங்க மறுத்து, --dry-run currently only works with the 'certonly' or 'renew' subcommands என்று செய்தி காட்டும். Dry run என்பது staging-ல் சரிபார்க்கும்; இதற்கு தாராளமான வரம்புகள் உண்டு மற்றும் இது உண்மையான certificates-ஐ வழங்காது, எனவே நீங்கள் நாள் முழுவதும் அங்கு தோல்வியடையலாம். Staging-ல் வெற்றி பெற்ற பிறகு மட்டுமே உண்மையான கட்டளையை மீண்டும் இயக்கவும். மற்ற வரம்புகள், அதாவது ஒரு வாரத்திற்கு ஒரு domain-க்கு 50 certificates, அல்லது ஒரே பெயருடைய தொகுப்பிற்கு வாரத்திற்கு 5 நகல்கள் போன்றவை, ஒரு script loop-ல் இயங்கினால் மட்டுமே நீங்கள் எதிர்கொள்ள நேரிடும்.

HTTPS செயல்பாட்டிற்கு வந்தவுடன், certificate என்பது போக்குவரத்தை (transport) மட்டுமே பாதுகாக்கிறது, server-ஐ அல்ல என்பதை நினைவில் கொள்க: port 22-ல் கடவுச்சொல் ஊகங்கள் (password guesses) தொடர்ந்து நடக்கலாம். இதை 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 plugin தேவைப்பட்டால் மட்டுமே snap-ஐத் தேர்ந்தெடுக்கவும். நீங்கள் snap-க்கு மாறினால், இரண்டு renewal schedulers-ம் ஒரே நேரத்தில் இயங்குவதைத் தவிர்க்க, முதலில் apt remove certbot python3-certbot-apache செய்யவும்.

Certbot ஏன் "Unable to find a virtual host listening on port 80" என்று காட்டுகிறது?

ஏனெனில், -d மூலம் நீங்கள் குறிப்பிட்ட domain-க்கு இணையான ServerName அல்லது ServerAlias கொண்ட, enabled நிலையில் உள்ள port-80 vhost எதுவும் இல்லை. Ubuntu-வின் default vhost-ல் ServerName comment செய்யப்பட்டிருக்கும். sudo apache2ctl -S-ஐ இயக்கவும், அந்த domain-க்கு உரிய vhost-ஐக் கண்டறியவும் (அல்லது உருவாக்கவும்), ServerName example.com-ஐச் சேர்க்கவும், Apache-ஐ reload செய்யவும், பிறகு Certbot-ஐ மீண்டும் இயக்கவும்.

"Timeout during connect (likely firewall problem)" பிழையை எவ்வாறு சரிசெய்வது?

உங்கள் DNS குறிப்பிடும் முகவரியில் உள்ள port 80-ஐ Let’s Encrypt-ஆல் அணுக முடியவில்லை. உங்கள் provider-ன் panel-level network firewall மற்றும் ufw ஆகியவற்றைச் சரிபார்க்கவும். dig +short example.com இந்த VPS-ஐக் காட்டுகிறதா என்பதை உறுதிப்படுத்தவும். பழைய AAAA record ஏதேனும் இருந்தால் அதை நீக்கவும் அல்லது திருத்தவும், ஏனெனில் IPv6 இருந்தால் validation அதற்கு முன்னுரிமை அளிக்கும். curl -I http://example.com மூலம் server-க்கு வெளியிலிருந்து இந்தத் திருத்தத்தைச் சரிபார்க்கவும், பிறகு உண்மையான issuance-க்கு முன் sudo certbot certonly --apache --dry-run -d example.com மூலம் ஒத்திகை பார்க்கவும்.

Ubuntu 24.04-ல் Certbot சான்றிதழ்களைத் தானாகவே புதுப்பிக்குமா?

ஆம். apt package certbot.timer-ஐ நிறுவுகிறது. இது ஒரு systemd timer ஆகும்; இது தினமும் இருமுறை இயங்கி, காலாவதியாவதற்கு 30 நாட்களுக்குள் இருக்கும் சான்றிதழ்களைப் புதுப்பித்து, அதன் பிறகு Apache-ஐ reload செய்யும். snap பதிப்பு இதே பணிக்காக snap.certbot.renew.timer-ஐப் பயன்படுத்துகிறது. systemctl list-timers certbot.timer மூலம் இதைச் சரிபார்க்கவும், sudo certbot renew --dry-run மூலம் ஒத்திகை பார்க்கவும். நீங்களாகவே தனியாக cron job எதையும் சேர்க்க வேண்டாம்.

Certbot மற்றும் Apache மூலம் wildcard சான்றிதழை எவ்வாறு பெறுவது?

Wildcard-களுக்கு DNS-01 challenge தேவைப்படுகிறது: Certbot ஒரு TXT record-ஐ _acme-challenge.example.com-ல் பதிவிட வேண்டும். இதற்கு உங்கள் DNS provider-க்கான API credentials கொண்ட certbot-dns-* plugin தேவைப்படும் (--manual மாற்றாக இருந்தால், ஒவ்வொரு முறை புதுப்பிக்கும்போதும் TXT record-களை நீங்களே கைமுறையாகத் திருத்த வேண்டியிருக்கும்). உங்களுக்குச் சில குறிப்பிட்ட subdomains மட்டுமே இருந்தால், அவற்றை வெளிப்படையாகக் குறிப்பிடும் SAN சான்றிதழ் எளிதானது மற்றும் இது DNS API keys-ஐ server-ல் வைக்க வேண்டிய அவசியத்தைக் குறைக்கிறது.