Certbot Apache Ubuntu 24.04 usakinishaji

Unachojenga

Tovuti ya Apache kwenye Ubuntu 24.04 inayojibu kupitia HTTPS kwa kutumia cheti cha Let's Encrypt cha bure kinachoaminika na vivinjari — cheti hikitolewa na Certbot, na kuhuishawa moja kwa moja na kipima muda cha systemd ambacho hutahitaji kukifikiria tena. Amri inayofanya kazi ni mstari mmoja tu. Kila kitu kinachokwenda vibaya kinakwenda vibaya kabla ya mstari huo: vhost isiyo na ServerName, lenti 80 imefungwa kwenye ukuta wa moto wa mtoa huduma, au DNS bado inaelekeza kwenye seva ya zamani. Kwa hiyo mwongozo huu hutumia muda mwingi katika kuelezea masharti ya awali, na kuorodhesha ujumbe halisi wa kosa ambao kila makosa hulitangaza.

Maelezo mawili kuhusu wigo. Kama seva yako ya wavuti ni nginx, mchakato una umbo lile lile lakini programu-jalizi na usanidi hutofautiana — tumia toleo la nginx la mwongozo huu badala yake. Na kama kile unachohakikisha usalama wake ni cha ndani tu — paneli ya usimamizi kwenye anwani ya faragha, au seva ya majaribio ambayo hakoi mwingine anaitembelea — huhitaji mamlaka ya cheti kabisa; cheti kilichosainiwa na wewe mwenyewe kinatumia vifaa machache na kinaweza kufanya kazi bila mtandao.

Masharti, na njia tatu hukifeli kabla Certbot hajaanza

• Apache tayari inatumia tovuti yako kupitia HTTP ya kawaida. Programu-jalizi ya Apache ya Certbot inahariri tovuti iliyopo; haizengataki mpya. Kama unatoka kwenye VPS tupu, jenga seti ya LAMP kwenye Ubuntu 24.04 kwanza kisha urudi — mwongozo huu ni sura yake ya TLS iliyokosekana.
• Kikoa cha umma chenye rekodi A kwenye anwani ya VPS yako. Changamoto ya HTTP-01 ya Let's Encrypt inamaanisha seva zao za uthibitishaji zinaunganishwa na kompyuta yako kutoka mtandaoni: hakuna homelab ya NAT bila usambazaji bandari, hakuna majina ya .local, hakuna anwani za IP tupu. dig +short example.com lazima irudishe anwani ya VPS yako, na kama ulibadilisha DNS ndani ya saa iliyopita, subiri muda wa TTL wa rekodi ya zamani kupita kabla ya kutoa.
• Kama rekodi ya AAAA ipo, lazima iwe sahihi. Let's Encrypt inapendelea IPv6 wakati rekodi ya AAAA inachapishwa, hivyo AAAA iliyopitwa muda wake hufeli uthibitishaji hata wakati curl kutoka kwenye kompyuta yako — huenda kwenye IPv4 — inafanya kazi vizuri. Chapisha AAAA sahihi au usichapishe kabisa.

Bandari 80 na 443 zinahitaji kuwa wazi kwenye ufw na katika ukuta wa moto wa mtandao wa mtoa huduma wako — paneli nyingi za hosting zina ukuta wa moto wa pili ambao OS haumuoni kamwe. HTTP-01 inathibitisha kupitia bandari 80 mahususi; huwezi kuendesha hii kwenye 443 pekee.

sudo ufw allow "Apache Full"
sudo ufw status

Ukiwa na hayo yote, kazi nzima inachukua dakika kumi na tano, na kumi kati ya hizo ni za kusoma.

Certbot wa snap au apt? Kwenye 24.04, apt hatimaye ni sawa

Certbot ilibadilishwa kusambazwa kwa snap miaka iliyopita kwa sababu nzuri: pakiti za usambazaji zilikuwa zimepitwa na wakati. Ubuntu 20.04 ilitoa Certbot 0.40 na haikubadilika kamwe, na mradi ukauchoka kusahihisha hitilafu za miaka mitano. Kwenye 24.04 sababu hiyo haipo tena — hifadhi inatoa Certbot 2.9.0, toleo la kizazi cha sasa, na unattended-upgrades inalitunza kwa visahisho. Mapendekezo yangu kwa mfumo huu wa uendeshaji: tumia apt. Unakwepa daemon ya snapd, kifaa cha Apache kinasakinishwa katika muamala huo huo, na kipima muda cha upya kinaungana na systemd kwa njia ya kawaida ya Debian.

sudo apt update
sudo apt install -y certbot python3-certbot-apache
certbot --version

Matokeo sahihi: certbot 2.9.0. Pakiti ya python3-certbot-apache ni kifaa kinachosoma na kuhariri usanidi wako wa Apache — bila hicho, certbot --apache hufeli kwa The requested apache plugin does not appear to be installed.

Snap bado ni chaguo sahihi katika hali mbili: unataka Certbot mpya kabisa siku inayochochwa, au unahitaji kifaa cha DNS kinachosambazwa kama snap pekee (baadhi ya viwazo vya watoa huduma wa certbot-dns-* ndivyo hivyo). Ukichagua njia hiyo:

sudo apt remove -y certbot python3-certbot-apache
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Iwe umechagua ipi, usiwahi kuendesha vyote viwili. Usakinishaji mara mbili una maana ya vipima muda viwili vya upya vinavyoshindana juu ya /etc/letsencrypt, na certbot ambayo ganda lako linapata kwenye PATH huenda isiwahi kuwa ile inayomiliki vyeti vyako. Mstari wa apt remove hapo juu si mapambo ya hiari.

vhost anayoiharisha Certbot lazima iwepo tayari — ServerName ndio kila kitu

certbot --apache hufanya kazi kwa kutafuta mwenyeji pepe wa bandari 80 ambao ServerName au ServerAlias wake unalingana na kila kikoa cha -d unachopitisha, kuthibitisha udhibiti wa kikoa kupitia huo, kisha kuandika nakala ya SSL ya huo vhost. Hakikuna ServerName inayolingana, hakuna usawaziko — na chaguo-msingi ya Ubuntu 000-default.conf huja na ServerName ikiwa imetiwa maoni. Mstari huo mmoja uliotiwa maoni ndio sababu inayotokea zaidi ambayo amri kuu moja ya mwongozo huu hushindwa.

Kwa hivyo kabla ya kugusa Certbot, peana tovuti mwenyeji pepe wa kawaida unaotegemea jina. Unda /etc/apache2/sites-available/example.com.conf:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com
    ErrorLog ${APACHE_LOG_DIR}/example.com-error.log
    CustomLog ${APACHE_LOG_DIR}/example.com-access.log combined
</VirtualHost>

Iwezeshe na thibitisha kwamba Apache inaisoma na kuelekeza jina kwake:

sudo a2ensite example.com.conf
sudo apache2ctl configtest
sudo systemctl reload apache2
sudo apache2ctl -S

configtest lazima ichapishe Syntax OK. Kama pia itachapisha AH00558: apache2: Could not reliably determine the server's fully qualified domain name, hiyo ni onyo kuhusu ServerName ya kimataifa, sio vhost yako — haina madhara hapa, na hufutwa na echo "ServerName $(hostname -f)" | sudo tee /etc/apache2/conf-available/servername.conf && sudo a2enconf servername && sudo systemctl reload apache2.

Matokeo ya -S ndiyo ukaguzi muhimu. Unahitaji mstari kama port 80 namevhost example.com (/etc/apache2/sites-enabled/example.com.conf:1) ukiwa na alias www.example.com chini yake — Apache inaripoti kiungo ishara cha sites-enabled ambacho kilisomwa kwa kweli, sio faili uliyoiharisha katika sites-available. Kama example.com haijaorodheshwa dhidi ya bandari 80, Certbot pia haitakipata.

Toa cheti: certbot --apache

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

Uendeshaji wa kwanza unauliza mambo matatu: anwani ya barua pepe (inayotumika kwa akaunti yako ya ACME na taarifa za dharura za CA; Let's Encrypt haileti tena onyo la kumalizika muda, hivyo ufuatiliaji wa upya unabaki kwako), makubaliano na sheria za Let's Encrypt, na kama unataka kushiriki barua pepe yako na EFF. Hakuna swali la uelekeo tena: kuanzia Certbot 2.0 kifungashi cha Apache huelekeza HTTP kwenda HTTPS kwa chaguo-msingi, ambayo ndiyo unachotaka. Pitisha --no-redirect ikiwa kweli unahitaji HTTP ya wazi kuendelea kutoa maudhui.

Mafanikio yanaonekana kama hivi, na unapaswa kuyasoma badala ya kuyapitia kwa haraka:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/example.com/privkey.pem
This certificate expires on 2026-10-14.

Deploying certificate
Successfully deployed certificate for example.com to /etc/apache2/sites-available/example.com-le-ssl.conf
Successfully deployed certificate for www.example.com to /etc/apache2/sites-available/example.com-le-ssl.conf
Congratulations! You have successfully enabled HTTPS on https://example.com and https://www.example.com

Nyuma ya ujumbe huo Certbot ilifanya mambo manne: iliwezesha moduli ya ssl ya Apache ikiwa haikuwasha tayari, iliandika example.com-le-ssl.conf — nakala ya vhost yako kwenye *:443 ikiwa na SSLEngine on na njia za cheti — iliwezesha, na iliongeza kizuizi cha RewriteRule kwenye vhost ya asili ya bandari-80 inayoelekeza yote 301 kwenda HTTPS. Faili yako ya asili ya vhost imehaririwa, haijachukuliwa nafasi, na vhost pacha ya SSL inakaa pembeni ambapo unaweza kusoma kila mstari iliyoongezwa.

Hapa ambapo cheti huwekwa kimsingi, na kwanini hukitengeneza nakala kamwe

Kila kitu huwekwa chini ya /etc/letsencrypt/live/example.com/: fullchain.pem (cheti pamoja na mnyororo wa kati — hili ndilo seva zinapaswa kulitumia), privkey.pem (ufunguo binafsi, unaweza kusomwa na root tu), pamoja na cert.pem na chain.pem kwa ajili ya programu zinazotaka vipengele hivi kivyake. Hizi ni viungo vimewasilisha kwenye /etc/letsencrypt/archive/, na mwelekeo huo ndio utaratibu wa upyaishaji: upyaishaji huandika faili mpya kwenye archive/ na kurekebisha viungo. Elekeza programu yoyote nyingine kwenye njia za live/ na itapata upyaishaji bila gharama ya ziada; tengeneza nakala ya faili mahali utapata mfauto wa kukatika kwa huduma baada ya siku 90.

Faili nyingine muhimu ya kujua ni /etc/letsencrypt/renewal/example.com.conf, ambayo inarekodi jinsi cheti hiki kilivyotolewa — authenticator = apache, installer = apache, na majina ya vikoa — ili upyaishaji uweze kurudia mchakato huo bila usimamizi, ikiwa ni pamoja na kupakia upya Apache baadaye.

Upyaishaji umeshapangwa tayari — thibitisha, usijenge

Cheti cha Let's Encrypt hudumu siku 90 kwa muundo wake, na kifurushi cha apt kimeshaweka tayari utendaji: timer ya systemd inayoendesha Certbot mara mbili kwa siku katika nyakati zisizotabiriwa, ikiupya cheti chochote kilichopo ndani ya siku 30 kabla ya kumalizika muda wake. Usiongeze kazi ya cron juu ya hilo; mpangaji wa pili haongezi chochote isipokuwa kelele kwenye kumbukumbu na hatari ya kufikia kikomo cha maombi.

systemctl list-timers certbot.timer
sudo certbot renew --dry-run

Amri ya kwanza inaonyesha timer ikiwa amilifu, ikiwa na muda wa NEXT mahali popote ndani ya masaa 24 yajayo — ratiba ni mara mbili kwa siku ikiwa na kuchelewa kisichotabiriwa, hivyo wakati halisi umekusudiwa usiweze kutabiriwa (kwenye usakinishaji wa snap, timer ni snap.certbot.renew.timer badala yake). Uendeshaji wa majaribio unafanya mazoezi kamili ya upyaishaji dhidi ya mazingira ya majaribio ya Let's Encrypt — changamoto halisi, hakuna cheti kinachotolewa, hakuna gharama ya kikomo cha maombi. Matokeo sahihi huishia na:

Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/example.com/fullchain.pem (success)

Ikiwa uendeshaji wa majaribio unashindwa, upyaishaji halisi katika siku ~60 zijazo utashindwa kwa njia ile ile — rekebisha sasa, wakati cheti cha sasa bado kina muda wote wa maisha mbele yake. Sababu ya kawaida ni kanuni ya firewall iliyoongezwa baada ya utoaji cheti ambayo ilifunga tena port 80.

Hakiki kwa kutumia curl, na kile ambacho ishara ya kufunguwa inapaswa kuonyesha

curl -sI http://example.com | head -n 3
curl -I https://example.com
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -issuer -dates

Amri ya kwanza inapaswa kurudisha HTTP/1.1 301 Moved Permanently ikiwa na kichwa cha Location: https://example.com/ — hilo ni mwelekeo upya uliowekwa na Certbot. Amri ya pili inapaswa kurudisha HTTP/1.1 200 OK bila curl kutoa malalamiko yoyote kuhusu TLS. Amri ya tatu inachapisha mlengwa — safu ya O = Let's Encrypt ikiwa na CN fupi kama R12 au E7 — na notAfter kufikia takriban siku 90 zijazo. Kwenye kivinjari unaona ishara ya kufunguwa, na kuibofya inaonyesha mlengwa huyu huyo. Iwapo curl inafanya kazi lakini kivinjari kinatoa onyo, huenda ni ukurasa uliohifadhiwa au jina la mwenyeji lisilo sahihi unaliotazama, na sio shida ya cheti.

Tovuti nyingi: cheti kimoja cha SAN au cheti kimoja kwa kila tovuti

Njia zote zinafanya kazi; zote hufanyi upya upya kwa njia ile ile. Kwa tovuti zisizohusiana zinazofanya kazi katika seva moja, endesha amri ya kutolewa mara moja kwa kila tovuti — kila moja hupata saraka yake chini ya live/ na usanidi wake mwenyewe wa upya, na tatizo lenye kikoa kimoja halizuii kamwe upya wa vilivyo bachwa. Hiyo ndiyo chaguo langu la msingi.

Kwa tovuti moja yenye majina kadhaa, yaweke kwenye cheti kimoja cha SAN — cheti kimoja kinaweza kubeba majina hadi 100. Tayari umefanya hivi hapo juu na example.com na www.example.com. Ili kuongeza jina kwenye cheti kilichopo baadaye, toa tena ukikitaja cheti na orodha mpya kamili:

sudo certbot --apache --cert-name example.com -d example.com -d www.example.com -d blog.example.com

Certbot hugundua mabadiliko ya seti ya vikoa, kuuliza udhibitishe upanuzi, na kubadilisha cheti mahali pake — njia ile ile ya live/, hivyo hakuna kitu kingine kinachohitaji kuguswa. Elewa kwamba orodha hii ni kubadilisha, sio kuongeza: usiitaje www kwenye amri hiyo na cheti kipya kitaacha kimyakimya.

Vitambulisho sanifu vinahitaji DNS-01, na kwa kawaida huhitaji kitambulisho sanifu

HTTP-01 haliwezi kutoa *.example.com — kuweka faili kwenye seva ya wavuti kunathibitisha udhibiti wa jina moja la mwenyeji, sio nafasi nzima ya majina. Vitambulisho sanifu vinahitaji changamoto ya DNS-01: Certbot huweka rekodi ya TXT kwenye _acme-challenge.example.com, ambayo kwa kawaida inamaanisha programu-jalizi ya certbot-dns-* yenye vitambulisho vya API kwa mtoa huduma wako wa DNS, au kuhariri kwa mkono rekodi za TXT kila wakati wa upyaishaji kwa kutumia --manual (ni shida kubwa — usipangie kazi zako kulingana na njia hii). Mwongozo kamili, kuanzia mbinu za rekodi ya TXT hadi programu-jalizi inayofanya upyaishaji bila ufuatiliaji, upo kwenye vitambulisho sanifu na Certbot kupitia DNS-01. Ushauri wa moja kwa moja: kama una majina nne yanayojulikana ya subdomeni, cheti cha SAN kinayoorodhesha yote minni ni rahisi kuliko kitambulisho sanifu na hakihitaji funguo za API za DNS kubaki kwenye seva.

Aina za hitilafu, pamoja na mistari utakayoiona

Certbot anakataa kuanza kwa sababu usanidi wa Apache umevurugika.

The apache plugin is not working; there may be problems with your existing configuration.
The error was: MisconfigurationError('Error while running apache2ctl configtest.\n\nAction \'configtest\' failed.\nThe Apache error log may have more information.\n\nAH00526: Syntax error on line 12 of /etc/apache2/sites-enabled/example.com.conf')

Programu-jalizi inatekeleza configtest kabla ya kugusa chochote na huacha kufanya kazi ikiwa Apache yenyewe haiko sawa — \n ni za moja kwa moja kwa sababu Certbot huchapisha repr ya exception. Tekeleza sudo apache2ctl configtest mwenyewe: itataja faili na mstari — kwa kawaida ni makosa ya kuandika kwa mkono, SSLCertificateFile inayotaja njia ambayo haipo tena, au moduli iliyotajwa lakini haijawashwa. Rekebisha hadi ichapishe Syntax OK, kisha tekeleza tena Certbot.

Hakuna vhost inayolingana na kikoa.

Unable to find a virtual host listening on port 80 which is currently the only challenge port.

Hii ni hitilafu ya kukosa ServerName kutoka hapo awali, iliyogundulika wakati wa kutolewa. Certbot ilitafuta kila vhost ya bandari 80 iliyowashwa kwa ServerName/ServerAlias inayolingana na -d yako na haikupata chochote. sudo apache2ctl -S inaonyesha Apache inapeleza wapi kwa kweli; ongeza mstari wa ServerName kwenye vhost sahihi, pakia upya, jaribu tena. Hitilafu inayofanana nayo ni uthibitishaji unaoifikia vhost sahihi — jibu la changamoto linarudi Invalid response ... 404 kwa sababu tovuti nyingine ilikamata ombi. Utambuzi ule ule, zana ile ile: apache2ctl -S.

Uthibitishaji unakwisha muda.

Certbot failed to authenticate some domains (authenticator: apache).
...
Detail: ...: Timeout during connect (likely firewall problem)

Let's Encrypt haikuweza kufungua muunganisho wa TCP kwenye bandari 80 kwenye anwani ambayo DNS yako inatangaza. Kwa mpangilio wa uwezekano: firewall ya mtandao wa mtoa huduma wako (tofauti na ufw, inasanidiwa kwenye paneli ya hosting), seti ya kanuni za ufu inayoruhusu 443 tu au SSH tu, DNS bado inataja seva iliyotangulia, au tatizo la AAAA la zamani — seva zao zilijaribu IPv6, yako inajibu kwenye IPv4 tu. Jaribu kutoka nje ya VPS: curl -I http://example.com kutoka kwenye kompyuta yako ya mkononi huiga kile ambacho kithibitishaji chao chaona.

Umejaribu mara nyingi hadi kufikia kikomo cha kiwango.

Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/

Let's Encrypt inaruhusu uthibitishaji ulioshindwa 5 kwa kila jina la mwenyeji kwa kila akaunti kwa kila saa — tangu upyaaji wa kikomo cha kiwango cha mwaka 2025, hii ni ndoo inayojazwa tena, ukipata jaribio moja takriban kila dakika 12 — na kujaribu mara kwa mara dhidi ya firewall iliyovurugika huiondoa haraka. Kusubiri hufanya kazi, lakini suluhisho halisi ni la kitabia: baada ya kila hitilafu, rekebisha kwa kutumia mazingira ya staging hadi ifanikiwe.

sudo certbot certonly --apache --dry-run -d example.com -d www.example.com

Zingatia certonly: --dry-run inakubaliwa tu na subcommands za certonly na renew, na fomu ya certbot --apache --dry-run pekee inakataa kufanya kazi kabisa, ikiwaambia --dry-run currently only works with the 'certonly' or 'renew' subcommands. Dry run huthibitisha dhidi ya staging, ambayo ina vikomo vyake nafasi na haitoi vyeti halisi, hivyo unaweza kushindwa huko mchana nzima. Tekeleza tena amri halisi tu baada ya staging kupita. Vikomo vingine — vyeti 50 kwa kila kikoa kilichosajiliwa kwa kila wiki, nakala 5 za seti ile ile ya majina kwa kila wiki — utakutana navyo tu ikiwa script inatoa tena kwenye mzunguko.

Mara HTTPS inapokuwa imewashwa, kumbuka cheti kinahakikisha usalama wa usafirishaji, sio seva: bandari 22 bado inapokea majaribio ya nywila siku nzima. Kuiunganisha hii na Fail2ban kwenye Ubuntu 24.04 ndio dakika thelathini zinazofuata kwa kawaida.

FAQ

Nitumie snap au apt kusakinisha Certbot kwa Apache kwenye Ubuntu 24.04?

Tumia apt. Ubuntu 24.04 inakuja na Certbot 2.9.0, ambayo ni ya kutosha kwa kila kitu katika mwongozo huu, hupata masasisho ya usalama kupitia unattended-upgrades, na haihitaji snapd. Chagua snap tu ikiwa unahitaji toleo jipya zaidi mara moja au plugin ya DNS inayotolewa pekee kama snap — na ukibadilisha, apt remove certbot python3-certbot-apache kwanza ili mipangilio miwili ya upya isifanye kazi kwa wakati mmoja.

Kwanini Certbot inasema "Unable to find a virtual host listening on port 80"?

Kwa sababu hakuna vhost iliyowashwa kwenye port 80 inayo na ServerName au ServerAlias inayolingana na kikoa ulichopitisha pamoja na -d — vhost chaguomsingi ya Ubuntu inakuja na ServerName imefutwa kwa maoni. Endesha sudo apache2ctl -S, tafuta (au uunde) vhost inayopaswa kumiliki jina hilo, ongeza ServerName example.com, pakia upya Apache, kisha endesha Certbot tena.

Nitatatua vipi "Timeout during connect (likely firewall problem)"?

Let's Encrypt haikuweza kufikia port 80 kwenye anwani inayotangazwa na DNS yako. Angalia firewall ya mtandao ya panel ya mtoa huduma wako pamoja na ufw, thibitisha dig +short example.com inarudisha VPS hii, na futa au sahihisha kumbukumbu yoyote ya zamani ya AAAA — uthibitishaji unapendelea IPv6 ikiwa ipo. Thibitisha marekebisho kutoka nje ya seva kwa curl -I http://example.com, kisha fanya mazoezi na sudo certbot certonly --apache --dry-run -d example.com kabla ya kutolewa halisi.

Je, Certbot inasasisha vyeti moja kwa moja kwenye Ubuntu 24.04?

Ndiyo. Kifurushi cha apt kinasakinisha certbot.timer, timer ya systemd inayoendeshwa mara mbili kwa siku na inasasisha kila cheti ndani ya siku 30 kabla ya kumalizika muda, na kisha inapakia upya Apache; snap inatumia snap.certbot.renew.timer kwa kazi hiyo hiyo. Thibitisha kwa systemctl list-timers certbot.timer na fanya mazoezi na sudo certbot renew --dry-run — usiongeze kazi yako ya cron juu ya hilo.

Nipate vipi cheti cha wildcard kwa Certbot na Apache?

Cheti cha wildcard kinahitaji changamoto ya DNS-01: Certbot lazima iweke kumbukumbu ya TXT kwenye _acme-challenge.example.com, ambayo inamaanisha plugin ya certbot-dns-* yenye vitambulisho vya API vya mtoa huduma wako wa DNS (mbadala wa --manual unahitaji kumbukumbu za TXT zilizohaririwa kwa mkono kila wakati wa kusasisha). Ikiwa una vikoa vidogo vya subdomain vinavyojulikana tu, cheti cha SAN kinakiorodhesha wazi ni rahisi zaidi na kinaacha funguo za API ya DNS nje ya seva.