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

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

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

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

apt வழிமுறை:

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

இது /usr/bin/certbot, nginx plugin, ஒரு 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-வை ஆதரிக்காத client-களுக்கு மட்டும் --key-type rsa-ஐப் பயன்படுத்தவும். அனைத்துத் தரவுகளும் /etc/letsencrypt-ன் கீழ் சேமிக்கப்படும்: archive/ உண்மையான சாவி மற்றும் certificate கோப்புகளைக் கொண்டுள்ளது, live/ தற்போதைய கோப்புகளுக்கான symlink-களைக் கொண்டுள்ளது, renewal/ ஒவ்வொரு certificate-க்கும் ஒரு config கோப்பைக் கொண்டுள்ளது, accounts/ உங்கள் ACME கணக்கின் சாவியைக் கொண்டுள்ளது.

HTTP-01 உண்மையில் என்ன செய்கிறது மற்றும் port 80 ஏன் கட்டாயமானது

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

• Port 80 பொது இணையத்திலிருந்து அணுகக்கூடியதாக இருக்க வேண்டும், உங்கள் மடிக்கணினியிலிருந்து மட்டும் அணுக முடிந்தால் போதாது. ஒரு ufw விதி, cloud-provider security group, அல்லது 443-ஐ மட்டும் அனுமதிக்கும் VPS-console firewall ஆகியவை சான்றிதழ் வழங்கலையும், எதிர்கால புதுப்பித்தல்களையும் (renewal) தடுக்கும்.
• DNS ஏற்கனவே இந்த server-ஐக் குறிப்பிட்டிருக்க வேண்டும். சரிபார்ப்பு server (validation server) வெளியிலிருந்து தனது சொந்த lookup-ஐச் செய்யும்; உங்கள் /etc/hosts பதிவுகளோ அல்லது browser cache-ஓ அதற்குப் பயன்படாது.
• நீங்கள் AAAA record-ஐ வெளியிட்டால், முதலில் IPv6 முயற்சிக்கப்படும். IPv6 இணைப்பு முற்றிலும் தோல்வியடையும் போது Let's Encrypt IPv4 மூலம் மீண்டும் முயற்சிக்கும், ஆனால் தவறான AAAA record ஒரு host-ஐச் சுட்டிக்காட்டி, அங்கு இணைப்பு கிடைத்து வேறு ஏதேனும் பதில் கிடைத்தால், அது தோல்வியாகவே கருதப்படும்.

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

Authenticator-ஐத் தேர்ந்தெடுத்தல்: --nginx, --webroot, --standalone

Nginx ஏற்கனவே இயங்கிக்கொண்டிருந்து, அந்த domain-க்கு சேவை வழங்கிக்கொண்டிருக்கும்போது --nginx சிறந்த இயல்புநிலைத் தேர்வாகும். Certbot உங்கள் configuration-ஐப் பகுப்பாய்வு செய்து, தற்காலிக challenge location-ஐச் சேர்த்து, Nginx-ஐ reload செய்து, சரிபார்த்து, பின்னர் TLS directives-ஐ உங்கள் server block-ல் எழுதும். இதனால் downtime இருக்காது.

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

புதிய server-க்கான script முறை:

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

உங்கள் Nginx configuration-ல் Certbot எந்த மாற்றமும் செய்யக்கூடாது என்று நீங்கள் விரும்பினால், --webroot சரியான தேர்வாகும். நீங்கள் template மூலம் உருவாக்கி, git-ல் பராமரிக்கும் அல்லது Ansible மூலம் deploy செய்யும் configuration-களுக்கு இது பொருந்தும். Certbot challenge file-ஐ மட்டும் நீங்கள் ஏற்கனவே சேவை வழங்கும் directory-க்குள் எழுதும்.

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

Port 80-ல் எந்தச் சேவையும் இயங்காதபோது --standalone சரியான தேர்வாகும். உதாரணமாக: mail server, 443 port-ல் மட்டும் இயங்கும் API, அல்லது Nginx நிறுவப்படுவதற்கு முன்பு இயங்கும் first-boot script. Certbot சில நொடிகள் மட்டும் port 80-ஐத் தானே பிடித்துக்கொள்ளும் (bind). Nginx ஏற்கனவே இயங்கிக்கொண்டிருந்தால், இந்த முறை தோல்வியடையும். எனவே, கட்டளையை இயக்கும்போது Nginx-ஐ நிறுத்தி வைக்கவும்:

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

இந்த hooks சான்றிதழின் renewal configuration-ல் பதிவு செய்யப்படும். எனவே, சான்றிதழ் புதுப்பிக்கப்படும்போது அதே stop/start செயல்பாடுகள் தானாகவே நடைபெறும்.

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

கோழி-முட்டை சிக்கல்: கோப்பில் இல்லாத ஒரு சான்றிதழை ssl_certificate சுட்டிக்காட்டினால் Nginx தொடங்க மறுக்கும், அதே சமயம் Nginx இயங்கவில்லை என்றால் Certbot-ஆல் சரிபார்ப்பை (validation) மேற்கொள்ள முடியாது. எனவே, முதலில் 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-க்கு முன்னால் உள்ள ^~ முன்னொட்டு (prefix) மிகவும் முக்கியமானது: இது challenge கோரிக்கையை return 301 block விழுங்காமல் தடுக்கிறது. இந்த location-ஐ port 80-ல் வைத்திருப்பது, தளம் முழுமையாக HTTPS-க்கு மாறிய பிறகும் சான்றிதழ் புதுப்பித்தல் (renewals) தொடர்ந்து நடைபெற உதவும்.

மேலே உள்ள இரண்டு block-களும் வட்டில் (disk) உள்ள கோப்புகளை வழங்குகின்றன; Nginx ஒரு application-க்கு முன்னால் proxy-ஆகச் செயல்பட்டால், location / என்பது proxy_pass block-ஆக மாறும். வரி வரியாக reverse proxy server block பகுதியில் அந்த application-க்குத் தேவையான headers விளக்கப்பட்டுள்ளன, அதே சமயம் ACME location மற்றும் TLS directives அப்படியே இருக்கும்.

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

Nginx-ஐ live/-க்குச் சுட்டிக்காட்டவும், ஒருபோதும் archive/-க்குச் சுட்டிக்காட்ட வேண்டாம். live/ symlink-கள் ஒவ்வொரு புதுப்பித்தலின் போதும் மாற்றப்படும்; archive/-க்குள் இருக்கும் hard path-ஐப் பயன்படுத்தினால், சான்றிதழ் காலாவதியாகும் போது சிக்கல் ஏற்படும்.

Wildcard-களுக்கு DNS-01 தேவை, DNS-01-க்கு plugin தேவை

Wildcard certificate (*.example.com) ஒன்றை HTTP-01 மூலம் சரிபார்க்க முடியாது, ஏனெனில் கோப்பைப் பெறுவதற்கு அங்கே ஒரு குறிப்பிட்ட hostname கிடையாது. DNS-01 மட்டுமே ஒரே வழி: ஒரு _acme-challenge.example.com TXT record-ஐ வெளியிடுவதன் மூலம் நீங்கள் அந்த domain-ன் கட்டுப்பாட்டை நிரூபிக்கிறீர்கள். இதைத் தானியங்கி முறையில் செய்ய Certbot-க்கு உங்கள் DNS வழங்குநரின் API நற்சான்றிதழ்கள் (credentials) தேவை, இதற்காகவே provider plugins உள்ளன. முழுமையான wildcard certificate வழிகாட்டி TXT record-ன் செயல்பாடுகள் மற்றும் manual முறையில் புதுப்பித்தலில் உள்ள சிக்கல்களை விளக்குகிறது; சுருக்கமான Cloudflare பதிப்பு கீழே கொடுக்கப்பட்டுள்ளது.

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

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

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

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

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

Wildcard-ஐ மேற்கோள் குறிகளுக்குள் (quotes) இடவும், அப்போதுதான் உங்கள் shell அதை glob செய்யாது. HTTP-01 செய்ய முடியாதவற்றையும் DNS-01 தீர்க்கிறது: பொதுவான port 80 இல்லாத hosts, ஒரு internal service, VPS-ல் உள்ள self-hosted WireGuard VPN மூலம் மட்டுமே அணுகக்கூடிய ஒரு பெட்டி, அல்லது private interface-ல் உள்ள admin panel ஆகியவற்றுக்கு இது சான்றிதழ்களை வழங்குகிறது.

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

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

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

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

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

வட்டில் உள்ள கோப்பைப் புதுப்பிப்பதால் மட்டும் மாற்றம் ஏற்படாது. Nginx பழைய certificate-ஐ நினைவகத்திலிருந்து தொடர்ந்து வழங்கும்; ஏதேனும் ஒன்று அதை reload செய்யச் சொல்லும் வரை இது தொடரும். ஒருமுறை 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 ஒரு குறிப்பிட்ட certificate-க்கு இதே வேலையைச் செய்யும், மேலும் renew_hook = ...-ஐ அதன் renewal config-ல் சேமிக்கும். certbot --nginx உங்களுக்காக reload செய்யும்; --webroot மற்றும் --standalone அமைப்புகள் அவ்வாறு செய்யாது. hook விடுபட்டிருந்தால், certbot certificates புதிய certificate-ஐக் காட்டும், ஆனால் தளம் காலாவதியான certificate-ஐயே வழங்கும். தொடக்கத்தின்போது certificate-ஐ வாசிக்கும் பிற மென்பொருள்களுக்கும் இதே hook தேவைப்படும். உதாரணமாக, Docker, TLS மற்றும் backups கொண்ட Nextcloud VPS நிறுவல் போன்ற containerised app-களுக்குத் தேவையான restart அல்லது reload கட்டளையை இதனுடன் இணைக்க வேண்டும்.

புதுப்பித்தலை (renewal) சோதனை செய்தல்

sudo certbot renew --dry-run

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

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

நீங்கள் உண்மையில் எதிர்கொள்ளும் பிழைகள்

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

Timeout during connect (likely firewall problem), Let's Encrypt-ஆல் port 80-ஐ அடைய முடியவில்லை. வெளிப்புறமாகச் சரிபார்க்கவும்: sudo ufw status (sudo ufw allow 'Nginx Full' மூலம் அதைத் திறக்கவும்), பிறகு VPS வழங்குநரின் firewall, இறுதியாக DNS. உங்கள் server அல்லாத வேறொரு இடத்திலிருந்து சோதிக்கவும்: 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-க்குச் சென்றுவிட்டது (எந்த block default_server-ஐக் கொண்டுள்ளது என்று சரிபார்க்கவும்), அல்லது -w-க்கு வழங்கப்பட்ட directory, Nginx பயன்படுத்தும் directory அல்ல. /var/www/example.com/.well-known/acme-challenge/test-ல் ஒரு கோப்பை வைத்து, அதை வெளிப்புறமாகப் பதிவிறக்க முயற்சிக்கவும்; அது 404 பிழையைக் காட்டினால், certificate-ல் எந்தப் பிரச்சினையும் இல்லை என்று அர்த்தம்.

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

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

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

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

அளவீட்டு முறையில் நிர்வகித்தல்

ஒரு certificate-ல் 100 பெயர்கள் வரை சேர்க்கலாம், ஒரு certbot --nginx -d a.example.com -d b.example.com ...-ஐப் பயன்படுத்துவது கவர்ச்சிகரமாகத் தோன்றலாம். ஆனால், காலாவதியான ஒரு DNS record validation-ல் தோல்வியடைந்தால், அந்த certificate-ல் உள்ள அனைத்து பெயர்களும் செயலிழந்துவிடும். பல தளங்களை ஹோஸ்ட் செய்யும் ஒரு server-ல், ஒவ்வொரு தளத்திற்கும் தனித்தனி certificate வைத்திருப்பதே சிறந்தது; அப்போதுதான் ஒன்று தோல்வியடைந்தாலும் மற்றவை பாதிக்கப்படாது. சில தளங்களுக்கு மேல் செல்லும்போது, ACME வசதி கொண்ட ஒரு front door-ஐப் பயன்படுத்துவது பயனுள்ளது: Docker Compose மூலம் பல apps-ஐ இயக்கும் Traefik reverse proxy தானாகவே certificate-களைக் கோரி புதுப்பித்துக்கொள்ளும், இதனால் Certbot-ன் தேவை முற்றிலும் நீங்கிவிடும். எந்த proxy-ஐப் பயன்படுத்த வேண்டும் என்பது உங்கள் முடிவு, Nginx, Caddy மற்றும் Traefik ஆகியவற்றை ஒப்பிட்டுப் பார்ப்பது, proxy எந்த அளவிற்கு certificate மற்றும் app-சார்ந்த கட்டமைப்புகளை உங்களுக்காகக் கையாள வேண்டும் என்பதைப் பொறுத்தது.

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

server-ஐ மீண்டும் கட்டமைக்கும்போதோ அல்லது புதிய LTS பதிப்பிற்கு மாறும்போது renewal timer தானாகவே வராது. ஏதேனும் migration, snapshot restore, அல்லது distro upgrade செய்த பிறகு, systemctl list-timers 'certbot*' மற்றும் ஒருமுறை --dry-run-ஐ இயக்கவும். இதைத் தவறவிட்டால், 89 நாட்களுக்குப் பிறகு, நள்ளிரவு 3 மணிக்கு, தானாகவே புதுப்பிக்கப்படும் என்று நம்பப்பட்ட certificate காலாவதியாகி தளம் முடங்கிவிடும்.

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

இதே certificate வழிமுறைகள் Nginx-க்கு பதிலாக Apache-விலும் பொருந்தும். public certificate பயன்படுத்த முடியாத சூழலில், Ubuntu-வில் self-signed certificate மூலம் internal services-ஐப் பாதுகாக்கலாம்.

FAQ

எனது தளம் HTTPS-ல் மட்டுமே இயங்கும்போது port 80-ஐத் திறந்து வைக்க வேண்டுமா?

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

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

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

nginx-க்காக Certbot-ஆல் wildcard certificate வழங்க முடியுமா?

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

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

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

certbot renew --dry-run கட்டளை renewal சரியாக நடக்கும் என்பதை உறுதிப்படுத்துமா?

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