Install Certbot sa Apache Ubuntu 24.04

Ang binubuo mo

Isang Apache site sa Ubuntu 24.04 na tumutugon sa HTTPS gamit ang libre at pinagkakatiwalaan ng browser na Let's Encrypt certificate. I-i-issue ito ng Certbot at awtomatikong ire-renew ng systemd timer na hindi mo na kailangang isipin. Isang linya lang ang command na gumagawa nito. Lahat ng nagkakaproblema ay nagkakaproblema bago ang linyang iyon: vhost na walang ServerName, port 80 na sarado sa provider firewall, o DNS na nakaturo pa rin sa lumang server. Kaya nakatuon ang malaking bahagi ng guide na ito sa mga precondition at tinutukoy nito ang eksaktong error string na inilalabas ng bawat pagkakamali.

Dalawang paalala tungkol sa saklaw. Kung nginx ang web server mo, pareho ang pangkalahatang daloy pero magkaiba ang plugin at mga config; gamitin ang bersyon ng guide na ito para sa nginx. Kung internal-only naman ang sine-secure mo—gaya ng admin panel sa private address o staging box na walang ibang bumibisita—hindi mo kailangan ng certificate authority; mas kaunti ang kailangang i-configure sa self-signed certificate, at gumagana ito offline.

Mga Prerequisite, at ang tatlong paraan kung paano ito nabibigo bago pa tumakbo ang Certbot

• Kasalukuyang nagsisilbi ang Apache ng site mo gamit ang plain HTTP. Ine-edit ng Apache plugin ng Certbot ang kasalukuyang site; hindi ito gumagawa ng bago. Kung nagsisimula ka sa isang bare VPS, i-set up muna ang LAMP stack sa Ubuntu 24.04, pagkatapos ay bumalik dito. Ito ang nawawalang TLS chapter ng gabay na iyon.
• May public domain na may A record na tumuturo sa address ng VPS mo. Ibig sabihin ng HTTP-01 challenge ng Let's Encrypt, kokonekta sa server mo mula sa internet ang kanilang validation servers: hindi puwede ang homelab na nasa likod ng NAT nang walang port forwarding, walang .local names, at walang bare IP. Dapat ibalik ng dig +short example.com ang address ng VPS mo. Kung binago mo ang DNS sa nakaraang oras, hintayin munang lumipas ang TTL ng lumang record bago mag-issue.
• Kung may AAAA record, dapat tama ito. Mas pinipili ng Let's Encrypt ang IPv6 kapag may naka-publish na AAAA record. Kaya mabibigo ang validation dahil sa lumang AAAA kahit gumagana nang maayos ang curl mula sa laptop mo, na malamang ay IPv4 ang gamit. Mag-publish ng tamang AAAA o huwag mag-publish ng AAAA.

Dapat bukas ang port 80 at 443 sa ufw at sa network firewall ng provider mo. Karamihan sa hosting panel ay may hiwalay na firewall na hindi nakikita ng OS. Partikular na gumagamit ng port 80 ang HTTP-01 validation; hindi ito puwedeng patakbuhin na 443 lamang.

sudo ufw allow "Apache Full"
sudo ufw status

Kapag handa na ang mga ito, labinlimang minuto lang ang buong proseso, at sampu roon ay para sa pagbabasa.

Snap o apt Certbot? Sa 24.04, maayos na rin sa wakas ang apt

Lumipat ang Certbot sa snap distribution ilang taon na ang nakalipas dahil may mabuting dahilan: nag-fossilize ang mga package ng distro. Nag-ship ang Ubuntu 20.04 ng Certbot 0.40 at hindi na ito na-update, kaya nagsawa ang project sa pag-debug ng mga bug na limang taon na. Sa 24.04, wala na ang problemang iyon. Nag-ship ang archive ng Certbot 2.9.0, isang kasalukuyang-generation release, at pinananatili itong patched ng unattended-upgrades. Para sa OS na ito, ang rekomendasyon ko ay apt. Hindi mo na kailangang gamitin ang snapd daemon, nai-install ang Apache plugin sa parehong transaction, at sumasama ang renewal timer sa systemd sa karaniwang paraan ng Debian.

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

Tamang resulta: certbot 2.9.0. Ang package na python3-certbot-apache ang plugin na bumabasa at nag-e-edit ng iyong Apache configs. Kung wala ito, mabibigo ang certbot --apache dahil sa The requested apache plugin does not appear to be installed.

Ang snap pa rin ang tamang piliin sa dalawang sitwasyon: gusto mo ang pinakabagong Certbot sa araw na ilabas ito, o kailangan mo ng DNS plugin na snap lamang ang distribution (snap ang distribution ng ilan sa mga provider plugin ng certbot-dns-*). Kung iyon ang pipiliin mo:

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

Anuman ang piliin mo, huwag kailanman patakbuhin ang dalawa. Kapag dalawang installation ang mayroon, mag-aagawan ang dalawang renewal scheduler sa /etc/letsencrypt, at maaaring hindi ang certbot na hinahanap ng iyong shell sa PATH ang nagmamay-ari ng iyong certificates. Hindi opsyonal na dekorasyon ang linyang apt remove sa itaas.

Dapat mayroon na ang vhost na ine-edit ng Certbot; ang ServerName ang pinakamahalaga

certbot --apache gumagana sa pamamagitan ng paghahanap sa virtual host ng port 80 na ang ServerName o ServerAlias ay tumutugma sa bawat -d domain na ipinasa mo. Pinatutunayan nito ang kontrol sa domain sa pamamagitan nito, pagkatapos ay nagsusulat ng SSL twin ng vhost na iyon. Kapag walang tumutugmang ServerName, walang match. Kasama rin sa Ubuntu's default 000-default.conf ang ServerName na naka-comment. Ang iisang naka-comment na linyang ito ang pinakakaraniwang dahilan kung bakit nagfa-fail ang isang malaking command sa guide na ito.

Kaya bago gamitin ang Certbot, bigyan muna ang site ng maayos na name-based vhost. Gawin ang /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>

I-enable ito at tiyaking parehong nababasa ito ng Apache at nairuruta nito rito ang pangalan:

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

Dapat mag-print ang configtest ng Syntax OK. Kung magpi-print din ito ng AH00558: apache2: Could not reliably determine the server's fully qualified domain name, babala iyon tungkol sa global ServerName, hindi sa vhost mo. Hindi ito nakapipinsala rito, at maaaring patahimikin gamit ang echo "ServerName $(hostname -f)" | sudo tee /etc/apache2/conf-available/servername.conf && sudo a2enconf servername && sudo systemctl reload apache2.

Ang output ng -S ang mahalagang check. Dapat may linya kang tulad ng port 80 namevhost example.com (/etc/apache2/sites-enabled/example.com.conf:1) na may alias www.example.com sa ilalim nito. Iniuulat ng Apache ang sites-enabled symlink na aktuwal nitong binasa, hindi ang file na ine-edit mo sa sites-available. Kung hindi nakalista ang example.com laban sa port 80, hindi rin ito mahahanap ng Certbot.

I-issue ang certificate: certbot --apache

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

Sa unang pag-run, tatlong bagay ang hihingin: isang email address (gagamitin para sa iyong ACME account at mahahalagang notice mula sa CA; hindi na nagpapadala ang Let's Encrypt ng mga warning tungkol sa expiration, kaya ikaw ang kailangang mag-monitor ng renewals), pagsang-ayon sa terms ng Let's Encrypt, at kung ibabahagi mo ang iyong email sa EFF. Wala na ang tanong tungkol sa redirect: mula sa Certbot 2.0, awtomatikong nagre-redirect ang Apache installer mula HTTP papuntang HTTPS, na siyang kailangan mo. Gamitin ang --no-redirect kung talagang kailangang patuloy na mag-serve ng content ang plain HTTP.

Ganito ang itsura ng matagumpay na resulta, at dapat mo itong basahin sa halip na basta i-skim:

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

Sa likod ng mensaheng iyon, apat na bagay ang ginawa ng Certbot: in-enable nito ang Apache's ssl module kung hindi pa ito enabled, isinulat ang example.com-le-ssl.conf, isang kopya ng iyong vhost sa *:443 na may SSLEngine on at mga path ng certificate, in-enable ito, at nagdagdag ng RewriteRule block sa orihinal na port-80 vhost na nagre-redirect ng lahat papuntang HTTPS gamit ang 301. Na-edit ang orihinal mong vhost file at hindi ito pinalitan, habang nasa tabi nito ang SSL twin para mabasa mo ang bawat linyang idinagdag nito.

Kung saan talaga naka-store ang certificate, at kung bakit hindi mo ito dapat kopyahin

Nasa /etc/letsencrypt/live/example.com/ ang lahat: fullchain.pem (ang certificate kasama ang intermediate chain, na dapat gamiting path ng mga server), privkey.pem (ang private key, root lamang ang dapat makabasa), pati cert.pem at chain.pem para sa software na kailangang hiwalay ang mga file. Mga symlink ang mga ito papunta sa /etc/letsencrypt/archive/. Ang indirection na ito ang mekanismo ng renewal: nagsusulat ang renewal ng mga bagong file sa archive/ at nire-repoint ang mga symlink. Ituro ang ibang software sa mga path ng live/ para awtomatiko nitong magamit ang mga bagong certificate sa bawat renewal. Kapag kinopya mo ang mga file sa ibang lokasyon, ikaw mismo ang lumikha ng outage pagkalipas ng 90 days.

Ang isa pang file na dapat malaman ay /etc/letsencrypt/renewal/example.com.conf. Itinatala nito kung paano inisyu ang certificate, authenticator = apache, installer = apache, at ang mga domain. Dahil dito, maaaring ulitin ng renewal ang proseso nang walang manual na intervention, kabilang ang pag-reload sa Apache.

Naka-iskedyul na ang renewal; i-verify ito, huwag nang gumawa ng panibago

Ang mga Let's Encrypt certificate ay may bisa sa loob ng 90 days bilang default, at na-install na ng apt package ang kinakailangang mekanismo: isang systemd timer na nagpapatakbo ng Certbot dalawang beses bawat araw sa randomized na oras. Nire-renew nito ang anumang certificate na may natitira nang 30 days bago mag-expire. Huwag nang magdagdag ng cron job; walang maidudulot ang pangalawang scheduler kundi dagdag na log noise at exposure sa rate limit.

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

Ipinapakita ng unang command na active ang timer, at may NEXT time ito sa loob ng susunod na 24 hours. Dalawang beses bawat araw ang schedule at may randomized delay, kaya sadyang hindi predictable ang eksaktong oras. Sa snap install, snap.certbot.renew.timer naman ang timer. Isinasagawa ng dry run ang buong renewal rehearsal laban sa staging environment ng Let's Encrypt. Totoong challenge ito, pero walang iniisyu na certificate at walang nagagamit na rate limit. Nagtatapos ang matagumpay na resulta sa:

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

Kung mabigo ang dry run, mabibigo rin sa parehong paraan ang aktuwal na renewal pagkalipas ng humigit-kumulang 60 days. Ayusin ito ngayon, habang buong-buo pa ang natitirang validity ng kasalukuyang certificate. Karaniwang sanhi nito ang firewall rule na idinagdag matapos ang issuance at muling nagsara sa port 80.

I-verify gamit ang curl, at kung ano ang dapat ipakita ng padlock

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

Dapat magbalik ang una ng HTTP/1.1 301 Moved Permanently na may Location: https://example.com/ header. Iyan ang redirect na na-install ng Certbot. Dapat magbalik ang ikalawa ng HTTP/1.1 200 OK nang walang TLS complaint mula sa curl. Ipinapakita ng ikatlo ang issuer, isang O = Let's Encrypt line na may maikling CN gaya ng R12 o E7, at notAfter na humigit-kumulang 90 araw mula ngayon. Sa browser, lalabas ang padlock. Kapag pinindot mo ito, makikita ang parehong issuer. Kung gumagana ang curl pero may warning ang browser, malamang na cached page o maling hostname ang tinitingnan mo, hindi problema sa certificate.

Maraming site: isang SAN certificate o tig-isang certificate bawat site

Pareho itong gumagana; pareho rin ang paraan ng pag-renew ng mga ito. Para sa magkakaibang site sa iisang server, patakbuhin ang issue command nang isang beses para sa bawat site. Bawat isa ay magkakaroon ng sariling directory sa ilalim ng live/ at sariling renewal config. Kapag nagkaproblema ang isang domain, hindi nito mapipigilan ang pag-renew ng iba. Ito ang default kong ginagamit.

Para sa isang site na may maraming pangalan, ilagay ang mga ito sa isang SAN certificate. Maaaring maglaman ang isang certificate ng hanggang 100 pangalan. Nagawa mo na ito sa itaas gamit ang example.com at www.example.com. Para magdagdag ng pangalan sa isang existing certificate, mag-reissue na tinutukoy ang pangalan ng certificate at ang buong bagong listahan:

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

Mapapansin ng Certbot na nagbago ang domain set, hihingi ito ng kumpirmasyon para sa expansion, at papalitan nito ang certificate in place sa parehong live/ path. Kaya wala nang ibang kailangang baguhin. Tandaan na replacement ang listahan, hindi append: kapag inalis mo ang www sa command na iyon, tahimik itong aalisin ng bagong certificate.

Kailangan ng DNS-01 ang mga wildcard, at kadalasan ay hindi mo kailangan ng wildcard

Hindi makakapag-isyu ang HTTP-01 ng *.example.com. Ang paglalagay ng file sa isang web server ay nagpapatunay ng control sa isang hostname, hindi sa buong namespace. Kailangan ng mga wildcard ang DNS-01 challenge: nagse-set ang Certbot ng TXT record sa _acme-challenge.example.com. Sa praktika, nangangahulugan ito ng certbot-dns-* plugin na may API credentials para sa DNS provider mo, o manu-manong pag-edit ng mga TXT record sa bawat renewal gamit ang --manual. Napakahirap nito, kaya huwag itong gawing batayan ng iyong setup. Makikita sa mga wildcard certificate gamit ang Certbot sa DNS-01 ang kumpletong walkthrough, mula sa mechanics ng TXT record hanggang sa plugin na awtomatikong nagre-renew. Praktikal na payo: kung mayroon kang apat na kilalang subdomain, mas simple ang SAN certificate na naglilista sa lahat ng apat kaysa sa wildcard, at hindi nito kailangan ng DNS API keys na naka-store sa server.

Mga failure mode at ang mga string na makikita mo

Tumangging magsimula ang Certbot dahil sira ang configuration ng Apache.

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

Pinapatakbo ng plugin ang configtest bago gumawa ng anuman, at humihinto kung may problema mismo ang Apache. Literal ang \n dahil ipinapakita ng Certbot ang repr ng exception. Patakbuhin mismo ang sudo apache2ctl configtest. Ipinapakita nito ang file at line. Karaniwan itong typo mula sa manual na pag-edit, SSLCertificateFile na tumutukoy sa path na wala na, o module na tinukoy pero hindi naka-enable. Ayusin ito hanggang maipakita nito ang Syntax OK, saka patakbuhin muli ang Certbot.

Walang vhost na tumutugma sa domain.

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

Ito ang nawawalang-ServerName failure na nabanggit kanina, at nahuhuli ito kapag nag-i-issue. Hinanap ng Certbot ang bawat naka-enable na port-80 vhost para sa ServerName/ServerAlias na tumutugma sa iyong -d, pero wala itong nakita. Ipinapakita ng sudo apache2ctl -S kung saan talaga niruruta ng Apache ang request. Idagdag ang ServerName line sa tamang vhost, mag-reload, at subukan muli. May kahalintulad na kaso kung napupunta ang validation sa maling vhost. Nagbabalik ng Invalid response ... 404 ang challenge response dahil ibang site ang nakahuli sa request. Pareho ang diagnosis at tool: apache2ctl -S.

Nag-time out ang validation.

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

Hindi nakapagbukas ang Let's Encrypt ng TCP connection sa port 80 sa address na inaanunsyo ng iyong DNS. Ayon sa posibilidad: network firewall ng provider mo, na hiwalay sa ufw at kino-configure sa hosting panel; ufw ruleset na port 443 lamang o SSH lamang ang pinapahintulutan; DNS na nakaturo pa sa dating server; o stale-AAAA problem, kung saan sinubukan ng kanilang mga server ang IPv6 pero IPv4 lamang ang sinasagot ng iyo. Mag-test mula sa labas ng VPS. Gamitin ang curl -I http://example.com mula sa iyong laptop upang ulitin ang nakikita ng kanilang validator.

Nakaabot ka sa rate limit dahil paulit-ulit kang nag-retry.

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

Pinapahintulutan ng Let's Encrypt ang 5 bigong validation bawat hostname, bawat account, bawat oras. Simula sa kanilang 2025 rate-limit rework, isa itong refilling bucket. Nababalik ang humigit-kumulang isang retry bawat 12 minuto. Mabilis itong mauubos kapag paulit-ulit kang nagre-retry habang sira ang firewall. Gumagana ang paghihintay, pero ang tunay na ayos ay baguhin ang proseso: pagkatapos ng anumang failure, mag-debug gamit ang staging environment hanggang magtagumpay.

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

Tandaan ang certonly. Tinatanggap lamang ang --dry-run ng certonly at renew subcommands. Ang hiwalay na certbot --apache --dry-run form ay hindi talaga tumatakbo at ipinapakita sa iyo ang --dry-run currently only works with the 'certonly' or 'renew' subcommands. Nagva-validate ang dry run laban sa staging. May sarili itong mas maluwag na limit at hindi ito nag-i-issue ng totoong certificates, kaya maaari kang paulit-ulit na mabigo roon buong hapon. Patakbuhin lamang muli ang totoong command kapag pumasa na ang staging. Ang iba pang limit—50 certificates bawat registered domain bawat linggo at 5 duplicate ng parehong name set bawat linggo—ay maaabot mo lamang kung may script na paulit-ulit na nagre-reissue.

Kapag gumagana na ang HTTPS, tandaan na pinoprotektahan ng certificate ang transport, hindi ang server. Tumatanggap pa rin ng password guesses ang port 22 buong araw. Ang pagsama nito sa Fail2ban sa Ubuntu 24.04 ang natural na susunod na 30 minuto.

FAQ

Dapat ba akong mag-install ng Certbot gamit ang snap o apt para sa Apache sa Ubuntu 24.04?

Gamitin ang apt. Ang Ubuntu 24.04 ay nagre-release ng Certbot 2.9.0, na sapat na napapanahon para sa lahat ng nasa gabay na ito, tumatanggap ng security patch sa pamamagitan ng unattended-upgrades, at hindi nangangailangan ng snapd. Piliin lamang ang snap kung kailangan mo agad ang pinakabagong release o isang DNS plugin na eksklusibong ipinapamahagi bilang snap. Kung lilipat ka, apt remove certbot python3-certbot-apache muna upang hindi sabay na umiral ang dalawang renewal scheduler.

Bakit sinasabi ng Certbot na "Unable to find a virtual host listening on port 80"?

Dahil walang naka-enable na port-80 vhost na may ServerName o ServerAlias na tumutugma sa domain na ipinasa mo gamit ang -d. Sa default vhost ng Ubuntu, naka-comment out ang ServerName. Patakbuhin ang sudo apache2ctl -S, hanapin o gumawa ng vhost na dapat magmay-ari sa hostname, idagdag ang ServerName example.com, i-reload ang Apache, at patakbuhin muli ang Certbot.

Paano ko aayusin ang "Timeout during connect (likely firewall problem)"?

Hindi maabot ng Let's Encrypt ang port 80 sa address na inilalathala ng iyong DNS. Suriin ang network firewall sa panel ng iyong provider at ang ufw. Tiyaking ang dig +short example.com ay nagbabalik sa VPS na ito, at burahin o itama ang anumang lipas na AAAA record. Mas pinipili ng validation ang IPv6 kapag mayroon nito. Kumpirmahin ang pag-aayos mula sa labas ng server gamit ang curl -I http://example.com, pagkatapos ay magsagawa ng rehearsal gamit ang sudo certbot certonly --apache --dry-run -d example.com bago ang aktuwal na pag-issue.

Awtomatiko bang nire-renew ng Certbot ang mga certificate sa Ubuntu 24.04?

Oo. Ini-install ng apt package ang certbot.timer, isang systemd timer na tumatakbo nang dalawang beses bawat araw at nagre-renew ng anumang certificate na matatapos sa loob ng 30 araw, pagkatapos ay nire-reload ang Apache. Ginagamit naman ng snap ang snap.certbot.renew.timer para sa parehong gawain. I-verify gamit ang systemctl list-timers certbot.timer at magsagawa ng rehearsal gamit ang sudo certbot renew --dry-run. Huwag magdagdag ng sarili mong cron job.

Paano ako makakakuha ng wildcard certificate gamit ang Certbot at Apache?

Nangangailangan ang wildcard ng DNS-01 challenge. Kailangang maglagay ang Certbot ng TXT record sa _acme-challenge.example.com. Ibig sabihin, kailangan ng certbot-dns-* plugin na may API credentials para sa iyong DNS provider. Ang --manual alternative ay nangangailangan ng mano-manong pag-edit ng TXT records sa bawat renewal. Kung iilan lamang ang alam mong subdomain, mas simple ang SAN certificate na tahasang naglilista sa mga ito. Hindi rin nito kailangang ilagay ang mga DNS API key sa server.