Sakinisha Certbot kwa Apache kwenye Ubuntu 24.04

Unachojenga

Tovuti ya Apache kwenye Ubuntu 24.04 inayojibu kupitia HTTPS kwa certificate ya bure ya Let's Encrypt inayoaminiwa na browser, inayotolewa na Certbot na kusasishwa kiotomatiki na systemd timer ambayo hutahitaji kuifikiria tena. Command inayofanya kazi hiyo iko kwenye mstari mmoja. Kila kinachoweza kwenda vibaya hutokea kabla ya mstari huo: vhost isiyo na ServerName, port 80 iliyofungwa kwenye firewall ya mtoa huduma, au DNS ambayo bado inaelekeza kwenye seva ya zamani. Kwa hiyo, mwongozo huu unatumia muda mwingi kueleza masharti ya awali na unaonyesha error string kamili inayochapishwa na kila kosa.

Maelezo mawili kuhusu upeo. Ikiwa web server yako ni nginx, mtiririko una muundo uleule lakini plugin na configs hutofautiana; tumia toleo la mwongozo huu la nginx badala yake. Ikiwa unacholinda kinapatikana ndani tu, kama admin panel kwenye anwani ya faragha au staging box ambayo hakuna mtu mwingine anayetembelea, huhitaji certificate authority hata kidogo; certificate iliyosainiwa yenyewe inahitaji vipengele vichache na hufanya kazi offline.

Mahitaji ya awali, na njia tatu ambazo mchakato huu hushindwa kabla Certbot haijaanza

• Apache tayari inahudumia tovuti yako kupitia HTTP isiyo na TLS. Plugin ya Apache ya Certbot hubadili tovuti iliyopo; haiundi tovuti. Ikiwa unaanza na VPS tupu, kwanza tengeneza LAMP stack kwenye Ubuntu 24.04, kisha urudi hapa; mwongozo huu ni sura ya TLS inayokosekana.
• Domain ya umma yenye A record inayoelekeza kwenye anwani ya VPS yako. Changamoto ya HTTP-01 ya Let's Encrypt inamaanisha seva zao za uthibitishaji huunganisha kwenye seva yako kupitia Internet: homelab iliyo nyuma ya NAT haiwezi kufanya kazi bila port forwarding, hakuna majina ya .local, na hakuna IP tupu. dig +short example.com lazima irudishe anwani ya VPS yako. Ikiwa ulibadili DNS ndani ya saa iliyopita, subiri TTL ya record ya zamani imalizike kabla ya kuomba certificate.
• Ikiwa AAAA record ipo, lazima iwe sahihi. Let's Encrypt hupendelea IPv6 wakati AAAA record imechapishwa. Kwa hiyo, AAAA iliyopitwa na wakati husababisha uthibitishaji kushindwa hata kama curl kutoka kwenye laptop yako, ambayo huenda inatumia IPv4, inafanya kazi vizuri. Chapisha AAAA sahihi au usichapishe kabisa.

Port 80 na 443 lazima ziwe wazi katika ufw na kwenye firewall ya mtandao ya mtoa huduma wako. Paneli nyingi za hosting huwa na firewall ya pili ambayo mfumo wa uendeshaji hauioni. HTTP-01 huthibitishwa kupitia port 80 mahususi; huwezi kuendesha mchakato huu kwa 443 pekee.

sudo ufw allow "Apache Full"
sudo ufw status

Masharti hayo yakitimia, kazi yote huchukua dakika kumi na tano, na dakika kumi kati ya hizo hutumika kusoma.

Certbot ya Snap au apt? Kwenye 24.04, apt sasa inafaa

Certbot ilihamia kwenye usambazaji wa snap miaka iliyopita kwa sababu nzuri: vifurushi vya distro vilipitwa na wakati. Ubuntu 20.04 ilisafirisha Certbot 0.40 na haikubadilisha toleo hilo, huku mradi ukichoka kurekebisha hitilafu za miaka mitano. Kwenye 24.04, sababu hiyo haipo tena. Archive inasafirisha Certbot 2.9.0, toleo la kizazi cha sasa, na unattended-upgrades huiweka ikiwa na marekebisho ya hivi karibuni. Mapendekezo yangu kwa OS hii ni kutumia apt. Huhitaji daemon ya snapd, plugin ya Apache husakinishwa katika transaction hiyo hiyo, na timer ya renewal huunganishwa na systemd kwa njia ya kawaida ya Debian.

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

Matokeo sahihi ni: certbot 2.9.0. Kifurushi cha python3-certbot-apache ni plugin inayosoma na kuhariri usanidi wako wa Apache. Bila kifurushi hicho, certbot --apache hushindwa kwa The requested apache plugin does not appear to be installed.

Snap bado ndiyo chaguo sahihi katika hali mbili: unataka Certbot mpya zaidi siku inapotolewa, au unahitaji plugin ya DNS inayosambazwa kama snap pekee. Plugins kadhaa za watoa huduma wa certbot-dns-* ziko katika hali hiyo. 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

Chaguo lolote utakalochagua, usiwahi kuendesha zote mbili. Usakinishaji mbili humaanisha schedulers mbili za renewal zinazogombania /etc/letsencrypt, na certbot ambayo shell yako hupata katika PATH huenda isiwe ile inayomiliki certificates zako. Mstari wa apt remove hapo juu si mapambo ya hiari.

Vhost ambayo Certbot inahariri lazima iwepo tayari; ServerName ndiyo msingi wa kila kitu

certbot --apache hufanya kazi kwa kutafuta virtual host ya port 80 ambayo ServerName au ServerAlias inalingana na kila domain ya -d unayotoa. Kisha inathibitisha udhibiti wa domain kupitia virtual host hiyo na kuandika nakala ya SSL ya vhost hiyo. Ikiwa hakuna ServerName inayolingana, hakuna ulinganifu. Pia, 000-default.conf ya kawaida ya Ubuntu hutolewa ikiwa ServerName imewekewa maoni. Mstari huo mmoja wenye maoni ndiyo sababu inayotokea mara nyingi zaidi ya amri moja kubwa katika mwongozo huu kushindwa.

Kwa hiyo, kabla ya kutumia Certbot, weka vhost sahihi inayotumia jina la site. 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>

Iwashe na uthibitishe kwamba Apache inaisoma bila makosa na inaelekeza jina kwenye vhost hiyo:

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

configtest lazima ichapishe Syntax OK. Ikiwa pia itachapisha AH00558: apache2: Could not reliably determine the server's fully qualified domain name, huo ni mwondoko kuhusu ServerName ya global, si vhost yako. Haina madhara hapa, na unaweza kuuficha kwa echo "ServerName $(hostname -f)" | sudo tee /etc/apache2/conf-available/servername.conf && sudo a2enconf servername && sudo systemctl reload apache2.

Output ya -S ndiyo ukaguzi muhimu. Unataka mstari kama port 80 namevhost example.com (/etc/apache2/sites-enabled/example.com.conf:1) ukiwa na alias www.example.com chini yake. Apache huripoti symlink ya sites-enabled ambayo ilisoma kwa kweli, si faili uliyohariri katika sites-available. Ikiwa example.com haijaorodheshwa dhidi ya port 80, Certbot pia haitaipata.

Toa cheti: certbot --apache

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

Mara ya kwanza utaombwa vitu vitatu: anwani ya barua pepe (inayotumika kwa akaunti yako ya ACME na arifa za dharura kutoka CA; Let's Encrypt haitumi tena maonyo ya kuisha kwa cheti, kwa hiyo ni jukumu lako kufuatilia renewal), kukubali masharti ya Let's Encrypt, na kuchagua ikiwa utashiriki barua pepe yako na EFF. Hakuna tena swali la redirect: tangu Certbot 2.0, kisakinishi cha Apache huelekeza HTTP kwenda HTTPS kwa chaguo-msingi, na hilo ndilo unalotaka. Tumia --no-redirect ikiwa kwa kweli unahitaji HTTP isiyosimbwa iendelee kutoa maudhui.

Matokeo ya mafanikio yanafanana na haya, na unapaswa kuyasoma badala ya kuyapitia 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 module ya Apache ya ssl ikiwa haikuwa imewezeshwa, ikaandika example.com-le-ssl.conf, yaani nakala ya vhost yako kwenye *:443 yenye SSLEngine on na njia za cheti, ikawezesha vhost hiyo, na ikaongeza block ya RewriteRule kwenye vhost ya awali ya port-80 inayoweka redirect ya 301 kwa kila kitu kwenda HTTPS. Faili yako ya awali ya vhost imehaririwa, si kubadilishwa, na nakala ya SSL iko kando yake ili uweze kusoma kila mstari uliouongeza.

Cheti kinapatikana wapi hasa, na kwa nini hupaswi kamwe kukinakili

Kila kitu huwekwa chini ya /etc/letsencrypt/live/example.com/: fullchain.pem (cheti pamoja na mnyororo wa vyeti vya kati, ambako seva zinapaswa kuelekezwa), privkey.pem (ufunguo wa faragha, unaoweza kusomwa na root pekee), pamoja na cert.pem na chain.pem kwa programu zinazohitaji vipande hivyo kando. Hivi ni viungo vya ishara vinavyoelekea kwenye /etc/letsencrypt/archive/, na uelekezaji huo ndio utaratibu wa renewal: renewal huandika faili mpya kwenye archive/ na kubadilisha viungo hivyo vielekee kwenye faili mpya. Elekeza programu nyingine yoyote kwenye njia za live/, nayo itapokea renewals moja kwa moja; ukinakili faili hizo mahali pengine, utakuwa umejiandalia outage baada ya siku 90.

Faili nyingine muhimu ni /etc/letsencrypt/renewal/example.com.conf, inayorekodi jinsi cheti hiki kilivyotolewa, authenticator = apache, installer = apache, pamoja na domains, ili renewal iweze kurudia mchakato bila uangalizi, ikiwemo kupakia upya Apache baadaye.

Renewal tayari imepangwa, ithibitishe badala ya kuiunda

Certificates za Let's Encrypt hudumu siku 90 kwa usanidi wa kawaida, na package ya apt tayari iliweka mfumo unaohitajika: systemd timer inayoendesha Certbot mara mbili kwa siku kwa nyakati za nasibu, na kufanya renewal ya certificate yoyote iliyobaki ndani ya siku 30 kabla ya ku-expire. Usiongeze cron job juu yake; scheduler ya pili haitaongeza chochote isipokuwa kelele kwenye log na uwezekano wa kufikia rate limit.

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

Command ya kwanza huonyesha timer ikiwa active, ikiwa na muda wa NEXT ndani ya saa 24 zijazo. Ratiba ni mara mbili kwa siku na ina delay ya nasibu, hivyo muda halisi haujatabirika kwa makusudi (kwenye usakinishaji wa snap, timer ni snap.certbot.renew.timer badala yake). Dry run hufanya mazoezi kamili ya renewal dhidi ya staging environment ya Let's Encrypt, kwa kutumia challenge halisi bila kutoa certificate wala kutumia kiwango cha rate limit. Matokeo sahihi huishia na:

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

Dry run ikishindwa, renewal halisi baada ya takriban siku 60 itashindwa kwa njia hiyo hiyo. Rekebisha tatizo sasa, wakati certificate ya sasa bado ina muda wake wote wa uhalali mbele yake. Kisababishi cha kawaida ni firewall rule iliyoongezwa baada ya certificate kutolewa na kufunga tena port 80.

Thibitisha kwa curl, na ujue kufuli inapaswa kuonyesha nini

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

Ya kwanza inapaswa kurudisha HTTP/1.1 301 Moved Permanently yenye kichwa cha Location: https://example.com/. Huo ndio uelekezaji wa ombi uliowekwa na Certbot. Ya pili inapaswa kurudisha HTTP/1.1 200 OK bila curl kutoa malalamiko kuhusu TLS. Ya tatu huchapisha mtoaji, mstari wa O = Let's Encrypt wenye CN fupi kama R12 au E7, na notAfter iliyo karibu siku 90 zijazo. Kwenye kivinjari utaona kufuli. Ukibofya kufuli hilo, utaona mtoaji huyo huyo. Ikiwa curl inafanya kazi lakini kivinjari kinaonyesha onyo, karibu hakika unaona ukurasa uliohifadhiwa kwenye cache au unatumia hostname isiyo sahihi, si tatizo la cheti.

Tovuti nyingi: certificate moja ya SAN au certificate moja kwa kila tovuti

Zote zinafanya kazi; zinafanyiwa renewal kwa njia ileile. Kwa tovuti zisizohusiana zilizo kwenye box moja, endesha command ya issue mara moja kwa kila tovuti. Kila tovuti itapata directory yake chini ya live/ pamoja na renewal config yake. Tatizo kwenye domain moja halitazuia renewal ya domain nyingine. Huo ndio mpangilio wangu wa kawaida.

Kwa tovuti moja yenye majina kadhaa, yaweke kwenye certificate moja ya SAN. Certificate moja inaweza kubeba hadi majina 100. Tayari ulifanya hivi hapo juu ukitumia example.com na www.example.com. Ili kuongeza jina kwenye certificate iliyopo baadaye, iissue tena kwa kutaja jina la certificate na orodha kamili ya majina mapya:

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

Certbot hutambua kuwa seti ya domains imebadilika, hukuomba uthibitishe upanuzi, kisha hubadilisha certificate hiyo mahali pake, kwenye path ileile ya live/. Kwa hiyo, hakuna kitu kingine kinachohitaji kubadilishwa. Kumbuka kuwa orodha hiyo inachukua nafasi ya orodha ya awali; haiongezi majina mwishoni. Ukiacha www kwenye command hiyo, certificate mpya itaiondoa bila kutoa ujumbe wa wazi.

Wildcard zinahitaji DNS-01, na kwa kawaida huhitaji wildcard

HTTP-01 haiwezi kutoa *.example.com, kwa sababu kuweka faili kwenye seva ya wavuti kunathibitisha udhibiti wa hostname moja tu, si namespace nzima. Wildcard zinahitaji challenge ya DNS-01: Certbot huweka TXT record kwenye _acme-challenge.example.com. Kwa vitendo, hii inamaanisha kutumia plugin ya certbot-dns-* yenye API credentials za mtoa huduma wako wa DNS, au kuhariri TXT records mwenyewe wakati wa kila renewal kwa kutumia --manual. Njia hiyo ni yenye usumbufu, kwa hiyo usiipangie. Mwongozo kamili, kuanzia jinsi TXT record inavyofanya kazi hadi plugin inayofanya renewal bila uangalizi, unapatikana kwenye certificates za wildcard kwa Certbot kupitia DNS-01. Ushauri wa moja kwa moja: ikiwa una subdomain nne zinazojulikana, certificate ya SAN inayoorodhesha zote nne ni rahisi kuliko wildcard na haihitaji DNS API keys zihifadhiwe kwenye seva.

Failure modes, with the strings you will see

Certbot refuses to start because Apache's config is broken.

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')

Plugin huendesha configtest kabla ya kugusa chochote na huacha kufanya kazi ikiwa Apache yenyewe ina hitilafu. \ns ni za moja kwa moja kwa sababu Certbot huchapisha repr ya exception. Endesha sudo apache2ctl configtest wewe mwenyewe. Inaonyesha faili na mstari wenye tatizo. Mara nyingi tatizo ni typo iliyotokana na kuhariri kwa mkono, SSLCertificateFile inayoelekeza kwenye path ambayo haipo tena, au module iliyotajwa lakini haijawezeshwa. Rekebisha hadi ichapishe Syntax OK, kisha endesha Certbot tena.

Hakuna vhost inayolingana na domain.

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

Hii ni hitilafu ya missing-ServerName iliyotajwa awali, inayotokea wakati wa issue. Certbot ilitafuta vhost zote za port 80 zilizowezeshwa kwa ServerName/ServerAlias inayolingana na -d yako, lakini haikupata yoyote. sudo apache2ctl -S inaonyesha Apache inapeleka maombi wapi kwa sasa. Ongeza mstari wa ServerName kwenye vhost sahihi, reload, kisha ujaribu tena. Tatizo linalofanana ni validation kufikia vhost isiyo sahihi. Jibu la challenge hurudi Invalid response ... 404 kwa sababu site nyingine ilipokea ombi hilo. Utambuzi na zana ni zilezile: apache2ctl -S.

Validation inaisha muda bila mafanikio.

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

Let's Encrypt haikuweza kufungua muunganisho wa TCP kwenye port 80 ya anwani inayotangazwa na DNS yako. Kwa kuanza na sababu zinazowezekana zaidi: firewall ya mtandao ya provider wako, iliyo tofauti na ufw na kusanidiwa kwenye paneli ya hosting; ruleset ya ufw inayoruhusu 443 pekee au SSH pekee; DNS ambayo bado inaelekeza kwenye seva ya awali; au tatizo la stale-AAAA. Katika hali hiyo, seva zao zilijaribu IPv6, lakini seva yako inajibu IPv4 pekee. Fanya jaribio kutoka nje ya VPS: curl -I http://example.com kutoka kwenye laptop yako huiga kile validator wao huona.

Umefanya majaribio mengi hadi kufikia kikomo cha maombi.

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

Let's Encrypt inaruhusu validation 5 zilizofeli kwa hostname moja, kwa account moja, ndani ya saa moja. Tangu marekebisho ya rate limit ya 2025, kikomo hicho ni bucket inayojazwa tena. Kwa kawaida unapata retry moja tena baada ya takriban dakika 12. Kurudia majaribio kwa nguvu dhidi ya firewall iliyoharibika hukimaliza haraka. Kusubiri husaidia, lakini suluhisho halisi ni kubadili utaratibu: baada ya failure yoyote, debug kwa kutumia staging environment hadi ifanikiwe.

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

Zingatia certonly: --dry-run inakubaliwa na subcommands za certonly na renew pekee. Muundo wa kawaida wa certbot --apache --dry-run hukataa kuendesha kabisa na kukuambia --dry-run currently only works with the 'certonly' or 'renew' subcommands. Dry run hufanya validation dhidi ya staging. Staging ina limits zake kubwa na haitoi certificates halisi, hivyo unaweza kufeli huko mara nyingi bila kuathiri certificates za uzalishaji. Endesha command halisi tena baada ya staging kufanikiwa. Limits nyingine ni certificates 50 kwa registered domain kwa wiki, na duplicates 5 za seti ileile ya majina kwa wiki. Utakutana nazo tu ikiwa script ina-reissue certificate kwa mfululizo.

Baada ya HTTPS kufanya kazi, kumbuka kuwa certificate inalinda transport, si seva yenyewe. Port 22 bado inapokea majaribio ya password siku nzima. Kuunganisha hatua hii na Fail2ban kwenye Ubuntu 24.04 ni hatua inayofuata ya kawaida kwa dakika 30 zijazo.

FAQ

Je, niweke Certbot kwa snap au apt kwa Apache kwenye Ubuntu 24.04?

Tumia apt. Ubuntu 24.04 inasambaza Certbot 2.9.0, ambayo ni ya sasa vya kutosha kwa kila kitu katika mwongozo huu, hupokea viraka vya usalama kupitia unattended-upgrades, na haihitaji snapd. Chagua snap ikiwa tu unahitaji release mpya zaidi mara moja au plugin ya DNS inayosambazwa kama snap pekee. Ukibadilisha, apt remove certbot python3-certbot-apache kwanza ili schedulers mbili za renewal zisitumike kwa wakati mmoja.

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

Kwa sababu hakuna vhost ya port 80 iliyowezeshwa iliyo na ServerName au ServerAlias inayolingana na domain uliyopitisha kwa -d. Ubuntu husambaza vhost ya default ikiwa na ServerName ikiwa imewekwa maoni. Tekeleza sudo apache2ctl -S, tafuta au unda vhost inayopaswa kumiliki jina hilo, ongeza ServerName example.com, reload Apache, kisha endesha Certbot tena.

Nitasahihishaje "Timeout during connect (likely firewall problem)"?

Let's Encrypt haikuweza kufikia port 80 kwenye anwani inayotangazwa na DNS yako. Kagua firewall ya mtandao iliyo kwenye panel ya provider wako pamoja na ufw. Thibitisha kuwa dig +short example.com inarejesha VPS hii, na ufute au sahihisha rekodi yoyote ya zamani ya AAAA. Uthibitishaji hupendelea IPv6 ikiwa rekodi kama hiyo ipo. Thibitisha marekebisho hayo ukiwa nje ya seva kwa curl -I http://example.com, kisha fanya jaribio la awali kwa sudo certbot certonly --apache --dry-run -d example.com kabla ya kuomba certificate halisi.

Je, Certbot husasisha certificates kiotomatiki kwenye Ubuntu 24.04?

Ndiyo. Kifurushi cha apt husakinisha certbot.timer, timer ya systemd inayoendesha mara 2 kwa siku na kusasisha certificate yoyote iliyobakiwa na siku 30 au chache kabla ya kuisha. Baada ya hapo hu-reload Apache. snap hutumia snap.certbot.renew.timer kwa kazi hiyo hiyo. Thibitisha kwa systemctl list-timers certbot.timer na ufanye jaribio la awali kwa sudo certbot renew --dry-run. Usiweke cron job yako juu ya utaratibu huo.

Nitapataje certificate ya wildcard kwa Certbot na Apache?

Wildcard zinahitaji challenge ya DNS-01. Certbot lazima iweke rekodi ya TXT kwenye _acme-challenge.example.com. Hii inahitaji plugin ya certbot-dns-* yenye API credentials za DNS provider wako. Chaguo la --manual linahitaji uhariri wa mikono wa rekodi za TXT katika kila renewal. Ikiwa una subdomain chache zinazojulikana, certificate ya SAN inayoziorodhesha wazi ni rahisi zaidi na huweka DNS API keys nje ya seva.