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

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

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

இரண்டு முக்கிய குறிப்புகள். உங்கள் web server nginx எனில், செயல்முறை இதே வடிவில்தான் இருக்கும், ஆனால் plugin மற்றும் configuration கோப்புகள் மாறுபடும்; அதற்குப் பதிலாக இந்த வழிகாட்டியின் nginx பதிப்பைப் பயன்படுத்தவும். நீங்கள் பாதுகாக்கும் தளம் உள் பயன்பாட்டிற்கு மட்டுமே என்றால், அதாவது ஒரு private address-ல் உள்ள 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 கொண்ட ஒரு பொது டொமைன் (public domain) இருக்க வேண்டும். Let's Encrypt-ன் HTTP-01 challenge என்பது, அவர்களின் சரிபார்ப்பு server-கள் இணையத்திலிருந்து உங்கள் server-ஐத் தொடர்பு கொள்ளும் என்பதாகும்: port forwarding இல்லாத NATed homelab, .local பெயர்கள் அல்லது வெறும் IP முகவரிகள் இதில் வேலை செய்யாது. dig +short example.com உங்கள் VPS முகவரியைக் காட்ட வேண்டும், மேலும் நீங்கள் கடந்த ஒரு மணி நேரத்தில் DNS-ஐ மாற்றியிருந்தால், சான்றிதழைப் பெறுவதற்கு முன் பழைய record-ன் TTL முடியும் வரை காத்திருக்கவும்.
• AAAA record இருந்தால், அது சரியாக இருக்க வேண்டும். AAAA record வெளியிடப்பட்டிருக்கும்போது Let's Encrypt IPv6-க்கு முன்னுரிமை அளிக்கும், எனவே உங்கள் மடிக்கணினியிலிருந்து curl (பெரும்பாலும் IPv4-ல்) சரியாக வேலை செய்தாலும், பழைய AAAA record சரிபார்ப்பைத் தோல்வியடையச் செய்யும். சரியான AAAA record-ஐ வெளியிடவும் அல்லது அதை நீக்கிவிடவும்.

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

sudo ufw allow "Apache Full"
sudo ufw status

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

Snap அல்லது apt Certbot? 24.04-ல் apt பயன்படுத்துவது சிறந்தது

Certbot பல ஆண்டுகளுக்கு முன்பே snap விநியோக முறைக்கு மாறியதற்கு ஒரு முக்கிய காரணம் இருந்தது: distro packages காலாவதியாகிவிட்டன. Ubuntu 20.04-ல் Certbot 0.40 மட்டுமே இருந்தது, அது மேம்படுத்தப்படவில்லை. ஐந்து ஆண்டுகள் பழமையான பிழைகளை சரிசெய்வதில் Certbot குழு சோர்வடைந்தது. 24.04-ல் அந்த சிக்கல் இல்லை; அதன் archive-ல் தற்போதைய பதிப்பான Certbot 2.9.0 உள்ளது, மேலும் unattended-upgrades அதைத் தொடர்ந்து புதுப்பித்து வருகிறது. இந்த 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 வெளியான அன்றே அதன் புதிய பதிப்பு உங்களுக்குத் தேவைப்பட்டால், அல்லது 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-ல் உள்ள அதே பதிப்பாக இருக்காது, அது உங்கள் certificates-ஐக் கட்டுப்படுத்தாமல் போகலாம். மேலே உள்ள apt remove வரி வெறும் அலங்காரத்திற்காக அல்ல, அது அவசியமானது.

Certbot திருத்தும் vhost ஏற்கனவே இருக்க வேண்டும், ServerName தான் இதில் மிக முக்கியமானது

certbot --apache, நீங்கள் குறிப்பிடும் ஒவ்வொரு -d டொமைனுக்கும் பொருத்தமான ServerName அல்லது ServerAlias கொண்ட port-80 virtual host-ஐக் கண்டறிவதன் மூலம் செயல்படுகிறது. இது அந்த டொமைன் மீதான உங்கள் கட்டுப்பாட்டை உறுதிசெய்து, அந்த vhost-க்கு ஒரு SSL நகலை உருவாக்குகிறது. பொருத்தமான ServerName இல்லையென்றால், பொருத்தம் ஏற்படாது. Ubuntu-வின் இயல்புநிலை 000-default.conf-ல் ServerName கருத்துரைக்கப்பட்டு (commented out) இருக்கும். அந்த ஒரு வரியை நீக்காமல் விடுவதே, இந்த வழிகாட்டியில் உள்ள முக்கிய கட்டளை தோல்வியடைவதற்கு மிகவும் பொதுவான காரணமாகும்.

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 configuration-ஐ செயல்படுத்துதல்

இதை enable செய்து, Apache இதை சரியாக parse செய்கிறதா என்பதையும், அந்தப் பெயரை அதற்கு routing செய்கிறதா என்பதையும் உறுதிப்படுத்தவும்:

1. a2ensite கட்டளையைப் பயன்படுத்தி configuration file-ஐ enable செய்யவும்:

sudo a2ensite your-config-file.conf

1. Apache configuration-ல் ஏதேனும் பிழைகள் உள்ளதா எனச் சரிபார்க்கவும்:

sudo apache2ctl configtest

1. மாற்றங்கள் நடைமுறைக்கு வர Apache-ஐ reload செய்யவும்:

sudo systemctl reload apache2

1. curl அல்லது browser மூலம் அந்த domain-க்கு request அனுப்பி, routing சரியாகச் செயல்படுகிறதா என்பதைச் சரிபார்க்கவும்:

curl -I http://your-domain.com

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) போன்ற ஒரு வரியை நீங்கள் பார்க்க வேண்டும். நீங்கள் sites-available-ல் திருத்திய கோப்பை அல்ல, Apache உண்மையில் வாசித்த sites-enabled symlink-ஐயே அது காட்டுகிறது. 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 உடன் பகிர விருப்பமா என்பது. இனி 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-ன் நகலை SSLEngine on மற்றும் சான்றிதழ் பாதைகளுடன் example.com-le-ssl.conf என்ற பெயரில் உருவாக்கியது, அதை இயக்கியது, மேலும் அசல் 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 தொகுப்பு ஏற்கனவே இதற்கான வசதியை நிறுவியுள்ளது: ஒரு systemd timer, Certbot-ஐ ஒரு நாளைக்கு இரண்டு முறை சீரற்ற நேரங்களில் இயக்கி, காலாவதியாவதற்கு 30 நாட்களுக்குள் இருக்கும் சான்றிதழ்களைப் புதுப்பிக்கும். கூடுதலாக ஒரு cron job-ஐச் சேர்க்க வேண்டாம்; இரண்டாவது scheduler தேவையற்ற log பதிவுகளையும், rate-limit சிக்கல்களையும் மட்டுமே உருவாக்கும்.

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

முதல் கட்டளை timer செயல்பாட்டில் இருப்பதைக் காட்டுகிறது. அடுத்த இயக்கம் அடுத்த 24 மணி நேரத்திற்குள் இருக்கும். இது ஒரு நாளைக்கு இரண்டு முறை சீரற்ற தாமதத்துடன் திட்டமிடப்பட்டுள்ளதால், சரியான நேரம் கணிக்க முடியாததாக இருக்கும் (snap install-ல், timer 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 மூலம் சரிபார்த்தல் மற்றும் 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 இருக்கும், மேலும் notAfter சுமார் 90 நாட்கள் காலாவதி தேதியைக் காட்டும். உலாவியில் (browser) உங்களுக்கு padlock குறியீடு கிடைக்கும், அதை கிளிக் செய்தால் அதே issuer-ஐக் காணலாம். curl சரியாக வேலை செய்து, உலாவி எச்சரிக்கை விடுத்தால், நீங்கள் பெரும்பாலும் cache செய்யப்பட்ட பக்கத்தையோ அல்லது தவறான 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 தொகுப்பைக் கவனித்து, அதை விரிவுபடுத்த உறுதிப்படுத்துமாறு கேட்கும். அது certificate-ஐ அதே இடத்தில், அதே live/ பாதையில் மாற்றியமைக்கும், எனவே வேறு எதையும் மாற்ற வேண்டியதில்லை. இந்தப் பட்டியல் சேர்ப்பதற்கானது அல்ல, மாற்றீடு செய்வதற்கானது என்பதை கவனத்தில் கொள்க: அந்த கட்டளையிலிருந்து 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 இருந்தால், wildcard-ஐ விட அந்த நான்கையும் உள்ளடக்கிய ஒரு SAN certificate எளிதானது; இதற்கு 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 பிழையின் 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 தோல்வியாகும். இது சான்றிதழ் கோரும்போது கண்டறியப்படுகிறது. உங்கள் -d-க்கு பொருந்தும் ServerName/ServerAlias உள்ளதா என, enable செய்யப்பட்ட அனைத்து port-80 vhost-களிலும் Certbot தேடும்; எதுவும் கிடைக்கவில்லை என்றால் இந்தத் தோல்வி ஏற்படும். sudo apache2ctl -S மூலம் Apache எங்கு traffic-ஐ அனுப்புகிறது என்பதைப் பார்க்கலாம்; சரியான vhost-ல் ServerName வரியைச் சேர்த்து, reload செய்து, மீண்டும் முயற்சிக்கவும். இதே போன்ற மற்றொரு சிக்கல், validation தவறான vhost-க்குச் செல்வது; மற்றொரு தளம் கோரிக்கையை ஏற்றுக்கொள்வதால், பதில் 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 சிக்கல் (அவர்களின் server 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-க்கு 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-ல் சரிபார்க்கும்; இதற்கு தாராளமான வரம்புகள் உண்டு மற்றும் உண்மையான சான்றிதழ்கள் வழங்கப்படாது, எனவே நீங்கள் நாள் முழுவதும் அங்கு தோல்வியடையலாம். Staging-ல் வெற்றி பெற்ற பிறகு மட்டுமே உண்மையான கட்டளையை மீண்டும் இயக்கவும். ஒரு வாரத்திற்கு ஒரு domain-க்கு 50 சான்றிதழ்கள், ஒரு வாரத்திற்கு 5 நகல்கள் போன்ற பிற வரம்புகள், ஏதேனும் script loop-ல் சான்றிதழை மீண்டும் மீண்டும் கோரினால் மட்டுமே ஏற்படும்.

HTTPS செயல்பாட்டிற்கு வந்தவுடன், சான்றிதழ் 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 தேவையில்லை. மிகப்புதிய release உடனடியாகத் தேவைப்பட்டாலோ அல்லது snap-ஆக மட்டுமே கிடைக்கும் DNS plugin தேவைப்பட்டாலோ மட்டுமே snap-ஐத் தேர்ந்தெடுக்கவும். நீங்கள் மாறினால், முதலில் apt remove certbot python3-certbot-apache செய்யவும், அப்போதுதான் இரண்டு renewal schedulers-ம் ஒரே நேரத்தில் இயங்காது.

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 தானாகவே certificates-ஐப் புதுப்பிக்குமா?

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

Certbot மற்றும் Apache மூலம் wildcard certificate-ஐ எவ்வாறு பெறுவது?

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