SSD Nodes Learn
கல்வி வழிகாட்டிகள் Matt Connorஆல் Matt Connor · புதுப்பிக்கப்பட்டது 2026-07-25

Ubuntu 24.04 nginx Certbot install செய்வது எப்படி

sudo apt install certbot python3-certbot-nginx உடன் certbot --nginx இயக்கி Let's Encrypt சான்றிதழ் பெறுவதற்கான முழு வழி. apt vs snap வேறுபாடும் port 80 timeout பிரச்சினையும் விளக்கமாக.

Certbot நிறுவுதல்: apt அல்லது snap

Ubuntu 24.04 இல், sudo apt install certbot python3-certbot-nginx உண்மையான, பொதுவாக நம்பகமான Let's Encrypt சான்றிதழ்களை வழங்கும் செயல்படும் Certbot ஐத் தருகிறது. Certbot இன் மேலோடை ஆவணங்கள் உங்களை snap நோக்கி வழிநடத்துகின்றன. வேறுபாடு குறைவாகவே உள்ளது — snap ஆனது மேலோடை வெளியீடுகளைக் கண்காணிக்கிறது; காப்பகத் தொகுப்பானது LTS உடன் வந்த பதிப்பைக் கண்காணித்து, பாதுகாப்புத் திருத்தங்களைப் பெறுகிறது.

ஒன்றைத் தேர்ந்தெடுக்கவும். Certbot இன் இரண்டு நகல்கள் என்பது ஒரே /etc/letsencrypt மரத்தை நோக்கி செயல்படும் இரண்டு புதுப்பித்தல் டைமர்கள் என்று பொருள். நீங்கள் மறந்துவிட்ட அந்த டைமர் தான் உங்களுக்குத் தற்செயலான பிரச்சினையை ஏற்படுத்தும்.

apt வழி:

sudo apt update
sudo apt install certbot python3-certbot-nginx

இது /usr/bin/certbot, nginx செருகுநிரல், ஒரு certbot.service + certbot.timer ஜோடி, மற்றும் systemd கீழ் எந்தச் செயலும் செய்யாத ஒரு /etc/cron.d/certbot உள்ளீட்டை நிறுவுகிறது.

snap வழி:

sudo apt remove certbot python3-certbot-nginx
sudo snap install core && sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

snap தனக்கெனத் தனியான டைமரான snap.certbot.renew.timer ஐக் கொண்டு வருகிறது. snap ஐ நிறுவுவதற்கு முன்பு apt தொகுப்பை அகற்றவும்.

நிறுவிய பிறகு இரண்டும் ஒரே மாதிரி செயல்படுகின்றன. Certbot 2.x இயல்புநிலையாக ECDSA (P-256) விசைகளைப் பயன்படுத்துகிறது — ECDSA ஐ ஆதரிக்காத வாடிக்கையாளருக்கு மட்டுமே --key-type rsa ஐப் பயன்படுத்தவும். அனைத்து நிலைத் தரவும் /etc/letsencrypt கீழ் உள்ளது: archive/ உண்மையான விசை மற்றும் சான்றிதழ் கோப்புகளைக் கொண்டுள்ளது, live/ தற்போதைய கோப்புகளுக்கான குறியீட்டு இணைப்புகள், renewal/ ஒவ்வொரு சான்றிதழுக்கும் ஒரு உள்ளமைவுக் கோப்பு, accounts/ உங்கள் ACME கணக்கு விசை.

HTTP-01 உண்மையில் என்ன செய்கிறது, மேலும் port 80 ஏன் விருப்பத்தேர்வு அல்ல

HTTP-01 சவால் ஒரு கால்பேக் ஆகும். நீங்கள் Let's Encrypt-இடம் example.com-ஐ உள்ளடக்கிய சான்றிதழைக் கோருகிறீர்கள். அது பொது DNS-இல் பெயரைத் தீர்க்கிறது, கண்டுபிடிக்கும் முகவரியில் port 80-க்கு இணைப்பைத் திறக்கிறது, மேலும் http://example.com/.well-known/acme-challenge/<token>-ஐக் கோருகிறது. உங்கள் சேவையகம் Certbot இப்போது தான் வட்டில் எழுதிய சரியான டோக்கன் உள்ளடக்கத்துடன் பதிலளிக்கிறது. இதுதான் முழு வழிமுறையும். இதிலிருந்து மூன்று விளைவுகள் உருவாகின்றன. அவைதான் பெரும்பாலான தோல்வியுற்ற சான்றிதழ் வழங்கல்களுக்குக் காரணம்.

  • Port 80 பொது இணையத்திலிருந்து அணுகக்கூடியதாக இருக்க வேண்டும், வெறுமனே உங்கள் மடிக்கணினியிலிருந்து அல்ல. ஒரு ufw விதி, கிளவுட் வழங்குநர் பாதுகாப்புக் குழு, அல்லது வெறும் 443-ஐ மட்டுமே திறக்கும் VPS-கன்சோல் ஃபயர்வால் ஆகியவை சான்றிதழ் வழங்கலையும் அதனுடன் ஒவ்வொரு எதிர்கால புதுப்பித்தலையும் தோல்வியடையச் செய்கின்றன.
  • DNS ஏற்கனவே இந்தச் சேவையகத்தை நோக்கி இருக்க வேண்டும். சரிபார்ப்பு சேவையகம் வெளியிலிருந்து தனக்குச் சொந்தமான தேடலைச் செய்கிறது; உங்கள் /etc/hosts உள்ளீடுகள் மற்றும் உலாவி கேச் ஆகியவை அதற்கு ஒரு பொருட்டே அல்ல.
  • நீங்கள் ஒரு AAAA ரெக்கார்டை வெளியிட்டால், IPv6 முதலில் முயற்சிக்கப்படுகிறது. IPv6 இணைப்பு முற்றிலுமாகத் தோல்வியடையும்போது Let's Encrypt IPv4 வழியாக மீண்டும் முயற்சிக்கிறது — ஆனால் இணைப்பை ஏற்றுக்கொண்டு வேறு ஏதாவது ஒன்றை வழங்கும் ஹோஸ்ட்டை நோக்கிய பழைய AAAA உங்களுக்கு கடுமையான தோல்வியைத் தருகிறது.

திருப்பிவிடுதல்கள் அனுமதிக்கப்படுகின்றன: சரிபார்ப்பு ஒரு HTTP திருப்பிவிடுதலை HTTPS-க்குப் பின்தொடர்கிறது, மேலும் மறுமுனையில் உள்ள சான்றிதழ் இல்லையென்றாலோ, காலாவதியானதாக இருந்தாலோ அல்லது சுய-கையொப்பமிடப்பட்டதாக இருந்தாலோ அதைப் பற்றி கவலைப்படுவதில்லை. அது செய்யாத ஒன்று, port 80-க்கு பதிலாக வேறு எங்கிருந்தும் தொடங்குவது இல்லை. Certbot-க்கு TLS-ALPN-01 செயலாக்கம் இல்லை, எனவே "வெறும் 443-ஐப் பயன்படுத்து" என்பது ஒரு தப்பிக்கும் வழி அல்ல.

அங்கீகரிப்பவரைத் தேர்ந்தெடுத்தல்: --nginx, --webroot, --standalone

--nginx ஆனது, nginx ஏற்கனவே இயங்கிக்கொண்டு அந்த டொமைனைச் சேவையளித்துக்கொண்டிருக்கும்போது சரியான இயல்புநிலை முறையாகும். Certbot உங்கள் கட்டமைப்பைப் பகுப்பாய்வு செய்கிறது. ஒரு தற்காலிக சவால் இருப்பிடத்தை உள்ளீடு செய்கிறது. nginx-ஐ மீண்டும் ஏற்றுகிறது. சரிபார்க்கிறது. பிறகு TLS கட்டளைகளை உங்கள் server block-க்குள் எழுதுகிறது. இடைநிறுத்தம் ஏதும் இல்லை.

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

புதிய சேவையகத்திற்கான கட்டளை நிரல்:

sudo certbot --nginx \
  -d example.com -d www.example.com \
  --agree-tos -m ops@example.com --no-eff-email \
  --redirect --non-interactive

--webroot ஆனது, நீங்கள் Certbot-ஐ உங்கள் nginx கட்டமைப்பின் அருகில் கொண்டுவர விரும்பாதபோது சரியான முறையாகும் — அதாவது நீங்கள் ஒரு டெம்ப்ளேட்டிலிருந்து உருவாக்கி, git-ல் வைத்திருக்கும், அல்லது Ansible மூலம் தள்ளும் கட்டமைப்பு. Certbot சவால் கோப்பை மட்டும் எழுதுகிறது. அது நீங்கள் ஏற்கனவே சேவையளிக்கும் ஒரு கோப்பகத்திற்குள் எழுதப்படுகிறது.

sudo certbot certonly --webroot -w /var/www/example.com \
  -d example.com -d www.example.com \
  --deploy-hook "systemctl reload nginx"

--standalone ஆனது, port 80-ல் எதுவும் கேட்காதபோது சரியான முறையாகும்: ஒரு மின்னஞ்சல் சேவையகம், 443-ல் மட்டுமே பேசும் ஒரு API, nginx இருப்பதற்கு முன்பே இயங்கும் ஒரு முதல்-துவக்க கட்டளை நிரல். Certbot port 80-ஐ சில வினாடிகளுக்குத் தானே பிணைக்கிறது. nginx இயங்கிக்கொண்டிருந்தால், இது தோல்வியடைகிறது — இயக்கத்தின் போது அதை நிறுத்தவும்:

sudo certbot certonly --standalone -d mail.example.com \
  --pre-hook "systemctl stop nginx" \
  --post-hook "systemctl start nginx"

இந்த hook-கள் சான்றிதழின் புதுப்பித்தல் கட்டமைப்பில் பதிவு செய்யப்படுகின்றன. எனவே புதுப்பித்தலின்போது இதே நிறுத்தம்/தொடக்கம் கண்காணிப்பின்றி நிகழ்கிறது.

சான்றிதழ் இருக்கும் முன்னும் பின்னும் செயல்படும் ஒரு server block

காரண-விளைவு சிக்கல்: இல்லாத கோப்பை ssl_certificate சுட்டிக்காட்டி இருந்தால் nginx தொடங்க மறுக்கிறது. nginx நிறுத்தமாக இருந்தால் Certbot சரிபார்க்க முடியாது. முதலில் தளத்தை port 80 இல் இயக்கவும்.

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    root /var/www/example.com;
    index index.html;

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/example.com;
        default_type "text/plain";
        try_files $uri =404;
    }

    location / {
        try_files $uri $uri/ =404;
    }
}

sudo nginx -t && sudo systemctl reload nginx ஐ இயக்கவும். பெட்டிக்கு வெளியில் இருந்து curl -I http://example.com/ பதிலளிக்கிறதா என உறுதி செய்துகொள்ளவும். பிறகு சான்றிதழை வழங்கவும். அதன் பின்னர்:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/example.com;
        default_type "text/plain";
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    root /var/www/example.com;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

ACME location இல் உள்ள ^~ முன்னொட்டு ஒரு முக்கிய பணியைச் செய்கிறது: அது return 301 block சவால் கோரிக்கையை விழுங்குவதைத் தடுக்கிறது. அந்த location ஐ port 80 இல் வைத்திருப்பதால், தளத்தின் மீதி பகுதிகள் HTTPS மட்டும் என மாறிய பிறகும் புதுப்பித்தல்கள் தொடர்ந்து செயல்படும்.

HTTP/2 தொடரியல் உங்கள் nginx பதிப்பைப் பொறுத்தது. இரண்டு வடிவங்களையும் கலந்தால் தொடக்கப் பிழை ஏற்படும். Ubuntu 24.04 இல் nginx 1.24 உள்ளது; அது இன்லைன் வடிவத்தை எதிர்பார்க்கிறது — listen 443 ssl http2;. Debian 13 புதிய nginx ஐக் கொண்டுள்ளது; அது தனி http2 on; directive ஐ எதிர்பார்க்கிறது. முதலில் nginx -v ஐ சரிபார்க்கவும்.

nginx ஐ live/ ஐ நோக்கி அமைக்கவும், archive/ ஐ நோக்கி அமைக்க வேண்டாம். ஒவ்வொரு புதுப்பித்தலின்போதும் live/ symlink கள் மறுசுட்டியாகும். archive/ க்குள் ஒரு நிலையான பாதையை அமைத்தால், காலாவதியாகும் ஒரு சான்றிதழுக்கு நீங்கள் பிணைக்கப்படுவீர்கள்.

ஒற்றைப்பெயர் சான்றிதழ்கள் DNS-01 ஐக் குறிக்கின்றன, DNS-01 என்பது ஒரு செருகுநிரலைக் குறிக்கிறது

ஒற்றைப்பெயர் சான்றிதழ் (*.example.com) HTTP-01 வழியாக சரிபார்க்க முடியாது — கோப்பை எடுப்பதற்கான தனிப்பட்ட ஒரு hostname இல்லை. DNS-01 தான் ஒரே வழி: நீங்கள் _acme-challenge.example.com TXT பதிவை வெளியிட்டு கட்டுப்பாட்டை நிரூபிக்கிறீர்கள். இதை தானாகச் செய்ய Certbot-க்கு உங்கள் DNS வழங்குநருக்கான API சான்றாணைகள் தேவை; இதற்காகத்தான் வழங்குநர் செருகுநிரல்கள் உள்ளன. முழு ஒற்றைப்பெயர் சான்றிதழ் வழிகாட்டி TXT பதிவின் இயங்கமைப்பையும் கைமுறை பயன்முறையில் உள்ள புதுப்பித்தல் சிக்கலையும் விளக்குகிறது; சுருக்கமான Cloudflare பதிப்பு கீழே உள்ளது.

sudo snap set certbot trust-plugin-with-root=ok
sudo snap install certbot-dns-cloudflare

sudo apt install python3-certbot-dns-cloudflare என்பதற்கு பதிலாக apt பாதையில் அது இவ்வாறு இருக்கும். சான்றாணைகள் root-க்கு மட்டும் என்ற ஒரு கோப்பில் இருக்கும்:

# /root/.secrets/cloudflare.ini
# then: sudo chmod 600 /root/.secrets/cloudflare.ini
dns_cloudflare_api_token = your_scoped_token_here

அந்த ஒரு zone-ல் DNS-திருத்த உரிமைகளுக்கு மட்டும் token-ஐ வரையறுக்கவும். இது உங்கள் DNS-க்கான ஒரு சாவியாகும்; அதை அப்படியே நடத்தவும்.

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cloudflare.ini \
  -d example.com -d '*.example.com'

உங்கள் shell அதை விரிவாக்காதபடி ஒற்றைப்பெயரை மேற்கோள் குறியிடவும். DNS-01 HTTP-01 ஆல் முடியாததையும் தீர்க்கிறது: பொது port 80 இல்லாத hosts-க்கான சான்றிதழ்கள் — ஒரு உள் சேவை, ஒரு VPS-ல் சுய-ஹோஸ்ட் செய்யப்பட்ட WireGuard VPN வழியாக மட்டுமே அணுகக்கூடிய ஒரு கணினி, தனிப்பட்ட interface ஒன்றில் உள்ள ஒரு நிர்வாக பலகம்.

புதுப்பித்தல்: 90 நாட்கள், டைமர், deploy hook

Let's Encrypt சான்றிதழ்கள் 90 நாட்களுக்குச் செல்லுபடியாகும். 30 நாட்களுக்கும் குறைவாகவே மீதமிருக்கும்போது Certbot புதுப்பிக்கிறது. இது உங்களுக்கு 30 நாள் சாளரத்தைத் தருகிறது. இந்தக் காலகட்டத்தில் புதுப்பித்தல் தோல்வியடைந்தால், அது ஒரு சேவை தடையாக மாறாமல் சரிசெய்யக்கூடிய ஒரு சிறிய பிரச்சினையாகவே இருக்கும். Let's Encrypt இனி காலாவதி எச்சரிக்கை மின்னஞ்சல்களை அனுப்புவதில்லை. யாரும் உங்களுக்கு நினைவூட்டப் போவதில்லை. எனவே கண்காணிப்பு இப்போது உங்கள் பொறுப்பு.

உங்கள் நிறுவலில் வந்த டைமரைச் சரிபாருங்கள்:

systemctl list-timers 'certbot*' 'snap.certbot*'
sudo certbot certificates

certbot renew ஆனது /etc/letsencrypt/renewal/ இல் உள்ள ஒவ்வொரு கட்டமைப்பையும் சரிபார்க்கிறது. 30 நாள் சாளரத்திற்கு வெளியே உள்ளவற்றைத் தவிர்க்கிறது. மீதமுள்ளவற்றை முதல் இயக்கத்தின் அதே flags ஐப் பயன்படுத்தி புதுப்பிக்கிறது. முதல் இயக்கம் முக்கியமானது இதனால்தான்: பதிவு செய்யப்படுவது அதுதான்.

வட்டில் உள்ள கோப்பைப் புதுப்பிப்பது தனியாக எதையும் மாற்றாது. ஏதாவது reload செய்யும்படி nginx-க்குக் கூறும் வரை, நினைவகத்தில் உள்ள பழைய சான்றிதழையே nginx தொடர்ந்து வழங்கும். ஒரு முறை deploy hook ஐ இணைக்கவும்:

sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh >/dev/null <<'EOF'
#!/bin/sh
set -e
nginx -t && systemctl reload nginx
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

renewal-hooks/deploy/ இல் உள்ள எந்த executable பொருளும் வெற்றிகரமான புதுப்பித்தலுக்குப் பிறகு இயங்கும். ஒரு சான்றிதழுக்கு அதே வேலையைச் செய்ய --deploy-hook flag பயன்படுகிறது. இது அந்த சான்றிதழின் புதுப்பித்தல் கட்டமைப்பில் renew_hook = ... ஐச் சேமிக்கிறது. certbot --nginx உங்களுக்காக reload செய்கிறது; --webroot மற்றும் --standalone அமைப்புகள் அவ்வாறு செய்யாது. ஒரு hook இல்லாததுதான் ஒரு தளம் காலாவதியான சான்றிதழை வழங்குவதற்குச் சரியான காரணம். அதே சமயம் certbot certificates புதிய சான்றிதழ் உள்ளதாக மகிழ்ச்சியாகப் புகட்டும். தொடக்கத்தில் சான்றிதழைப் படிக்கும் வேறு எதுவும் இருந்தால், அதற்கும் இதே hook தேவை. Docker, TLS மற்றும் backups உடன் Nextcloud VPS நிறுவல் போன்ற ஒரு containerised செயலி தனக்கான restart அல்லது reload படியையும் இங்கே இணைத்துக்கொள்ள வேண்டும்.

உண்மையான புதுப்பித்தலைச் சோதித்தல்

sudo certbot renew --dry-run

இது Let's Encrypt-இன் staging சூழலில் முழு challenge-ஐயும் இயக்குகிறது: அதே code path, அதே firewall, அதே DNS, rate-limit செலவு இல்லை, disk-ல் எதுவும் எழுதப்படாது. இது இன்று வெற்றிபெற்றால், இயந்திரத்தின் அடிப்படையில் எதுவும் மாறவில்லை என்று கொண்டால், 60 நாட்களில் நடைபெறும் unattended புதுப்பித்தலும் வெற்றிபெறும்.

ஒரு dry run உங்கள் reload hook இயங்குகிறது என்பதை நிரூபிக்காது — அதன் நடத்தை Certbot version-ஐப் பொறுத்து மாறுபடும். அந்தப் பகுதியை கைமுறையாகச் சோதிக்கவும்: hook script-ஐ நேரடியாக இயக்கவும், systemctl reload nginx வெற்றிபெறுகிறது என்பதை உறுதிப்படுத்தவும், மேலும் sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf-ஐ சரிபார்க்கவும்.

உண்மையில் நீங்கள் சந்திக்கப் போகும் பிழைகள்

Could not bind to IPv4 or IPv6. — nginx ஏற்கனவே port 80-ஐ பயன்படுத்திக் கொண்டிருக்கும்போது --standalone. --nginx அல்லது --webroot பயன்படுத்தவும். இல்லையென்றால், இயக்கும் நேரத்தில் nginx-ஐ நிறுத்தவும். யார் பிடித்துள்ளார்கள் என்பதை sudo ss -lntp | grep ':80' கொண்டு உறுதிப்படுத்தவும்.

Timeout during connect (likely firewall problem) — Let's Encrypt, port 80-ஐ அணுக முடியவில்லை. வெளிப்புறமாகச் சரிபார்க்கவும்: முதலில் sudo ufw status (இதை sudo ufw allow 'Nginx Full' கொண்டு திறக்கவும்), பிறகு VPS வழங்குநரின் சொந்த firewall, பிறகு DNS. உங்கள் சர்வர் அல்லாத வேறு இடத்திலிருந்து சோதிக்கவும்: curl -sSv http://example.com/.well-known/acme-challenge/test. பழைய AAAA record-ம் இதே செய்தியைத் தரும்.

unauthorized :: Invalid response from http://example.com/.well-known/acme-challenge/xyz: 404 — port 80 அணுகக்கூடியதாக உள்ளது, ஆனால் token சேவையளிக்கப்படவில்லை. கோரிக்கை வேறு ஒரு server block-க்குச் சென்றிருக்கலாம் (எந்த server block-க்கு default_server உரியது என்று சரிபார்க்கவும்). இல்லையென்றால், -w-க்கு கொடுக்கப்பட்ட directory, nginx சேவையளிக்கும் directory அல்ல. /var/www/example.com/.well-known/acme-challenge/test-இல் ஒரு கோப்பை வைத்து வெளிப்புறமாக அதை எடுத்துப் பார்க்கவும். அது 404 தருமாயின், சான்றிதழ் ஒருபோதும் பிரச்சினையே அல்ல.

DNS problem: NXDOMAIN looking up A for example.com — பெயர் பொதுவாக resolve ஆகவில்லை. பரவாத புதிய records, அல்லது உங்கள் registrar சேவையளிக்காத zone-இல் உள்ள ஒரு record.

too many certificates already issued for: example.com — இது ஒரு rate limit. தொடர்ந்து debug செய்பவர்கள் சிக்கும் பிழை இதுவே. Let's Encrypt, நகல் சான்றிதழ்களை — அதாவது ஒரே பெயர்த் தொகுப்பை — வாரத்திற்கு ஐந்திற்கு மட்டுமே அனுமதிக்கிறது. தனியாக, ஒரு registered domain-க்கு வாரத்திற்கு 50 புதிய சான்றிதழ்கள் வரை அனுமதிக்கிறது. இவை இரண்டையும் நேரம் தவிர வேறு எதுவும் தளர்த்தாது. staging-உடன் --dry-run பயன்படுத்தி debug செய்யவும்.

nginx: [emerg] cannot load certificate "/etc/letsencrypt/live/example.com/fullchain.pem": No such file or directory — nginx, வழங்கப்படாத ஒரு சான்றிதழுக்காக அமைக்கப்பட்டுள்ளது. அல்லது certbot delete கொண்டு நீக்கப்பட்ட சான்றிதழுக்காக அமைக்கப்பட்டுள்ளது. TLS server block-ஐ comment செய்யவும், nginx-ஐ தொடங்கவும், சான்றிதழை வழங்கவும், பிறகு அந்த block-ஐ மீண்டும் சேர்க்கவும்.

open() "/etc/letsencrypt/options-ssl-nginx.conf" failed — அந்தக் கோப்பு nginx plugin package-உடன் வரும். python3-certbot-nginx இல்லாத ஒரு certonly சர்வரில், plugin-ஐச் சேர்க்கவும். அல்லது include வரியை நீங்களே உருவாக்கிய ssl_protocols மற்றும் ssl_ciphers அமைப்புகளால் மாற்றவும்.

பெருமளவில் இதனை நிர்வகித்தல்

ஒரு சான்றிதழ் 100 பெயர்கள் வரை கொண்டிருக்கலாம். ஒரே ஒரு certbot --nginx -d a.example.com -d b.example.com ... பயன்படுத்துவது கவர்ச்சியானது. ஆனால் ஒரு பழைய DNS பதிவு சரிபார்ப்பில் தோல்வியடைந்தால், அதே சான்றிதழில் உள்ள மற்ற அனைத்து பெயர்களும் செயலிழக்கும். ஒவ்வொரு தளத்திற்கும் தனித்தனி சான்றிதழ்கள் தனித்தனியாக தோல்வியடையும். ஒன்றுக்கு மேற்பட்டவற்றை ஹோஸ்ட் செய்யும் சர்வரில் இதுவே நீங்கள் விரும்புவது. சில தளங்களுக்கு மேல், ACME-ஐ ஆதரிக்கும் ஃப்ரண்ட் டோர் பயனுள்ளதாக இருக்கும்: ஒரு Docker Compose கீழ் பல ஆப்ஸை இயக்கும் Traefik ரிவர்ஸ் ப்ராக்ஸி சான்றிதழ்களை தானாகவே கோரி புதுப்பிக்கும். அப்போது Certbot முற்றிலுமாக தேவையில்லாமல் போகும்.

/etc/letsencrypt மரத்தை முழுமையாக காப்புப் பிரதி எடுக்கவும் — sudo tar -czf letsencrypt-$(date +%F).tar.gz -C /etc letsencrypt — சிம்லிங்க்குகள் அப்படியே இருக்கட்டும். அந்த மரத்தில் accounts/, உங்கள் ACME கணக்கு விசை உள்ளது. இதனை நீங்கள் பழையபடி மீண்டும் உருவாக்க முடியாது. புதிய VPS-க்கு மாறுவது எளிதாகிறது: மரத்தை -a உடன் rsync செய்யவும், Certbot-ஐ நிறுவவும், DNS-ஐ மறுசீரமைக்கவும், மாறுவதற்கு முன் certbot renew --dry-run-ஐ இயக்கவும்.

சர்வரை மறுகட்டமைத்தாலோ புதிய LTS-க்கு மாறினாலோ புதுப்பிப்பு டைமர் உங்களுடன் வராது. எந்தவொரு இடப்பெயர்ச்சி, ஸ்னாப்ஷாட் மீட்பு, அல்லது டிஸ்ட்ரோ மேம்படுத்தலுக்குப் பிறகும் systemctl list-timers 'certbot*' மற்றும் ஒரு --dry-run இயக்கவும். இதனை தவறவிடுவதால் 89 நாட்களுக்குப் பிறகு, காலை 3 மணிக்கு, தானாக புதுப்பிக்கும் என அனைவரும் நினைத்த சான்றிதழ் செயலிழந்து தளம் இணையற்று போகும்.

இவை அனைத்தும் நீங்கள் கட்டுப்பாட்டில் உள்ள ஒரு இயந்திரத்தைக் கருதுகின்றன. அதற்கு பொது IP மற்றும் உலகளாவிய அணுகலுக்கு திறந்த port 80 இருக்க வேண்டும் — அதாவது ஒரு VPS. மேற்கண்ட இயக்கமுறைகள் எந்த VPS-லும் ஒன்றே.

இதே சான்றிதழ் படிகள் nginx-க்கு பதிலாக Apache-லும் பொருந்தும். பொது சான்றிதழ் சாத்தியமில்லாதபோது, Ubuntu-ல் சுய-கையொப்பமிடப்பட்ட சான்றிதழ் உள்கட்டமைப்பு சேவைகளை பாதுகாக்கும்.

FAQ

எனது தளம் HTTPS மட்டும் வழங்கினால், port 80 திறந்திருக்க வேண்டுமா?

ஆம், HTTP-01 சவாலுக்கு தேவை. Let's Encrypt தனது சரிபார்ப்பு கோரிக்கையை எப்போதும் port 80 இல் தொடங்குகிறது. Certbot இல் TLS-ALPN-01 செயல்படுத்தல் இல்லை. எனவே, 443 ஐ மட்டும் திறக்கும் firewall முதல் சான்றிதழ் வழங்கலையும் அதற்குப் பிறகு ஒவ்வொரு தானியங்கி புதுப்பித்தலையும் தடுக்கிறது. port 80 இல் இருந்து HTTPS க்கு திருப்பி விடுவது பிரச்சினையில்லை — சரிபார்ப்பு அதைப் பின்பற்றும். port 80 ஐ முற்றிலும் தவிர்க்க ஒரே வழி, provider plugin உடன் DNS-01 ஐப் பயன்படுத்துவது.

Ubuntu 24.04 இல் nginx க்கு எந்த Certbot ஐ நிறுவ வேண்டும் — apt அல்லது snap?

apt ஐப் பயன்படுத்துங்கள். sudo apt install certbot python3-certbot-nginx Ubuntu 24.04 இல் Certbot 2.9.0 ஐத் தருகிறது. இந்த வழிகாட்டியில் உள்ள அனைத்திற்கும் இது போதுமானது. unattended-upgrades மூலம் பாதுகாப்பு திருத்தங்கள் கிடைக்கின்றன. snapd தேவையில்லை. புதிய வெளியீடு உடனடியாகத் தேவைப்பட்டால் அல்லது ஒரு DNS plugin சிறப்பாக snap ஆகவே வழங்கப்பட்டால் மட்டுமே snap ஐத் தேர்ந்தெடுக்கவும். எப்படியாக இருந்தாலும், சரியாக ஒன்றை மட்டும் தேர்ந்தெடுக்கவும்: இரண்டு நிறுவல்கள் என்பது ஒரே /etc/letsencrypt மரத்தை நோக்கி இரண்டு புதுப்பித்தல் timers என்பதைக் குறிக்கும். கண்டுகொள்ளாமல் விடப்பட்டதுதான் பின்னர் பிரச்சினையை ஏற்படுத்தும்.

Certbot ஆனது nginx க்கு wildcard சான்றிதழை வழங்க முடியுமா?

DNS-01 வழியாக மட்டுமே. *.example.com போன்ற wildcard இல் சவால் கோப்பை எடுக்க ஒரே ஒரு hostname கிடையாது. எனவே --nginx, --webroot மற்றும் --standalone ஆகிய அனைத்தும் செல்லாது. உங்கள் DNS provider க்கான plugin ஐ நிறுவவும். root மட்டும் அணுகக்கூடிய credentials கோப்பில் ஒரு வரம்பிடப்பட்ட API token ஐ வைக்கவும். shell அதை விரிவாக்குவதைத் தடுக்க wildcard ஐ மேற்கோளிட்டு certbot certonly --dns-cloudflare -d example.com -d '*.example.com' ஐ இயக்கவும்.

வெற்றிகரமான புதுப்பித்தலுக்குப் பிறகும் nginx ஏன் பழைய சான்றிதழை வழங்குகிறது?

nginx சான்றிதழை நினைவகத்தில் வைத்திருக்கிறது. அது reload செய்யப்படும் வரை வட்டில் உள்ள புதிய கோப்பைக் கவனிப்பதில்லை. certbot --nginx உங்களுக்காக reload செய்கிறது. ஆனால் --webroot மற்றும் --standalone இயக்கங்கள் அவ்வாறு செய்வதில்லை. எனவே, புதுப்பித்தல் வெற்றிபெற்றாலும் உலாவி காலாவதியாகும் சான்றிதழையே காண்கிறது. /etc/letsencrypt/renewal-hooks/deploy/ இல் nginx -t && systemctl reload nginx ஐ இயக்கும் ஒரு செயல்படுத்தக்கூடிய script ஐ வைக்கவும். ஒவ்வொரு வெற்றிகரமான புதுப்பித்தலுக்குப் பிறகும் இது இயங்கும்.

certbot renew --dry-run புதுப்பித்தல் வேலை செய்யும் என்பதை நிரூபிக்கிறதா?

பெரும்பாலும் ஆம். இது staging சூழலுக்கு எதிராக உண்மையான சவாலை இயக்குகிறது — ஒரே firewall, ஒரே DNS, ஒரே code path — rate-limit செலவு இல்லாமல், வட்டில் எதுவும் எழுதப்படாமல். எனவே, வெற்றி என்பது பிணைய பகுதி சரியாக இருப்பதைக் குறிக்கிறது. இருப்பினும், உங்கள் deploy hook இயங்குவதை இது நம்பகமாக நிரூபிக்காது. அதைத் தனியாகச் சோதிக்கவும்: hook script ஐ கைமுறையாக இயக்கி sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf ஐச் சரிபார்க்கவும்.

#certbot#lets-encrypt#nginx#tls#ubuntu#systemd