Paano mag-install ng Certbot sa Apache Ubuntu

Ang iyong bubuuin

Isang Apache site sa Ubuntu 24.04 na gumagamit ng HTTPS gamit ang libre at browser-trusted na Let's Encrypt certificate — na ibibigay ng Certbot at awtomatikong i-re-renew ng isang systemd timer nang hindi mo na kailangang pakialaman. Isang linya lang ang command para sa prosesong ito. Lahat ng error ay mangyayari bago ang linyang iyon: vhost na walang ServerName, port 80 na naka-close sa firewall ng provider, o DNS na nakaturo pa rin sa lumang server. Dahil dito, nakatuon ang guide na ito sa mga preconditions, at ibibigay ang eksaktong error string para sa bawat pagkakamali.

Dalawang mahalagang paalala. Kung nginx ang iyong web server, pareho ang daloy nito pero magkaiba ang plugin at configs — gamitin ang nginx version ng guide na ito. At kung ang sine-secure mo ay internal-only — gaya ng admin panel sa isang private address o staging box na walang ibang bumibisita — hindi mo kailangan ng certificate authority; mas simple ang self-signed certificate at gumagana kahit offline.

Prerequisites, at ang tatlong dahilan kung bakit ito mabibigo bago pa tumakbo ang Certbot

• Naka-serve na ang Apache sa iyong site gamit ang plain HTTP. Ina-edit ng Apache plugin ng Certbot ang isang existing na site; hindi ito gumagawa ng bago. Kung nagsisimula ka sa isang bare VPS, i-setup muna ang LAMP stack sa Ubuntu 24.04 bago bumalik — ang guide na ito ang kulang na TLS chapter para dito.
• Isang public domain na may A record sa address ng iyong VPS. Dahil sa HTTP-01 challenge ng Let's Encrypt, kumokonekta ang kanilang validation servers sa iyong box mula sa internet: hindi pwede ang NATed homelab nang walang port forward, walang .local names, at walang bare IPs. Dapat ibalik ng dig +short example.com ang address ng iyong VPS. Kung binago mo ang DNS sa nakalipas na isang oras, maghintay muna na matapos ang TTL ng lumang record bago mag-issue.
• Kung mayroong AAAA record, dapat itong tama. Mas pinapaboran ng Let's Encrypt ang IPv6 kapag may naka-publish na AAAA record. Ang isang stale na AAAA ay magiging sanhi ng failure sa validation kahit na gumagana ang curl mula sa iyong laptop — na malamang ay IPv4 — nang maayos. Mag-publish ng tamang AAAA o huwag nang maglagay ng kahit ano.

Dapat bukas ang ports 80 at 443 sa ufw at sa network firewall ng iyong provider — karamihan ng hosting panels ay may pangalawang firewall na hindi nakikita ng OS. Ang HTTP-01 ay nagba-validate partikular sa port 80; hindi ito pwedeng patakbuhin nang 443-only.

sudo ufw allow "Apache Full"
sudo ufw status

Kapag naka-set up na ang mga ito, ang buong proseso ay tatagal lamang ng labinlimang minuto, at sampu sa mga ito ay pagbabasa.

Snap o apt Certbot? Sa 24.04, maayos na ang apt

Lumipat ang Certbot sa snap distribution ilang taon na ang nakalilipas dahil sa isang mahalagang dahilan: ang mga distro package ay hindi na nag-uupdate. Ang Ubuntu 20.04 ay may Certbot 0.40 at hindi na nagbago, kaya napagod ang project sa pag-debug ng mga bug na limang taon na ang tanda. Sa 24.04, wala na ang dahilan na ito — ang archive ay may Certbot 2.9.0, isang current-generation release, at ang unattended-upgrades ang nagpapanatili ng mga patch nito. Ang rekomendasyon ko para sa OS na ito: gamitin ang apt. Hindi mo na kailangang i-run ang snapd daemon, kasabay na ang installation ng Apache plugin sa iisang transaction, at ang renewal timer ay integrated sa systemd sa pamamaraang Debian.

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

Tamang resulta: certbot 2.9.0. Ang python3-certbot-apache package ang plugin na nagbabasa at nag-e-edit ng iyong mga Apache config — kung wala ito, mag-e-error ang certbot --apache gamit ang The requested apache plugin does not appear to be installed.

Ang snap ay tama pa ring gamitin sa dalawang kaso: kung gusto mo ang pinakabagong Certbot sa araw na ilabas ito, o kung kailangan mo ng DNS plugin na snap lang ang distribution (marami sa mga certbot-dns-* provider plugins ang ganito). Kung ito 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 patakbuhin ang dalawa. Ang dalawang install ay nangangahulugang may dalawang renewal scheduler na nag-aagawan sa /etc/letsencrypt, at ang certbot na makikita ng iyong shell sa PATH ay maaaring hindi ang may-ari ng iyong mga certificate. Ang apt remove na linya sa itaas ay hindi lamang dekorasyon.

Dapat ay nakagawa na ng vhost Certbot edits — ServerName ang pinakaimportante

Gumagana ang certbot --apache sa pamamagitan ng paghahanap sa port-80 virtual host kung saan ang ServerName o ServerAlias ay tumutugma sa bawat -d domain na ibinigay mo. Pinapatunayan nito ang kontrol sa domain, at pagkatapos ay gagawa ng SSL twin para sa vhost na iyon. Kapag walang tugmang ServerName, walang match — at ang default na 000-default.conf ng Ubuntu ay may ServerName na naka-comment out. Ang isang commented line na ito ang pinaka-karaniwang dahilan kung bakit nagfe-fail ang isang command sa guide na ito.

Kaya bago gamitin ang Certbot, bigyan ang site ng tamang name-based vhost. I-create 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 i-confirm na nababasa ng Apache ang configuration at nairoroute ang pangalan dito:

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

Dapat mag-print ang configtest ng Syntax OK. Kung mag-print din ito ng AH00558: apache2: Could not reliably determine the server's fully qualified domain name, babala ito tungkol sa global ServerName, hindi sa iyong vhost — wala itong epekto rito, at maaari itong i-silence 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 pagsusuri. Kailangan mo ng linya na katulad 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 binasa nito, hindi ang file na in-edit mo sa sites-available. Kung hindi nakalista ang example.com sa port 80, hindi rin ito mahahanap ng Certbot.

Issue the certificate: certbot --apache

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

Tatlong bagay ang hihingin sa unang pagtakbo: email address (ginagamit para sa iyong ACME account at mahahalagang CA notices; hindi na nagpapadala ang Let's Encrypt ng expiry warnings, kaya ikaw na ang dapat mag-monitor ng renewals), pagsang-ayon sa terms ng Let's Encrypt, at kung gusto mong i-share ang iyong email sa EFF. Wala nang redirect question: simula sa Certbot 2.0, default na ang pag-redirect ng Apache installer mula HTTP patungong HTTPS, na siyang kailangan mo. Gamitin ang flag na --no-redirect kung kailangan mo talaga ang plain HTTP para mag-serve ng content.

Ganito ang itsura ng success, at dapat itong basahin nang mabuti sa halip na i-skim lang:

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 ito, apat na bagay ang ginawa ng Certbot: i-enabled ang Apache ssl module kung hindi pa ito naka-on, isinulat ang example.com-le-ssl.conf — isang kopya ng iyong vhost sa *:443 na may SSLEngine on at ang mga certificate paths — i-enabled ito, at nagdagdag ng RewriteRule block sa orihinal na port-80 vhost na nag-301 sa lahat ng traffic patungong HTTPS. Ang orihinal mong vhost file ay ine-edit, hindi pinapalitan, at ang SSL twin nito ay nasa tabi nito kung saan mababasa mo ang bawat linyang idinagdag nito.

Kung nasaan ang certificate at bakit hindi ito dapat i-copy

Lahat ay nasa ilalim ng /etc/letsencrypt/live/example.com/: fullchain.pem (ang certificate at ang intermediate chain — ito ang dapat ituro ng mga server), privkey.pem (ang private key, para sa root-readable lamang), pati na ang cert.pem at chain.pem para sa mga software na nangangailangan ng hiwalay na mga file. Ang mga ito ay mga symlink sa /etc/letsencrypt/archive/, at ang indirection na ito ang nagsisilbing renewal mechanism: ang renewal ay nagsusulat ng mga bagong file sa archive/ at muling itinuturo ang mga symlink. Ituro ang anumang software sa mga path ng live/ para awtomatikong makuha ang mga renewal; kung i-copy ang mga file sa ibang lokasyon, magdudulot ito ng outage pagkalipas ng 90 days.

Ang isa pang file na dapat malaman ay ang /etc/letsencrypt/renewal/example.com.conf, kung saan nakatala kung paano inisyu ang certificate na ito — authenticator = apache, installer = apache, at ang mga domains — upang magawa ng renewal ang proseso nang walang tulong ng tao, kasama na ang pag-reload ng Apache pagkatapos.

Naka-schedule na ang renewal — i-verify ito, huwag nang gumawa ng bago

Ang mga Let's Encrypt certificate ay tumatagal ng 90 days sa disenyo nito. Ang nakainstall na apt package ay mayroon nang systemd timer na nagpapatakbo sa Certbot nang dalawang beses kada araw sa randomized na oras. I-re-renew nito ang anumang certificate na malapit nang mag-expire sa loob ng 30 days. Huwag nang magdagdag ng cron job; ang pangalawang scheduler ay magdudulot lamang ng log noise at panganib sa rate-limit.

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

Ipinapakita ng unang command na active ang timer, kung saan ang NEXT time ay nasa loob ng susunod na 24 hours — ang schedule ay dalawang beses kada araw na may randomized delay, kaya ang eksaktong oras ay sadyang hindi predictable (sa snap install, ang timer ay snap.certbot.renew.timer sa halip). Ang dry run ay nagsasagawa ng full renewal rehearsal gamit ang Let's Encrypt staging environment — totoong challenge, pero walang issued certificate at walang rate-limit cost. Ang tamang resulta ay nagtatapos sa:

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

Kung mabigo ang dry run, mabibigo rin ang totoong renewal sa ~60 days sa parehong paraan — ayusin ito ngayon habang ang kasalukuyang certificate ay may mahaba pang lifetime. Ang karaniwang sanhi ay isang firewall rule na naidagdag pagkatapos ng issuance na muling nagsara sa port 80.

I-verify gamit ang curl, at ang dapat na status 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 ibalik ng una ang HTTP/1.1 301 Moved Permanently na may Location: https://example.com/ header — ito ang redirect na in-install ng Certbot. Dapat ibalik ng ikalawa ang HTTP/1.1 200 OK nang walang TLS complaint mula sa curl. Ipi-print 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 days bago mag-expire. Sa browser, makikita mo ang padlock, at ang pag-click dito ay magpapakita ng 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.

Multiple sites: isang SAN certificate o isang cert bawat site

Parehong gumagana ang mga ito; pareho ang paraan ng renewal nila. Para sa mga hindi magkakaugnay na site sa iisang box, i-run ang issue command nang minsan bawat site — bawat isa ay magkakaroon ng sariling directory sa ilalim ng live/ at sariling renewal config. Hindi nakakaapekto ang problema sa isang domain sa renewal ng iba. Ito ang default na setup ko.

Para sa isang site na may maraming pangalan, pagsamahin sila sa isang SAN certificate — ang isang cert ay maaaring maglaman ng hanggang 100 na pangalan. Nagawa mo na ito sa itaas gamit ang example.com at www.example.com. Para magdagdag ng pangalan sa isang existing na certificate sa hinaharap, i-reissue ang cert gamit 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 ang pagbabago sa domain set, hihilingin ang kumpirmasyon para sa expansion, at papalitan ang certificate sa mismong lokasyon nito — parehong live/ path, kaya wala nang ibang kailangang baguhin. Tandaan na ang listahan ay isang replacement, hindi append: kung tatanggalin ang www sa command na iyon, awtomatikong mawawala ang domain na iyon sa bagong certificate.

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

Hindi makakapag-issue ang HTTP-01 ng *.example.com — ang paglalagay ng file sa isang web server ay nagpapatunay lamang ng kontrol sa isang hostname, hindi sa buong namespace. Ang mga wildcard ay nangangailangan ng DNS-01 challenge: naglalagay ang Certbot ng TXT record sa _acme-challenge.example.com. Sa praktikal na aspeto, nangangailangan ito ng certbot-dns-* plugin na may API credentials para sa iyong DNS provider, o manual na pag-edit ng mga TXT record sa bawat renewal gamit ang --manual (mahirap itong gawin — huwag itong gawing basehan ng iyong plano). Ang kumpletong walkthrough, mula sa mechanics ng TXT record hanggang sa plugin para sa unattended renewal, ay nasa wildcard certificates with Certbot over DNS-01. Payo: kung mayroon kang apat na kilalang subdomains, mas simple ang isang SAN certificate na nakalista ang lahat ng apat kaysa sa isang wildcard, at hindi nito kailangan ng DNS API keys sa server.

Failure modes, kasama ang mga string na makikita mo

Hindi magsisimula ang Certbot dahil sira ang config 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')

Tatakbo ang plugin sa configtest bago gumalaw sa kahit ano, at hihinto kung may error ang Apache — ang mga \ns ay literal dahil ipinapakita ng Certbot ang repr ng exception. Patakbuhin ang sudo apache2ctl configtest nang manu-mano: ipinapakita nito ang file at line — karaniwang typo mula sa manual editing, isang SSLCertificateFile na nakaturo sa path na wala na, o isang module na tinatawag pero hindi enabled. Ayusin hanggang sa lumabas 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 missing-ServerName failure na nabanggit kanina, na nahuli sa oras ng pag-issue. Hinanap ng Certbot ang bawat enabled na port-80 vhost para sa isang ServerName/ServerAlias na tumutugma sa iyong -d at walang nahanap. Ipinapakita ng sudo apache2ctl -S kung ano ang aktuwal na nira-route ng Apache; idagdag ang ServerName line sa tamang vhost, i-reload, at subukan muli. Ang katulad nito ay ang validation na napupunta sa maling vhost — ang challenge response ay nagiging Invalid response ... 404 dahil ibang site ang nakakuha ng request. Pareho ang diagnosis at pareho ang tool: apache2ctl -S.

Nag-timeout ang validation.

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

Hindi mabuksan ng Let's Encrypt ang TCP connection sa port 80 sa address na ibinibigay ng iyong DNS. Ayon sa pagkakataon: network firewall ng iyong provider (iba sa ufw, naka-configure sa hosting panel), ufw ruleset na 443 o SSH lang ang pinapayagan, DNS na nakaturo pa rin sa lumang server, o ang stale-AAAA problem — sinubukan ng kanilang servers ang IPv6, pero IPv4 lang ang sumasagot sa iyo. Mag-test mula sa labas ng VPS: ang curl -I http://example.com mula sa iyong laptop ay magpapakita ng parehong nakikita ng kanilang validator.

Naabot mo ang rate limit dahil sa paulit-ulit na pag-retry.

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

Pinapayagan ng Let's Encrypt ang 5 failed validations bawat hostname bawat account bawat oras — simula sa kanilang 2025 rate-limit rework, ito ay isang refilling bucket, kung saan nakakakuha ka ng halos isang retry kada 12 minuto — at ang mabilis na pag-retry habang sira ang firewall ay mabilis na uubos nito. Gumagana ang paghihintay, pero ang tunay na solusyon ay pagbabago sa paraan ng paggawa: pagkatapos ng anumang failure, mag-debug gamit ang staging environment hanggang sa maging successful ito.

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

Tandaan ang certonly: ang --dry-run ay tinatanggap lamang ng mga certonly at renew subcommands, at ang mismong certbot --apache --dry-run form ay hindi gagana at sasabihing --dry-run currently only works with the 'certonly' or 'renew' subcommands. Ang dry run ay nagva-validate laban sa staging, na may sariling maluwag na limits at hindi naglalabas ng mga totoong certificate, kaya maaari kang magkamali doon nang buong hapon. Patakbuhin lamang ang totoong command kapag pasado na ang staging. Ang iba pang limits — 50 certificates bawat registered domain bawat linggo, 5 duplicates ng parehong name set bawat linggo — ay makikita mo lang kung ang isang script ay paulit-ulit na nag-i-issue.

Kapag up na ang HTTPS, tandaan na ang certificate ay nag-secure sa transport, hindi sa server: ang port 22 ay patuloy pa ring tumatanggap ng mga password guesses buong araw. Ang paggamit nito kasama ang Fail2ban sa Ubuntu 24.04 ang susunod na lohikal na hakbang.

FAQ

Dapat ko bang i-install ang Certbot gamit ang snap o apt para sa Apache sa Ubuntu 24.04?

Gamitin ang apt. Ang Ubuntu 24.04 ay may kasamang Certbot 2.9.0, na sapat na ang bersyon para sa lahat ng nasa guide na ito, nakakakuha ng security patches sa pamamagitan ng unattended-upgrades, at hindi nangangailangan ng snapd. Gamitin lamang ang snap kung kailangan mo agad ang pinakabagong release o kung kailangan mo ng DNS plugin na eksklusibong distributed bilang snap — at kung lilipat ka, unahin ang apt remove certbot python3-certbot-apache para hindi magkaroon ng dalawang renewal schedulers.

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

Dahil walang enabled na port-80 vhost na may ServerName o ServerAlias na tumutugma sa domain na ibinigay mo gamit ang -d — ang default vhost ng Ubuntu ay may naka-comment out na ServerName. Patakbuhin ang sudo apache2ctl -S, hanapin (o gumawa) ng vhost na dapat ang may-ari ng pangalan, idagdag ang ServerName example.com, i-reload ang Apache, at i-rerun ang Certbot.

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

Hindi maabot ng Let's Encrypt ang port 80 sa address na naka-publish sa iyong DNS. Suriin ang network firewall sa panel ng iyong provider pati na ang ufw, kumpirmahin kung ang dig +short example.com ay bumabalik sa VPS na ito, at burahin o itama ang anumang lumang AAAA record — mas pinapaboran ng validation ang IPv6 kung mayroon nito. Kumpirmahin ang fix mula sa labas ng server gamit ang curl -I http://example.com, at mag-rehearse gamit ang sudo certbot certonly --apache --dry-run -d example.com bago ang totoong issuance.

Nag-a-automatic ba ang renewal ng mga certificate ng Certbot sa Ubuntu 24.04?

Oo. Ang apt package ay nag-i-install ng certbot.timer, isang systemd timer na tumatakbo nang dalawang beses kada araw at nagre-renew ng anumang certificate na malapit nang mag-expire (loob ng 30 days), at i-re-reload ang Apache pagkatapos; ang snap ay gumagamit ng snap.certbot.renew.timer para sa parehong trabaho. I-verify gamit ang systemctl list-timers certbot.timer at mag-rehearse gamit ang sudo certbot renew --dry-run — huwag nang magdagdag ng sarili mong cron job.

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

Ang mga wildcard ay nangangailangan ng DNS-01 challenge: dapat maglagay ang Certbot ng TXT record sa _acme-challenge.example.com, na nangangahulugang kailangan ng isang certbot-dns-* plugin na may API credentials para sa iyong DNS provider (ang --manual alternative ay nangangailangan ng manu-manong pag-edit ng mga TXT record sa bawat renewal). Kung iilang subdomains lang ang kailangan mo, mas simple ang SAN certificate na naglilista sa mga ito nang direkta at hindi na kailangang ilagay ang DNS API keys sa server.