Jinsi ya kusakinisha Certbot kwenye Ubuntu 24.04

Sakinisha Certbot: apt au snap

Kwenye Ubuntu 24.04, sudo apt install certbot python3-certbot-nginx inakupa Certbot inayofanya kazi na kutoa vyeti halisi vya Let's Encrypt vinavyoaminika hadharani. Nyaraka za Certbot zinapendekeza kutumia snap; tofauti ni ndogo, snap hufuata matoleo ya hivi karibuni kutoka kwa msanidi, wakati kifurushi cha archive hufuata toleo lililokuja na LTS na kupokea marekebisho ya usalama.

Chagua moja. Kuwa na nakala mbili za Certbot kunamaanisha vipima muda viwili vya kusasisha (renewal timers) vinavyolenga mti uleule wa /etc/letsencrypt, na ile uliyoisahau ndiyo itakayokushangaza.

Njia ya apt:

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

Hii inasakinisha /usr/bin/certbot, plugin ya nginx, jozi ya certbot.service + certbot.timer, na ingizo la /etc/cron.d/certbot ambalo halifanyi kazi chini ya systemd.

Njia ya 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 inakuja na kipima muda chake, snap.certbot.renew.timer. Ondoa kifurushi cha apt kabla ya kusakinisha snap.

Usakinishaji wote hufanya kazi kwa njia sawa baada ya hapo. Certbot 2.x hutumia funguo za ECDSA (P-256) kama chaguo-msingi, pitisha --key-type rsa tu kwa mteja asiyeweza kutumia ECDSA. Hali yote huhifadhiwa chini ya /etc/letsencrypt: archive/ inashikilia funguo halisi na faili za vyeti, live/ ina viungo vya mfumo (symlinks) kuelekea faili za sasa, renewal/ ina faili moja ya usanidi kwa kila cheti, accounts/ ina ufunguo wa akaunti yako ya ACME.

Kile ambacho HTTP-01 hufanya kihalisi, na kwa nini port 80 si ya hiari

Changamoto ya HTTP-01 ni utaratibu wa callback. Unaiomba Let's Encrypt cheti kinachohusu example.com; inatafuta jina hilo kwenye DNS ya umma, inafungua muunganisho kwenye port 80 katika anwani inayopata, na kuomba http://example.com/.well-known/acme-challenge/<token>. Seva yako inajibu kwa maudhui kamili ya token ambayo Certbot imeiandika kwenye diski. Huo ndio utaratibu mzima. Matokeo matatu yanatokana na hili, na ndiyo sababu ya kushindwa kwa utoaji wa vyeti mara nyingi.

• Port 80 lazima iweze kufikiwa kutoka kwenye Internet ya umma, si kutoka kwenye laptop yako pekee. Sheria ya ufw, security group ya mtoa huduma wa cloud, au firewall ya VPS-console inayofungua port 443 pekee itasababisha utoaji wa cheti kufeli, pamoja na kila renewal ya baadaye.
• DNS lazima iwe inaelekeza kwenye seva hii. Seva ya uthibitishaji hufanya lookup yake yenyewe kutoka nje; entries zako za /etc/hosts na cache ya browser hazina maana yoyote kwake.
• Uchapishaji wa AAAA record husababisha IPv6 kujaribiwa kwanza. Let's Encrypt hujaribu tena kupitia IPv4 wakati muunganisho wa IPv6 unapofeli kabisa, lakini AAAA record iliyopitwa na wakati inayoelekeza kwenye host inayokubali muunganisho na kutoa kitu kingine itakupa hitilafu ya moja kwa moja.

Redirects zinaruhusiwa: uthibitishaji hufuata HTTP redirect kwenda HTTPS na haujali kama cheti kilicho upande mwingine hakipo, kimepitwa na wakati, au kimejitiwa saini (self-signed). Kile ambacho hakitafanya ni kuanza popote pengine isipokuwa port 80. Certbot haina utekelezaji wa TLS-ALPN-01, kwa hivyo "tumia tu 443" si njia ya mkato.

Choosing an authenticator: --nginx, --webroot, --standalone

--nginx is the right default when nginx already runs and already serves the domain. Certbot parses your config, injects a temporary challenge location, reloads nginx, validates, then writes the TLS directives into your server block. No downtime.

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

Scripted, for a fresh box:

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

--webroot is right when you want Certbot nowhere near your nginx config, one you generate from a template, keep in git, or push with Ansible. Certbot writes only the challenge file, into a directory you already serve.

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

--standalone is right when nothing listens on port 80: a mail server, an API that only speaks 443, a first-boot script that runs before nginx exists. Certbot binds port 80 itself for a few seconds. If nginx is running, this fails, stop it around the run:

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

Those hooks are recorded in the certificate's renewal config, so the same stop/start happens unattended at renewal.

Seva block inayofanya kazi kabla na baada ya cheti kuwepo

Tatizo la kuku na yai: nginx inakataa kuanza ikiwa ssl_certificate inaelekeza kwenye faili lisilokuwepo, na Certbot haiwezi kufanya uthibitisho wakati nginx imezimwa. Washa tovuti kwenye port 80 kwanza.

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

Tekeleza sudo nginx -t && sudo systemctl reload nginx, thibitisha curl -I http://example.com/ inajibu kutoka nje ya seva, kisha fanya utoaji wa cheti. Baada ya hapo:

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

Kiambishi ^~ kwenye eneo la ACME kina faida yake: kinazuia block ya return 301 kumeza ombi la challenge. Kuweka eneo hilo kwenye port 80 kunahakikisha kuwa ufanyaji upya (renewals) unaendelea kufanya kazi baada ya sehemu nyingine ya tovuti kubadilishwa kuwa HTTPS pekee.

Blocks zote mbili hapo juu zinahudumia faili kutoka kwenye diski; ikiwa nginx inafanya kazi kama mbele ya programu (reverse proxy), location / inakuwa block ya proxy_pass na seva block ya reverse proxy, mstari kwa mstari inaelezea vichwa vya habari (headers) ambavyo programu hiyo inahitaji, huku eneo la ACME na maelekezo ya TLS yakibaki kama yalivyo.

Syntax ya HTTP/2 inategemea toleo lako la nginx, na kuchanganya aina hizo mbili husababisha hitilafu wakati wa kuanza. Ubuntu 24.04 inakuja na nginx 1.24, ambayo inataka iwekwe ndani ya mstari, listen 443 ssl http2;. Debian 13 inakuja na nginx mpya zaidi, ambayo inataka maelekezo tofauti ya http2 on;. Angalia nginx -v kwanza.

Elekeza nginx kwenye live/, kamwe usielekeze kwenye archive/. Viungo vya live/ (symlinks) hubadilishwa kuelekeza kwingine kila wakati cheti kinapofanywa upya; njia ya kudumu (hard path) ndani ya archive/ itakufunga kwenye cheti kitakachoisha muda wake bila wewe kujua.

Wildcards humaanisha DNS-01, na DNS-01 humaanisha plugin

Cheti cha wildcard (*.example.com) hakiwezi kuhakikiwa kupitia HTTP-01, kwa sababu hakuna hostname moja ya kuchotea faili. DNS-01 ndiyo njia pekee: unathibitisha umiliki kwa kuchapisha rekodi ya TXT ya _acme-challenge.example.com. Certbot inahitaji vitambulisho vya API vya mtoa huduma wako wa DNS ili kufanya hivyo bila usimamizi wa binadamu, ndiyo maana plugins za watoa huduma zipo. Mwongozo kamili wa cheti cha wildcard unaelezea mbinu za rekodi ya TXT na mtego wa kusasisha (renewal) katika hali ya mwongozo; toleo fupi la Cloudflare linafuata hapa chini.

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

Kwenye njia ya apt hiyo ni sudo apt install python3-certbot-dns-cloudflare badala yake. Vitambulisho huwekwa kwenye faili inayoweza kusomwa na root pekee:

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

Punguza uwezo wa token hiyo iwe na haki za DNS-edit kwenye zone hiyo moja pekee. Hiyo ni ufunguo wa DNS yako; itunze kama ufunguo.

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

Weka alama za kunukuu (quotes) kwenye wildcard ili shell yako isijaribu kuifanyia glob. DNS-01 pia hutatua kile ambacho HTTP-01 haiwezi: vyeti kwa ajili ya hosts zisizo na port 80 ya umma, huduma ya ndani, seva inayoweza kufikiwa tu kupitia WireGuard VPN inayojiendesha kwenye VPS, au paneli ya usimamizi kwenye interface ya faragha.

Upyaji: siku 90, kipima muda, na deploy hook

Vyeti vya Let's Encrypt ni halali kwa siku 90. Certbot hufanya upyaji wakati zimesalia chini ya siku 30, jambo linalokupa muda wa siku 30 ambapo upyaji ulioshindwa ni usumbufu unaoweza kurekebishika badala ya kuwa tatizo la kukatika kwa huduma. Let's Encrypt haitumi tena barua pepe za onyo la kuisha kwa muda wa cheti, hakuna atakayekukumbusha, kwa hivyo ufuatiliaji ni jukumu lako sasa.

Kagua kipima muda kilichokuja na usakinishaji wako:

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

certbot renew hupitia kila usanidi katika /etc/letsencrypt/renewal/, huruka chochote kilicho nje ya dirisha la siku 30, na kufanya upyaji wa vingine kwa kutumia flag zilezile za mara ya kwanza. Hii ndiyo sababu mara ya kwanza ni muhimu: ndiyo inayohifadhiwa kwenye kumbukumbu.

Kufanya upyaji wa faili kwenye diski hakubadilishi chochote chenyewe, nginx huendelea kutoa cheti cha zamani kutoka kwenye kumbukumbu hadi kitu fulani kiiambie kipakie upya. Unganisha deploy hook mara moja:

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

Chochote kinachoweza kutekelezwa ndani ya renewal-hooks/deploy/ huendeshwa baada ya upyaji wowote uliofanikiwa. Flag ya --deploy-hook hufanya kazi hiyo hiyo kwa cheti kimoja, ikihifadhi renew_hook = ... katika usanidi wake wa upyaji. certbot --nginx hupakia upya kwa ajili yako; usanidi wa --webroot na --standalone haufanyi hivyo. Hook iliyokosekana ndiyo sababu kamili ya tovuti kutoa cheti kilichoisha muda wake wakati certbot certificates ikiripoti kwa furaha kuwa cheti ni kipya. Kitu kingine chochote kinachosoma cheti wakati wa kuanza kinahitaji hook hiyo hiyo, programu iliyo kwenye container kama vile Nextcloud VPS install with Docker, TLS and backups inahitaji hatua yake ya kuanzisha upya au kupakia upya iunganishwe hapa pia.

Kujaribu usasishaji kwa uhalisia

sudo certbot renew --dry-run

Hii huendesha changamoto kamili dhidi ya mazingira ya staging ya Let's Encrypt: njia ileile ya msimbo, firewall ileile, DNS ileile, hakuna gharama ya rate-limit, na hakuna kinachoandikwa kwenye diski. Ikiwa jaribio hili litafanikiwa leo, usasishaji wa kiotomatiki baada ya siku 60 utafanikiwa pia, kwa sharti kuwa hakuna kitakachobadilika kwenye seva.

Jaribio la awali (dry run) halithibitishi kama reload hook yako inafanya kazi, kwani tabia hiyo hutofautiana kulingana na toleo la Certbot. Jaribu sehemu hiyo kwa mkono: endesha hati ya hook moja kwa moja, thibitisha kuwa systemctl reload nginx inafanikiwa, na uangalie sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf.

Hitilafu utakazokutana nazo

Could not bind to IPv4 or IPv6., --standalone wakati nginx tayari inashikilia port 80. Tumia --nginx au --webroot, au simamisha nginx wakati wa uendeshaji. Thibitisha kinachoshikilia port hiyo kwa sudo ss -lntp | grep ':80'.

Timeout during connect (likely firewall problem), Let's Encrypt haikuweza kufikia port 80. Chunguza kuanzia nje: sudo ufw status (ifungue kwa sudo ufw allow 'Nginx Full'), kisha firewall ya mtoa huduma wa VPS, na mwisho DNS. Jaribu kutoka sehemu nyingine nje ya seva yako: curl -sSv http://example.com/.well-known/acme-challenge/test. Rekodi ya AAAA iliyopitwa na wakati husababisha ujumbe huu pia.

unauthorized :: Invalid response from http://example.com/.well-known/acme-challenge/xyz: 404, port 80 inafikika, lakini token haitolewi. Ombi limefika kwenye server block tofauti (angalia ni ipi inayomiliki default_server), au saraka iliyopitishwa kwa -w si ile inayotumiwa na nginx. Weka faili kwenye /var/www/example.com/.well-known/acme-challenge/test na uijaribu kutoka nje; ikiwa inaleta 404, cheti hakikuwa tatizo.

DNS problem: NXDOMAIN looking up A for example.com, jina halitafsiriwi hadharani. Hii hutokea kwa rekodi mpya ambazo hazijasambaa, au rekodi iliyo kwenye zone ambayo msajili wako haihudumii.

too many certificates already issued for: example.com, kikomo cha kasi (rate limit), na ndicho watu hukutana nacho wanapofanya debugging mara kwa mara. Let's Encrypt huweka kikomo cha vyeti vinavyofanana, yaani seti ileile ya majina, hadi vitano kwa wiki, na pia huruhusu vyeti vipya 50 kwa kila domain iliyosajiliwa kwa wiki; hakuna kinachoweza kuondoa kikomo hiki isipokuwa muda. Fanya debugging dhidi ya staging kwa kutumia --dry-run.

nginx: [emerg] cannot load certificate "/etc/letsencrypt/live/example.com/fullchain.pem": No such file or directory, nginx imesanidiwa kwa cheti ambacho hakijawahi kutolewa, au kilichoondolewa kwa certbot delete. Toa maoni (comment out) kwenye TLS server block, anzisha nginx, toa cheti, kisha rudisha block hiyo.

open() "/etc/letsencrypt/options-ssl-nginx.conf" failed, faili hiyo huja na kifurushi cha plugin ya nginx. Kwenye mashine ya certonly isiyo na python3-certbot-nginx, ongeza plugin hiyo au badilisha mstari wa include na mipangilio yako ya ssl_protocols na ssl_ciphers.

Kusimamia hili kwa kiwango kikubwa

Cheti kimoja kinaweza kubeba hadi majina 100, na certbot --nginx -d a.example.com -d b.example.com ... moja inajaribu, hadi pale rekodi moja ya DNS iliyopitwa na wakati inaposhindwa uthibitishaji na kusababisha majina mengine yote kwenye cheti hicho kufeli. Vyeti tofauti kwa kila tovuti hufeli kivyake, jambo ambalo ni muhimu kwenye seva inayohudumia zaidi ya vitu vichache. Baada ya tovuti chache, mlango wa mbele unaoelewa ACME unajilipa: Traefik reverse proxy inayoendesha programu nyingi chini ya Docker Compose huomba na kusasisha vyeti vyenyewe, na Certbot huondolewa kabisa kwenye mchakato. Ni proxy ipi inayofaa kwenye mlango huo wa mbele ni uamuzi wako, na kulinganisha Nginx na Caddy na Traefik mara nyingi hutegemea ni kiasi gani cha kazi ya cheti na usanidi wa kila programu unachotaka proxy ikufanyie.

Hifadhi nakala ya /etc/letsencrypt nzima, sudo tar -czf letsencrypt-$(date +%F).tar.gz -C /etc letsencrypt, huku symlinks zikiwa salama. Mti huo unashikilia accounts/, ufunguo wa akaunti yako ya ACME, ambao huwezi kuutengeneza upya ukiwa sawa na ule wa awali. Kuhamia kwenye VPS mpya basi kunakuwa rahisi: rsync mti huo kwa kutumia -a, sakinisha Certbot, elekeza upya DNS, na uendeshe certbot renew --dry-run kabla ya kuhama.

Jenga upya seva au hama kwenda kwenye LTS mpya na kipima muda cha kusasisha hakitakufuata. Baada ya uhamiaji wowote, kurejesha snapshot, au kuboresha distro, endesha systemctl list-timers 'certbot*' na --dry-run moja. Kuruka hatua hiyo ndiyo sababu tovuti huzimika baada ya siku 89, saa 9 usiku, kwenye cheti ambacho kila mtu alidhani kinajisasisha chenyewe.

Yote haya yanachukulia kuwa una mashine unayoimiliki, yenye IP ya umma na port 80 iliyo wazi kwa ulimwengu, kwa maneno mengine, VPS. Mbinu zilizo hapo juu ni sawa kwa yoyote kati yao.

Hatua zilezile za cheti zinatumika kwenye Apache badala ya nginx, na wakati cheti cha umma si chaguo, cheti kilichojitolea (self-signed) kwenye Ubuntu hufunika huduma za ndani.

FAQ

Je, ninahitaji kufungua port 80 ikiwa tovuti yangu inahudumia HTTPS pekee?

Ndiyo, kwa ajili ya changamoto ya HTTP-01. Let's Encrypt huanza ombi lake la uthibitishaji kwenye port 80 kila wakati, na Certbot haina utekelezaji wa TLS-ALPN-01, kwa hivyo firewall inayofungua port 443 pekee itazuia utoaji wa kwanza na kila ufanyaji upya wa cheti (renewal) unaofuata. Kuelekeza (redirect) trafiki kutoka port 80 kwenda HTTPS ni sawa, uthibitishaji utafuata mwelekeo huo. Njia pekee ya kuruka port 80 kabisa ni kutumia DNS-01 pamoja na plugin ya mtoa huduma wako.

apt au snap, ni Certbot ipi ninapaswa kusakinisha kwa ajili ya nginx kwenye Ubuntu 24.04?

Tumia apt. sudo apt install certbot python3-certbot-nginx inakupa Certbot 2.9.0 kwenye Ubuntu 24.04, ambayo ni ya kisasa vya kutosha kwa kila kitu katika mwongozo huu, inapata viraka vya usalama kupitia unattended-upgrades, na haihitaji snapd. Chagua snap ikiwa tu unahitaji toleo jipya zaidi mara moja au plugin ya DNS inayosambazwa kama snap pekee. Vyovyote vile, chagua moja tu: usakinishaji mbili unamaanisha vipima muda viwili vya renewal vinavyoelekeza kwenye mti uleule wa /etc/letsencrypt, na ile inayosahaulika ndiyo itakayokuletea matatizo.

Je, Certbot inaweza kutoa cheti cha wildcard kwa ajili ya nginx?

Inawezekana kupitia DNS-01 pekee. Wildcard kama *.example.com haina hostname moja ya kuchotea faili ya changamoto, kwa hivyo --nginx, --webroot na --standalone zote hazifanyi kazi. Sakinisha plugin ya mtoa huduma wako wa DNS, weka token ya API yenye uwezo mdogo katika faili ya vitambulisho inayoweza kusomwa na root pekee, na uendeshe certbot certonly --dns-cloudflare -d example.com -d '*.example.com', huku ukiweka alama za kunukuu kwenye wildcard ili kuzuia shell kuifanyia globbing.

Kwa nini nginx bado inahudumia cheti cha zamani baada ya renewal kufanikiwa?

nginx huhifadhi cheti kwenye kumbukumbu (memory) na haioni faili mpya kwenye diski hadi itakapopakia upya (reload). certbot --nginx hufanya reload kwa ajili yako, lakini --webroot na --standalone hazifanyi hivyo, kwa hivyo renewal inaweza kufanikiwa huku kivinjari kikiona cheti kinachokaribia kuisha muda wake. Weka script inayoweza kutekelezeka ndani ya /etc/letsencrypt/renewal-hooks/deploy/ inayoiendesha nginx -t && systemctl reload nginx, na itafanya kazi baada ya kila renewal iliyofanikiwa.

Je, certbot renew --dry-run inathibitisha kuwa renewal itafanya kazi?

Kwa kiasi kikubwa. Inaendesha changamoto halisi dhidi ya mazingira ya staging, ikitumia firewall ileile, DNS ileile, na njia ileile ya msimbo, bila gharama ya rate-limit na bila kuandika chochote kwenye diski, kwa hivyo kupita mtihani huu kunamaanisha kuwa sehemu ya mtandao iko sawa. Hata hivyo, haithibitishi kwa uhakika kuwa deploy hook yako itafanya kazi. Ijaribu hiyo kando: endesha script ya hook kwa mkono na uangalie sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf.