Install Certbot para sa nginx sa Ubuntu 24.04

I-install ang Certbot: apt o snap

Sa Ubuntu 24.04, nagbibigay ang sudo apt install certbot python3-certbot-nginx ng gumaganang Certbot na nag-iisyu ng tunay at pampublikong pinagkakatiwalaang Let's Encrypt certificates. Sa halip, itinuturo ng upstream documentation ng Certbot ang snap; maliit ang pagkakaiba: sinusundan ng snap ang upstream releases, habang sinusundan ng archive package ang bersyong isinama sa LTS at tumatanggap ng security fixes.

Pumili ng isa. Kapag may dalawang kopya ng Certbot, magkakaroon ng dalawang renewal timer na nakatuon sa iisang /etc/letsencrypt tree. Ang kopyang nakalimutan mo ang siyang maaaring magdulot ng hindi inaasahang resulta.

Ang apt na paraan:

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

Ini-install nito ang /usr/bin/certbot, ang nginx plugin, isang certbot.service + certbot.timer pair, at isang /etc/cron.d/certbot entry na walang ginagawa kapag systemd ang ginagamit.

Ang snap na paraan:

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

May sarili itong timer ang snap, snap.certbot.renew.timer. Alisin ang apt package bago i-install ang snap.

Pareho ang magiging kilos ng dalawang installation pagkatapos nito. Bilang default, gumagamit ang Certbot 2.x ng ECDSA (P-256) keys. Gamitin lamang ang --key-type rsa para sa client na hindi kayang gumamit ng ECDSA. Nasa /etc/letsencrypt ang lahat ng state: nasa archive/ ang aktuwal na key at certificate files, naka-symlink ang live/ sa mga kasalukuyang file, may isang config file bawat certificate sa renewal/, at nasa accounts/ ang ACME account key mo.

Ano ang aktuwal na ginagawa ng HTTP-01, at kung bakit hindi optional ang port 80

Ang HTTP-01 challenge ay isang callback. Humihingi ka sa Let's Encrypt ng certificate para sa example.com; nireresolba nito ang pangalan sa public DNS, kumokonekta sa port 80 sa address na natagpuan nito, at hinihingi ang http://example.com/.well-known/acme-challenge/<token>. Sumasagot ang server mo gamit ang eksaktong token content na isinulat lang ng Certbot sa disk. Iyan ang buong mekanismo. May tatlong resulta ito, at dito nagmumula ang karamihan ng mga nabigong issuance.

• Dapat maabot ang port 80 mula sa public internet, hindi lamang mula sa laptop mo. Ang ufw rule, cloud-provider security group, o firewall sa VPS console na nagbubukas lamang ng 443 ay pumipigil sa issuance at sa lahat ng susunod na renewal.
• Dapat nakaturo na ang DNS sa server na ito. Ang validation server mismo ang nagsasagawa ng lookup mula sa labas; walang epekto rito ang mga /etc/hosts entry at browser cache mo.
• Kung magpa-publish ka ng AAAA record, unang susubukan ang IPv6. Muling susubukan ng Let's Encrypt sa IPv4 kapag tuluyang nabigo ang IPv6 connection, pero ang lumang AAAA na nakaturo sa host na tumatanggap ng connection at naghahatid ng ibang content ay magdudulot ng hard failure.

Pinapayagan ang mga redirect: sinusundan ng validation ang HTTP redirect patungo sa HTTPS, at hindi nito isinasaalang-alang kung missing, expired, o self-signed ang certificate sa kabilang dulo. Ngunit hindi ito magsisimula sa port na iba sa port 80. Walang TLS-ALPN-01 implementation ang Certbot, kaya hindi solusyon ang “gamitin na lang ang 443.”

Pagpili ng authenticator: --nginx, --webroot, --standalone

Ang --nginx ang tamang default kapag tumatakbo na ang nginx at nagsi-serve na ito ng domain. Binabasa ng Certbot ang configuration mo, naglalagay ng pansamantalang challenge location, nire-reload ang nginx, vine-validate ang domain, at pagkatapos ay isinusulat ang TLS directives sa server block mo. Walang downtime.

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

Para sa scripted na setup sa bagong server:

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

Ang --webroot ang tamang piliin kapag ayaw mong pakialaman ng Certbot ang nginx configuration mo—halimbawa, kapag galing ito sa template, naka-store sa git, o ipinapadala gamit ang Ansible. Ang challenge file lamang ang isinusulat ng Certbot sa directory na sini-serve mo na.

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

Ang --standalone ang tamang piliin kapag walang nakikinig sa port 80: halimbawa, mail server, API na 443 lamang ang ginagamit, o first-boot script na tumatakbo bago pa available ang nginx. Ang Certbot mismo ang nagbi-bind sa port 80 sa loob ng ilang segundo. Kung tumatakbo ang nginx, mabibigo ito. Ihinto ang nginx bago patakbuhin ang command at paandarin itong muli pagkatapos:

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

Naitatala ang mga hook na ito sa renewal configuration ng certificate, kaya awtomatikong inuulit ang parehong stop/start sa renewal.

Isang server block na gumagana bago at pagkatapos magkaroon ng certificate

Ang problema sa dependency: tumatangging magsimula ang nginx kapag nakaturo ang ssl_certificate sa file na hindi umiiral, at hindi makapag-validate ang Certbot habang down ang nginx. Ipaandar muna ang site sa 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;
    }
}

Patakbuhin ang sudo nginx -t && sudo systemctl reload nginx, tiyaking sumasagot ang curl -I http://example.com/ mula sa labas ng server, pagkatapos ay mag-issue. Pagkatapos:

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;
    }
}

Mahalaga ang ^~ prefix sa ACME location: pinipigilan nitong sakupin ng return 301 block ang challenge request. Kapag nananatili ang location na iyon sa port 80, patuloy na gagana ang renewals kahit HTTPS-only na ang natitirang bahagi ng site.

Parehong naghahatid ng mga file mula sa disk ang dalawang block sa itaas; kung application naman ang nasa likod ng nginx, magiging location / block ang proxy_pass at tinatalakay sa reverse proxy server block, bawat linya ang mga header na kailangan ng application na iyon, habang eksaktong mananatili ang ACME location at mga TLS directive.

Nakadepende sa bersyon ng nginx ang syntax ng HTTP/2, at nagdudulot ng startup error ang paghahalo ng dalawang anyo. Kasama sa Ubuntu 24.04 ang nginx 1.24, na nangangailangan nito inline, listen 443 ssl http2;. Kasama naman sa Debian 13 ang mas bagong nginx, na nangangailangan ng hiwalay na http2 on; directive. Suriin muna ang nginx -v.

Ituro ang nginx sa live/, at huwag kailanman sa archive/. Awtomatikong nire-repoint ang mga symlink na live/ sa bawat renewal; kapag hard path papasok sa archive/ ang ginamit, mananatili kang nakatali sa certificate na mag-e-expire habang ginagamit mo ito.

Ang wildcard certificate (*.example.com) ay hindi mabe-validate gamit ang HTTP-01 dahil walang iisang hostname kung saan maaaring kunin ang file. DNS-01 lamang ang paraan: pinatutunayan mong kontrolado mo ang domain sa pamamagitan ng pag-publish ng _acme-challenge.example.com TXT record. Kailangan ng Certbot ng API credentials para sa DNS provider mo upang maisagawa ito nang unattended. Para rito ginagamit ang provider plugins. Saklaw ng buong walkthrough para sa wildcard certificate ang mechanics ng TXT record at ang renewal trap sa manual mode; kasunod ang maikling bersyon para sa Cloudflare.

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

Sa apt path, sudo apt install python3-certbot-dns-cloudflare naman iyon. Ilagay ang credentials sa isang file na root lamang ang makababasa:

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

Limitahan ang token sa DNS-edit rights para sa zone na iyon lamang. Key ito para sa DNS mo; ituring mo itong sensitibong credential.

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

I-quote ang wildcard upang hindi ito i-glob ng shell. Nilulutas din ng DNS-01 ang hindi kayang lutasin ng HTTP-01: mga certificate para sa host na walang public port 80, isang internal service, isang box na maa-access lamang sa pamamagitan ng self-hosted WireGuard VPN sa isang VPS, o isang admin panel sa private interface.

Pag-renew: ang 90 araw, ang timer, at ang deploy hook

Valid nang 90 araw ang mga certificate ng Let’s Encrypt. Nagre-renew ang Certbot kapag mas mababa sa 30 araw ang natitira. Nagbibigay ito sa iyo ng 30-araw na palugit kung kailan ang pumalyang renewal ay abalang maaari pang ayusin sa halip na outage. Hindi na nagpapadala ang Let’s Encrypt ng mga email ng babala tungkol sa pag-expire. Walang magpapaalala sa iyo, kaya ikaw na ang kailangang mag-monitor.

Suriin ang timer na kasama sa iyong installation:

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

Sinusuri ng certbot renew ang bawat config sa /etc/letsencrypt/renewal/, nilalaktawan ang mga wala pa sa 30-araw na window, at nire-renew ang iba gamit ang eksaktong mga flag ng unang pagtakbo. Kaya mahalaga ang unang pagtakbo: iyon ang nire-record.

Kapag ni-renew ang file sa disk, walang awtomatikong nagbabago. Patuloy na ginagamit ng nginx ang lumang certificate mula sa memory hanggang may magsabi rito na mag-reload. Mag-configure ng deploy hook nang isang beses:

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

Ang anumang executable sa renewal-hooks/deploy/ ay tumatakbo pagkatapos ng matagumpay na renewal. Pareho ang ginagawa ng --deploy-hook flag para sa isang certificate, at iniimbak nito ang renew_hook = ... sa renewal config nito. Awtomatikong nagre-reload ang certbot --nginx para sa iyo; hindi ito ginagawa ng mga setup na --webroot at --standalone. Ang kawalan ng hook ang eksaktong dahilan kung bakit maaaring maghatid ang isang site ng expired certificate habang masayang nag-uulat ang certbot certificates na bago ang certificate. Ang anumang iba pang nagbabasa ng certificate sa startup ay nangangailangan din ng parehong hook. Ang containerised app gaya ng Nextcloud VPS installation na may Docker, TLS, at backups ay nangangailangan din ng sarili nitong restart o reload step na i-wire dito.

Pagsubok sa aktuwal na renewal

sudo certbot renew --dry-run

Isinasagawa nito ang buong challenge laban sa staging environment ng Let's Encrypt: parehong code path, parehong firewall, parehong DNS, walang rate-limit cost, at walang isinusulat sa disk. Kung pumasa ito ngayon, papasa rin ang unattended renewal pagkalipas ng 60 araw, hangga't walang nagbabago sa system sa panahong iyon.

Hindi pinatutunayan ng dry run na tatakbo ang reload hook. Nag-iiba ang behavior nito depende sa bersyon ng Certbot. Subukan nang manu-mano ang bahaging iyon: direktang isagawa ang hook script, tiyaking nagtatagumpay ang systemctl reload nginx, at suriin ang sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf.

Mga error na aktuwal mong mararanasan

Could not bind to IPv4 or IPv6., --standalone habang ginagamit na ng nginx ang port 80. Gamitin ang --nginx o --webroot, o ihinto muna ang nginx habang isinasagawa ang run. Kumpirmahin kung ano ang gumagamit sa port gamit ang sudo ss -lntp | grep ':80'.

Timeout during connect (likely firewall problem), hindi maabot ng Let's Encrypt ang port 80. Suriin mula sa labas papasok: sudo ufw status (buksan ito gamit ang sudo ufw allow 'Nginx Full'), pagkatapos ang sariling firewall ng VPS provider, at saka ang DNS. Mag-test mula sa ibang system na hindi ang server mo: curl -sSv http://example.com/.well-known/acme-challenge/test. Nagdudulot din ng mensaheng ito ang luma o hindi na wastong AAAA record.

unauthorized :: Invalid response from http://example.com/.well-known/acme-challenge/xyz: 404, reachable ang port 80, pero hindi naihahatid ang token. Maaaring napunta ang request sa ibang server block (tingnan kung alin ang may-ari ng default_server), o hindi ang directory na ipinasa sa -w ang sine-serve ng nginx. Maglagay ng file sa /var/www/example.com/.well-known/acme-challenge/test at i-fetch ito mula sa labas; kung 404 ang resulta, hindi certificate ang problema.

DNS problem: NXDOMAIN looking up A for example.com, hindi nagre-resolve publicly ang pangalan. Maaaring bagong record ito na hindi pa propagated, o record sa zone na hindi sine-serve ng registrar mo.

too many certificates already issued for: example.com, rate limit ito, at ito ang madalas maranasan kapag paulit-ulit ang pag-debug. Nililimitahan ng Let's Encrypt ang duplicate certificates, na may eksaktong parehong set ng mga pangalan, sa lima bawat linggo. Hiwalay nitong pinapayagan ang 50 bagong certificate bawat registered domain bawat linggo. Walang makapag-aalis ng alinmang limit maliban sa paglipas ng oras. Mag-debug laban sa staging gamit ang --dry-run.

nginx: [emerg] cannot load certificate "/etc/letsencrypt/live/example.com/fullchain.pem": No such file or directory, naka-configure ang nginx para sa certificate na hindi kailanman na-issue, o inalis gamit ang certbot delete. I-comment out ang TLS server block, simulan ang nginx, i-issue ang certificate, at ibalik ang block.

open() "/etc/letsencrypt/options-ssl-nginx.conf" failed, kasama ang file na iyon sa nginx plugin package. Sa certonly box na walang python3-certbot-nginx, magdagdag ng plugin o palitan ang linyang include ng sarili mong ssl_protocols at ssl_ciphers settings.

Pagmamay-ari at pamamahala sa malakihang deployment

Ang isang certificate ay maaaring maglaman ng hanggang 100 pangalan, at nakatutukso ang isang certbot --nginx -d a.example.com -d b.example.com ..., ngunit kapag may isang lumang DNS record na nabigong ma-validate, mabibigo rin ang lahat ng iba pang pangalan sa certificate na iyon. Ang magkakahiwalay na certificate para sa bawat site ay magkakabigo nang hiwa-hiwalay. Ito ang kailangan mo sa isang server na nagho-host ng higit sa ilang serbisyo. Kapag lumampas na sa ilang site, sulit ang isang ACME-aware na front door: ang isang Traefik reverse proxy na nagpapatakbo ng maraming app sa ilalim ng Docker Compose ang mismong humihiling at nagre-renew ng mga certificate, kaya tuluyang hindi na kailangan ang Certbot. Sariling desisyon kung aling proxy ang ilalagay sa front door na iyon, at ang pagtitimbang sa Nginx, Caddy, at Traefik ay pangunahing nakabatay sa dami ng certificate at per-app configuration work na gusto mong akuin ng proxy para sa iyo.

I-back up nang buo ang /etc/letsencrypt, kasama ang sudo tar -czf letsencrypt-$(date +%F).tar.gz -C /etc letsencrypt at mga symlink. Nasa tree na iyon ang accounts/, ang ACME account key mo, na hindi mo maaaring buuing muli nang eksakto. Sa paglipat sa bagong VPS, ang proseso ay: i-rsync ang tree gamit ang -a, i-install ang Certbot, ituro muli ang DNS, at patakbuhin ang certbot renew --dry-run bago ilipat ang traffic.

Kapag ni-rebuild mo ang server o lumipat sa bagong LTS, hindi kasama ang renewal timer. Pagkatapos ng anumang migration, snapshot restore, o distro upgrade, patakbuhin ang systemctl list-timers 'certbot*' at isang --dry-run. Kapag nilaktawan ito, maaaring maging unavailable ang isang site makalipas ang 89 araw, bandang 3am, dahil sa certificate na inakalang awtomatikong nagre-renew.

Ipinapalagay ng lahat ng ito na kontrolado mo ang machine, may public IP ito, at bukas sa buong internet ang port 80—isang VPS, sa madaling salita. Pareho ang mga hakbang sa anumang ganoong machine.

Pareho ang mga hakbang para sa certificate sa Apache sa halip na nginx, at kapag hindi puwedeng gumamit ng public certificate, sapat para sa internal services ang self-signed certificate sa Ubuntu.

FAQ

Kailangan bang bukas ang port 80 kung HTTPS lamang ang inihahatid ng site ko?

Oo, para sa HTTP-01 challenge. Palaging sinisimulan ng Let’s Encrypt ang validation request sa port 80, at walang implementasyon ng TLS-ALPN-01 ang Certbot. Kaya kung 443 lamang ang pinapayagan ng firewall, mapipigilan nito ang unang pag-issue at bawat unattended renewal pagkatapos nito. Ayos lang ang redirect mula port 80 papuntang HTTPS; sinusundan ito ng validation. Ang tanging paraan para tuluyang laktawan ang port 80 ay ang paggamit ng DNS-01 kasama ang provider plugin.

apt o snap, alin ang dapat kong i-install na Certbot para sa nginx sa Ubuntu 24.04?

Gamitin ang apt. Ibinibigay ng sudo apt install certbot python3-certbot-nginx ang Certbot 2.9.0 sa Ubuntu 24.04, na sapat nang bago para sa lahat ng nasa gabay na ito. Tumatanggap din ito ng security patches sa pamamagitan ng unattended-upgrades at hindi nangangailangan ng snapd. Piliin lamang ang snap kung kailangan mo agad ang pinakabagong release o kung ang DNS plugin ay eksklusibong ipinapamahagi bilang snap. Alinman ang piliin mo, eksaktong isa lamang ang i-install: ang dalawang installation ay nangangahulugang may dalawang renewal timer na nakaturo sa parehong /etc/letsencrypt tree, at ang nakalimutang installation ang magdudulot ng problema.

Maaari bang mag-issue ang Certbot ng wildcard certificate para sa nginx?

Sa pamamagitan lamang ng DNS-01. Ang wildcard gaya ng *.example.com ay walang iisang hostname kung saan maaaring kunin ang challenge file. Kaya hindi magagamit ang --nginx, --webroot, at --standalone. I-install ang plugin para sa DNS provider mo, ilagay ang scoped API token sa credentials file na root lamang ang makakabasa, at patakbuhin ang certbot certonly --dns-cloudflare -d example.com -d '*.example.com'. I-quote ang wildcard upang hindi ito ma-expand ng shell bilang glob.

Bakit ang lumang certificate pa rin ang inihahatid ng nginx matapos ang matagumpay na renewal?

Nananatili sa memory ang certificate ng nginx at hindi nito napapansin ang bagong file sa disk hanggang sa mag-reload ito. Awtomatikong nagre-reload ang certbot --nginx, ngunit hindi ito ginagawa ng mga run ng --webroot at --standalone. Kaya maaaring matagumpay ang renewal habang expiring certificate pa rin ang nakikita ng browser. Maglagay ng executable script sa /etc/letsencrypt/renewal-hooks/deploy/ na nagpapatakbo ng nginx -t && systemctl reload nginx. Tatakbo ito matapos ang bawat matagumpay na renewal.

Pinatutunayan ba ng certbot renew --dry-run na gagana ang renewal?

Kadalasan. Isinasagawa nito ang aktuwal na challenge laban sa staging environment, gamit ang parehong firewall, DNS, at code path. Wala itong rate-limit cost at walang sinusulat sa disk, kaya ang matagumpay na resulta ay nangangahulugang maayos ang network side. Gayunman, hindi nito mapagkakatiwalaang napapatunayan na tatakbo ang deploy hook. Subukan iyon nang hiwalay: patakbuhin nang manu-mano ang hook script at tingnan ang sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf.