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 badala yake; tofauti ni ndogo, snap hufuata matoleo ya hivi karibuni kutoka kwa msanidi, wakati kifurushi cha archive hufuata toleo lililokuja na LTS na kupata marekebisho ya usalama pekee.

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

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 yenyewe, 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 kwa mteja asiyeweza kutumia ECDSA pekee. Hali yote huhifadhiwa chini ya /etc/letsencrypt: archive/ inashikilia funguo halisi na faili za vyeti, live/ ina viungo (symlinks) vya faili za sasa, renewal/ ina faili moja ya usanidi kwa kila cheti, accounts/ ina ufunguo wa akaunti yako ya ACME.

Jinsi HTTP-01 inavyofanya kazi, na kwa nini port 80 si ya hiari

Changamoto ya HTTP-01 ni utaratibu wa callback. Unaomba cheti kutoka Let's Encrypt kwa ajili ya example.com; wao hutatua jina hilo kwenye DNS ya umma, hufungua muunganisho kwenye port 80 katika anwani wanayoipata, na kuomba http://example.com/.well-known/acme-challenge/<token>. Seva yako hujibu kwa maudhui kamili ya token ambayo Certbot imeandika kwenye diski. Huo ndio utaratibu mzima. Matokeo matatu hutokana na hili, na ndiyo sababu kuu ya kushindwa kwa utoaji wa vyeti.

• 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 husababisha utoaji wa cheti na kila renewal ya baadaye kufeli.
• DNS lazima iwe tayari inaelekeza kwenye seva hii. Seva ya uthibitishaji hufanya lookup yake yenyewe kutoka nje; entries zako za /etc/hosts na cache ya kivinjari chako 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 husababisha kufeli kabisa.

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

Kuchagua authenticator: --nginx, --webroot, --standalone

--nginx ndiyo chaguo-msingi sahihi wakati nginx tayari inafanya kazi na inahudumia domain husika. Certbot huchanganua usanidi wako, huweka eneo la muda la challenge, hupakia upya nginx, hufanya uthibitisho, kisha huandika maelekezo ya TLS kwenye server block yako. Hakuna downtime.

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

Kwa hati (scripted), kwenye seva mpya:

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

--webroot ni sahihi wakati hutaki Certbot iguse usanidi wa nginx yako, kama vile unapotumia template, kuhifadhi usanidi kwenye git, au kuusambaza kwa kutumia Ansible. Certbot huandika faili ya challenge pekee, kwenye saraka unayohudumia tayari.

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

--standalone ni sahihi wakati hakuna huduma inayosikiliza kwenye port 80: kama seva ya barua pepe, API inayozungumza 443 pekee, au script ya kwanza ya boot inayofanya kazi kabla nginx haijakuwepo. Certbot hujifunga kwenye port 80 yenyewe kwa sekunde chache. Ikiwa nginx inafanya kazi, hatua hii itafeli, kwa hivyo iache (stop) wakati wa mchakato huu:

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

Hooks hizo hurekodiwa kwenye usanidi wa kufanya upya (renewal) wa cheti, kwa hivyo kitendo hicho cha kusimamisha na kuanzisha huduma kitajirudia kiotomatiki wakati wa renewal.

Server 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, hakikisha curl -I http://example.com/ inajibu kutoka nje ya seva, kisha omba 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 isimeze ombi la challenge. Kuweka eneo hilo kwenye port 80 kunahakikisha kuwa renewals zinaendelea kufanya kazi baada ya tovuti nzima 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 server block ya reverse proxy, mstari kwa mstari inaelezea headers ambazo 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 directive tofauti ya http2 on;. Angalia nginx -v kwanza.

Elekeza nginx kwenye live/, kamwe usielekeze kwenye archive/. Symlinks za live/ hubadilishwa kuelekeza kwingine kila wakati wa renewal; njia ya kudumu (hard path) ndani ya archive/ itakufunga kwenye cheti kitakachoisha muda wake bila wewe kujua.

Wildcards inamaanisha DNS-01, na DNS-01 inamaanisha 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 kuingiliwa na binadamu, ndiyo maana plugins za mtoa huduma zipo. Mwongozo kamili wa cheti cha wildcard unaelezea utaratibu wa 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. Hii 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 zimebaki chini ya siku 30, jambo linalokupa muda wa siku 30 ambapo upyaji ulioshindwa ni usumbufu unaoweza kurekebishika badala ya kuwa hitilafu ya huduma. Let’s Encrypt haitumi tena barua pepe za onyo la kuisha kwa 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 muda wa 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 peke yake, 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 katika 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 hasa tovuti huendelea 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 itafaulu leo, usasishaji wa kiotomatiki baada ya siku 60 utafaulu pia, tukizingatia kuwa hakuna kinachobadilika kwenye seva yenyewe.

Dry run haithibitishi kama reload hook yako inafanya kazi; tabia hiyo hutofautiana kulingana na toleo la Certbot. Jaribu sehemu hiyo kwa mkono: endesha script ya hook moja kwa moja, thibitisha kuwa systemctl reload nginx inafaulu, na uangalie sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf.

Hitilafu utakazokutana nazo kihalisi

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 ambayo si 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; ikitoa 404, cheti hakijawahi kuwa tatizo.

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

too many certificates already issued for: example.com, kikomo cha kasi (rate limit), na ndilo tatizo ambalo watu hukutana nalo wanapofanya debugging kwa kurudia-rudia. 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 kizuizi 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 ajili ya 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.

Usimamizi wa kiwango kikubwa

Cheti kimoja kinaweza kubeba hadi majina 100, na kutumia certbot --nginx -d a.example.com -d b.example.com ... moja kunavutia, hadi pale rekodi moja ya DNS iliyopitwa na wakati inaposhindwa uthibitisho 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 kufikisha tovuti kadhaa, lango la mbele linalotambua ACME huwa na faida: Traefik reverse proxy inayotumia programu nyingi chini ya Docker Compose huomba na kuhuisha vyeti vyenyewe, na Certbot huondolewa kabisa kwenye mchakato. Ni proxy ipi inayofaa kwenye lango hilo ni uamuzi wako, na kulinganisha Nginx dhidi ya Caddy na Traefik kwa kiasi kikubwa hutegemea ni kiasi gani cha kazi ya cheti na usanidi wa kila programu unachotaka proxy ikufanyie.

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

Ukijenga upya seva au kuhamia kwenye toleo jipya la LTS, kipima muda cha kuhuisha 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 hufeli baada ya siku 89, saa 9 usiku, kwenye cheti ambacho kila mtu alidhani kinajihuisha chenyewe.

Yote haya yanadhani 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 hutumika kwenye Apache badala ya nginx, na wakati cheti cha umma si chaguo, cheti kilichojitolea (self-signed) kwenye Ubuntu hufaa kwa huduma za ndani.

FAQ

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

Ndiyo, kwa ajili ya changamoto ya HTTP-01. Let's Encrypt huanza ombi lake la uthibitishaji kwenye port 80, na Certbot haina utekelezaji wa TLS-ALPN-01, kwa hivyo firewall inayofungua port 443 pekee itazuia utoaji wa kwanza na kila ufanyaji upya (renewal) wa kiotomatiki baada ya hapo. Redirect kutoka port 80 kwenda HTTPS inakubalika, uthibitishaji utaifuata. Njia pekee ya kuruka port 80 kabisa ni kutumia DNS-01 pamoja na plugin ya mtoa huduma wako.

apt au snap, ni Certbot ipi ninayopaswa 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. Kwa vyovyote vile, chagua moja tu: usakinishaji mbili unamaanisha vipima muda viwili vya renewal vinavyoelekeza kwenye mti uleule wa /etc/letsencrypt, na ile iliyosahaulika ndiyo itakayokuletea matatizo.

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

Kupitia DNS-01 pekee. Wildcard kama *.example.com haina hostname moja ya kuchotea faili la changamoto, kwa hivyo --nginx, --webroot na --standalone zote hazifanyi kazi. Sakinisha plugin kwa ajili ya mtoa huduma wako wa DNS, weka API token yenye uwezo mdogo kwenye faili la vitambulisho linaloweza 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 inatoa cheti cha zamani baada ya renewal kufanikiwa?

nginx huhifadhi cheti kwenye kumbukumbu (memory) na haioni faili jipya kwenye diski hadi itakapopakia upya (reload). certbot --nginx hufanya reload kwa ajili yako, lakini --webroot na --standalone hazifanyi hivyo, kwa hivyo renewal inaweza kufanikiwa wakati kivinjari bado kinaona cheti kinachokaribia kuisha muda wake. Weka script inayoweza kutekelezeka ndani ya /etc/letsencrypt/renewal-hooks/deploy/ inayotekeleza 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.