Cara pasang Certbot Apache di Ubuntu 24.04

Apa yang anda bina

Sebuah tapak Apache pada Ubuntu 24.04 yang bertindak balas melalui HTTPS dengan sijil Let's Encrypt percuma yang dipercayai oleh pelayar — dikeluarkan oleh Certbot, dan diperbaharui secara automatik oleh pemasa systemd yang tidak perlu anda uruskan lagi. Perintah yang menjalankan tugas ini hanyalah satu baris. Segala kegagalan berlaku sebelum baris tersebut: vhost tanpa ServerName, port 80 ditutup pada tembok api pembekal, atau DNS masih menghala ke pelayan lama. Oleh itu, panduan ini menumpukan sebahagian besar masa pada prasyarat, dan menyatakan rentetan ralat tepat bagi setiap kesilapan.

Dua nota skop. Jika pelayan web anda ialah nginx, aliran kerjanya adalah sama tetapi plugin dan konfigurasinya berbeza — gunakan versi nginx untuk panduan ini sebagai ganti. Dan jika perkara yang anda ingin lindungi adalah untuk kegunaan dalaman sahaja — panel admin pada alamat peribadi, atau kotak staging yang tidak dikunjungi sesiapa — anda tidak memerlukan pihak berkuasa sijil sama sekali; sijil self-signed adalah lebih ringkas dan berfungsi secara luar talian.

Prasyarat, dan tiga sebab kegagalan sebelum Certbot dijalankan

• Apache sudah melayani laman web anda melalui HTTP biasa. Plugin Apache Certbot mengubah suai tapak sedia ada; ia tidak mencipta tapak baharu. Jika anda bermula dengan VPS kosong, bina LAMP stack pada Ubuntu 24.04 terlebih dahulu sebelum menyambung — panduan ini adalah bab TLS yang diperlukan.
• Domain awam dengan rekod A pada alamat VPS anda. Cabaran HTTP-01 Let's Encrypt bermaksud pelayan pengesahan mereka menyambung ke pelayan anda melalui internet: tiada homelab dengan NAT tanpa pemindahan port, tiada nama .local, tiada IP kosong. dig +short example.com mesti memulangkan alamat VPS anda, dan jika anda menukar DNS dalam tempoh satu jam terakhir, tunggu sehingga TTL rekod lama tamat sebelum mengeluarkan sijil.
• Jika rekod AAAA wujud, ia mestilah betul. Let's Encrypt mengutamakan IPv6 apabila rekod AAAA diterbitkan, jadi rekod AAAA yang lapuk akan menyebabkan kegagalan pengesahan walaupun curl dari komputer riba anda — mungkin melalui IPv4 — berfungsi dengan baik. Terbitkan AAAA yang betul atau jangan terbitkan langsung.

Port 80 dan 443 perlu dibuka dalam ufw dan dalam firewall rangkaian pembekal anda — kebanyakan panel pengehosan mempunyai firewall kedua yang tidak dilihat oleh OS. HTTP-01 melakukan pengesahan khusus melalui port 80; anda tidak boleh menjalankan ini hanya dengan port 443.

sudo ufw allow "Apache Full"
sudo ufw status

Setelah semua ini tersedia, keseluruhan tugasan hanya mengambil masa lima belas minit, dan sepuluh minit daripadanya adalah untuk membaca.

Snap atau apt Certbot? Pada 24.04, apt akhirnya sudah memadai

Certbot telah berpindah ke pengedaran snap bertahun-tahun dahulu atas sebab yang kukuh: pakej distro sudah ketinggalan zaman. Ubuntu 20.04 membekalkan Certbot 0.40 dan tidak pernah dikemas kini, menyebabkan projek tersebut sukar membaiki pepijat lama. Pada 24.04, masalah itu tidak lagi wujud — arkib membekalkan Certbot 2.9.0, iaitu versi generasi semasa, dan unattended-upgrades memastikan ia sentiasa dikemas kini. Cadangan saya untuk OS ini: gunakan apt. Anda tidak perlu menjalankan daemon snapd, plugin Apache dipasang dalam transaksi yang sama, dan pemasa pembaharuan bersepadu dengan systemd mengikut cara Debian yang biasa.

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

Hasil yang betul: certbot 2.9.0. Pakej python3-certbot-apache adalah plugin yang membaca dan menyunting konfigurasi Apache anda — tanpa plugin ini, certbot --apache akan gagal dengan The requested apache plugin does not appear to be installed.

Snap masih merupakan pilihan yang tepat dalam dua keadaan: anda mahukan Certbot terbaharu sebaik sahaja ia dikeluarkan, atau anda memerlukan plugin DNS yang hanya diedarkan sebagai snap (beberapa plugin pembekal certbot-dns-* adalah sedemikian). Jika anda memilih cara itu:

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

Mana-mana yang anda pilih, jangan jalankan kedua-duanya. Dua pemasangan bermaksud dua penjadual pembaharuan akan bertindih pada /etc/letsencrypt, dan certbot yang ditemui shell anda dalam PATH mungkin bukan pemilik sijil anda. Baris apt remove di atas bukan sekadar hiasan.

Suntingan vhost Certbot mesti sudah wujud — ServerName adalah kunci utama

certbot --apache berfungsi dengan mencari virtual host port-80 yang mana ServerName atau ServerAlias sepadan dengan setiap domain -d yang anda berikan. Ini membuktikan kawalan ke atas domain tersebut, kemudian ia menulis kembar SSL bagi vhost tersebut. Jika tiada ServerName yang sepadan, tiada padanan ditemui — dan 000-default.conf lalai Ubuntu disertakan dengan ServerName yang telah dikomen. Baris dikomen tersebut adalah sebab paling utama mengapa satu arahan besar dalam panduan ini gagal.

Oleh itu, sebelum menyentuh Certbot, berikan laman web tersebut vhost berasaskan nama yang betul. Cipta /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>

Aktifkan ia dan sahkan Apache berjaya menterjemah serta menghalakan nama tersebut kepadanya:

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

configtest mesti memaparkan Syntax OK. Jika ia juga memaparkan AH00558: apache2: Could not reliably determine the server's fully qualified domain name, itu adalah amaran tentang ServerName global, bukan vhost anda — ia tidak berbahaya di sini, dan akan disenyapkan oleh echo "ServerName $(hostname -f)" | sudo tee /etc/apache2/conf-available/servername.conf && sudo a2enconf servername && sudo systemctl reload apache2.

Output -S adalah semakan yang penting. Anda memerlukan baris seperti port 80 namevhost example.com (/etc/apache2/sites-enabled/example.com.conf:1) dengan alias www.example.com di bawahnya — Apache melaporkan symlink sites-enabled yang sebenarnya dibaca, bukan fail yang anda sunting dalam sites-available. Jika example.com tidak disenaraikan pada port 80, Certbot juga tidak akan menemuinya.

Keluarkan sijil: certbot --apache

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

Larian pertama akan meminta tiga perkara: alamat e-mel (digunakan untuk akaun ACME dan pemberitahuan penting CA; Let's Encrypt tidak lagi menghantar amaran tamat tempoh, jadi anda perlu memantau pembaharuan sendiri), persetujuan terhadap terma Let's Encrypt, dan sama ada anda ingin berkongsi e-mel dengan EFF. Tiada lagi soalan tentang penghalaan (redirect): sejak Certbot 2.0, pemasang Apache menghala HTTP ke HTTPS secara lalai, yang merupakan tetapan yang anda inginkan. Gunakan --no-redirect jika anda benar-benar memerlukan HTTP biasa untuk terus menghantar kandungan.

Kejayaan kelihatan seperti ini, dan anda harus membacanya dengan teliti dan bukannya sekadar imbas:

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

Di sebalik mesej tersebut, Certbot telah melakukan empat perkara: mengaktifkan modul ssl Apache jika ia belum diaktifkan, menulis example.com-le-ssl.conf — salinan vhost anda pada *:443 dengan SSLEngine on dan laluan sijil — mengaktifkannya, dan menambah blok RewriteRule pada vhost port-80 asal yang menghala semua trafik ke HTTPS melalui 301. Fail vhost asal anda disunting, bukan diganti, dan salinan SSL berada di sebelahnya supaya anda boleh membaca setiap baris yang ditambah.

Di mana sijil disimpan, dan mengapa anda tidak boleh menyalinnya

Semuanya disimpan di bawah /etc/letsencrypt/live/example.com/: fullchain.pem (sijil beserta rantaian perantara — yang perlu dirujuk oleh pelayan), privkey.pem (kunci peribadi, hanya boleh dibaca oleh root), serta cert.pem dan chain.pem untuk perisian yang memerlukan fail secara berasingan. Fail-fail ini adalah symlink ke /etc/letsencrypt/archive/, dan sistem rujukan ini merupakan mekanisme pembaharuan: proses pembaharuan akan menulis fail baharu ke dalam archive/ dan mengemas kini symlink tersebut. Halakan mana-mana perisian lain ke laluan live/ untuk menerima pembaharuan secara automatik; jika anda menyalin fail ke lokasi lain, anda akan menghadapi gangguan perkhidmatan dalam masa 90 hari.

Fail lain yang penting untuk diketahui ialah /etc/letsencrypt/renewal/example.com.conf, yang merekodkan cara sijil ini dikeluarkan — authenticator = apache, installer = apache, domain yang terlibat — supaya proses pembaharuan boleh dilakukan secara automatik, termasuk memuat semula Apache selepas itu.

Pembaharuan telah dijadualkan — sahkan, jangan bina semula

Sijil Let's Encrypt bertahan selama 90 hari secara reka bentuk, dan pakej apt telah memasang mekanismenya: pemasa systemd yang menjalankan Certbot dua kali sehari pada masa rawak, membaharui mana-mana sijil dalam tempoh 30 hari sebelum tamat tempoh. Jangan tambah tugasan cron; penjadual kedua hanya menambah gangguan log dan risiko had kadar (rate-limit).

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

Perintah pertama menunjukkan pemasa aktif, dengan masa NEXT dalam tempoh 24 jam akan datang — jadual adalah dua kali sehari dengan kelewatan rawak, jadi masa tepat adalah sengaja tidak dapat diramal (pada pemasangan snap, pemasa adalah snap.certbot.renew.timer). Dry run melakukan simulasi pembaharuan penuh terhadap persekitaran staging Let's Encrypt — cabaran sebenar, tiada sijil dikeluarkan, tiada kos had kadar. Hasil yang betul berakhir dengan:

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

Jika dry run gagal, pembaharuan sebenar dalam ~60 hari akan gagal dengan cara yang sama — baiki sekarang, selagi sijil semasa masih mempunyai tempoh hayat yang panjang. Punca biasa adalah peraturan firewall yang ditambah selepas pengeluaran yang menutup semula port 80.

Sahkan dengan curl, dan apa yang perlu dipaparkan oleh ikon mangga

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

Yang pertama harus memulangkan HTTP/1.1 301 Moved Permanently dengan pengepala Location: https://example.com/ — ini adalah penghalaan (redirect) yang dipasang oleh Certbot. Yang kedua harus memulangkan HTTP/1.1 200 OK tanpa sebarang ralat TLS daripada curl. Yang ketiga memaparkan penerbit — baris O = Let's Encrypt dengan CN pendek seperti R12 atau E7 — dan notAfter kira-kira 90 hari dari tarikh tamat. Dalam pelayar web, anda akan melihat ikon mangga, dan klik padanya akan menunjukkan penerbit yang sama. Jika curl berfungsi tetapi pelayar memberikan amaran, anda hampir pasti sedang melihat halaman yang tersimpan dalam cache atau nama hos yang salah, bukannya masalah sijil.

Pelbagai tapak: satu sijil SAN atau satu sijil bagi setiap tapak

Kedua-duanya berfungsi; proses pembaharuan adalah sama. Untuk tapak yang tidak berkaitan pada mesin yang sama, jalankan arahan isu sekali bagi setiap tapak — setiap tapak akan mendapat direktori sendiri di bawah live/ dan konfigurasi pembaharuan sendiri. Masalah pada satu domain tidak akan menghalang pembaharuan domain yang lain. Ini adalah tetapan lalai saya.

Untuk satu tapak dengan beberapa nama, letakkan semuanya pada satu sijil SAN — satu sijil boleh memuatkan sehingga 100 nama. Anda telah melakukan ini di atas dengan example.com dan www.example.com. Untuk menambah nama pada sijil sedia ada kemudian, keluarkan semula sijil dengan menamakan sijil tersebut dan senarai penuh yang baharu:

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

Certbot mengesan set domain yang telah berubah, meminta anda mengesahkan pengembangan, dan menggantikan sijil tersebut di lokasi asal — menggunakan laluan live/ yang sama, jadi tiada perkara lain yang perlu diubah. Perlu diingat bahawa senarai tersebut adalah penggantian, bukan penambahan: jika anda menggugurkan www daripada arahan tersebut, sijil baharu akan membuang nama tersebut secara senyap.

Wildcards memerlukan DNS-01, dan biasanya anda tidak memerlukan wildcard

HTTP-01 tidak boleh mengeluarkan *.example.com — meletakkan fail pada pelayan web membuktikan kawalan ke atas satu hostname, bukan seluruh namespace. Wildcard memerlukan cabaran DNS-01: Certbot menetapkan rekod TXT pada _acme-challenge.example.com, yang secara praktikalnya memerlukan plugin certbot-dns-* dengan kredensial API untuk penyedia DNS anda, atau menyunting rekod TXT secara manual pada setiap pembaharuan dengan --manual (sukar — jangan rancang berdasarkan kaedah ini). Panduan lengkap, daripada mekanik rekod TXT sehingga plugin yang memperbaharui secara automatik, terdapat dalam sijil wildcard dengan Certbot melalui DNS-01. Nasihat jujur: jika anda mempunyai empat subdomain yang diketahui, sijil SAN yang menyenaraikan keempat-empat subdomain tersebut adalah lebih mudah daripada wildcard dan tidak memerlukan kunci API DNS disimpan pada pelayan.

Mod kegagalan, dengan rentetan yang akan anda lihat

Certbot enggan bermula kerana konfigurasi Apache rosak.

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 ini menjalankan configtest sebelum melakukan sebarang tindakan dan akan berhenti jika Apache sendiri mengalami ralat — \n adalah literal kerana Certbot mencetak repr pengecualian tersebut. Jalankan sudo apache2ctl configtest sendiri: ia akan menyatakan fail dan baris — biasanya disebabkan kesilapan taip semasa suntingan manual, SSLCertificateFile yang merujuk kepada laluan yang tidak lagi wujud, atau modul yang dirujuk tetapi tidak diaktifkan. Baiki sehingga ia mencetak Syntax OK, kemudian jalankan semula Certbot.

Tiada vhost yang sepadan dengan domain.

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

Ini adalah kegagalan kekurangan-ServerName yang dinyatakan sebelum ini, dikesan semasa proses pengeluaran. Certbot telah mencari setiap vhost port-80 yang diaktifkan untuk ServerName/ServerAlias yang sepadan dengan -d anda dan tidak menemui apa-apa. sudo apache2ctl -S menunjukkan apa yang sebenarnya dihalakan oleh Apache; tambahkan baris ServerName pada vhost yang betul, muat semula, dan cuba lagi. Masalah berkaitan ialah pengesahan mencapai vhost yang salah — respons cabaran kembali sebagai Invalid response ... 404 kerana laman web lain telah menangkap permintaan tersebut. Diagnosis dan alat yang sama: apache2ctl -S.

Pengesahan tamat tempoh (timeout).

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

Let's Encrypt tidak dapat membuka sambungan TCP ke port 80 pada alamat yang diiklankan oleh DNS anda. Mengikut kebarangkalian: firewall rangkaian pembekal anda (berasingan daripada ufw, dikonfigurasi dalam panel pengehosan), set peraturan ufw yang hanya membenarkan 443 atau hanya SSH, DNS masih merujuk kepada pelayan terdahulu, atau masalah stale-AAAA — pelayan mereka cuba IPv6, manakala pelayan anda hanya menjawab pada IPv4. Uji dari luar VPS: curl -I http://example.com dari komputer riba anda akan meniru apa yang dilihat oleh validator mereka.

Anda telah mencuba terlalu banyak kali sehingga terkena had kadar (rate limit).

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

Let's Encrypt membenarkan 5 kegagalan pengesahan bagi setiap nama hos bagi setiap akaun setiap jam — sejak rombakan had kadar 2025, ia adalah sistem baldi yang diisi semula, di mana anda mendapat semula kira-kira satu percubaan setiap 12 minit — dan melakukan percubaan berulang kali terhadap firewall yang rosak akan menghabiskan kuota dengan cepat. Menunggu adalah jalan penyelesaian, tetapi penyelesaian sebenar adalah perubahan tingkah laku: selepas sebarang kegagalan, lakukan penyahpepijatan dengan persekitaran staging sehingga ia berjaya.

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

Perhatikan certonly: --dry-run hanya diterima oleh subperintah certonly dan renew, manakala bentuk certbot --apache --dry-run yang kosong akan enggan berjalan dan memberitahu anda --dry-run currently only works with the 'certonly' or 'renew' subcommands. Dry run mengesahkan terhadap staging, yang mempunyai hadnya sendiri yang lebih longgar dan tidak mengeluarkan sijil sebenar, jadi anda boleh gagal di sana sepanjang petang. Hanya jalankan semula arahan sebenar setelah staging berjaya. Had yang lain — 50 sijil bagi setiap domain berdaftar setiap minggu, 5 pendua bagi set nama yang sama setiap minggu — hanya akan anda hadapi jika skrip melakukan pengeluaran semula dalam gelung (loop).

Setelah HTTPS berfungsi, ingat bahawa sijil tersebut mengamankan pengangkutan, bukan pelayan: port 22 masih menerima cubaan tekaan kata laluan sepanjang hari. Memadankan ini dengan Fail2ban pada Ubuntu 24.04 adalah langkah seterusnya yang logik.

FAQ

Patutkah saya memasang Certbot menggunakan snap atau apt untuk Apache pada Ubuntu 24.04?

Gunakan apt. Ubuntu 24.04 menyertakan Certbot 2.9.0, yang sudah memadai untuk semua perkara dalam panduan ini, menerima tampalan keselamatan melalui unattended-upgrades, dan tidak memerlukan snapd. Pilih snap hanya jika anda memerlukan versi terbaharu dengan segera atau memerlukan plugin DNS yang diedarkan secara eksklusif sebagai snap — dan jika anda bertukar, lakukan apt remove certbot python3-certbot-apache terlebih dahulu supaya dua penjadual pembaharuan tidak wujud serentak.

Mengapa Certbot menyatakan "Unable to find a virtual host listening on port 80"?

Ini berlaku kerana tiada vhost port-80 yang diaktifkan mempunyai ServerName atau ServerAlias yang sepadan dengan domain yang anda berikan dengan -d — vhost lalai Ubuntu disertakan dengan ServerName yang telah dikomen. Jalankan sudo apache2ctl -S, cari (atau cipta) vhost yang sepatutnya memiliki nama tersebut, tambah ServerName example.com, muat semula Apache, dan jalankan semula Certbot.

Bagaimanakah saya membaiki "Timeout during connect (likely firewall problem)"?

Let's Encrypt tidak dapat menghubungi port 80 pada alamat yang diterbitkan oleh DNS anda. Periksa firewall rangkaian pada tahap panel pembekal anda serta ufw, sahkan dig +short example.com memulangkan VPS ini, dan padam atau betulkan mana-mana rekod AAAA yang lama — proses pengesahan lebih mengutamakan IPv6 jika ia wujud. Sahkan pembaikan dari luar pelayan dengan curl -I http://example.com, kemudian lakukan latihan dengan sudo certbot certonly --apache --dry-run -d example.com sebelum pengeluaran sebenar.

Adakah Certbot memperbaharui sijil secara automatik pada Ubuntu 24.04?

Ya. Pakej apt memasang certbot.timer, iaitu pemasa systemd yang berjalan dua kali sehari dan memperbaharui mana-mana sijil dalam tempoh 30 hari sebelum tamat tempoh, kemudian memuat semula Apache; versi snap menggunakan snap.certbot.renew.timer untuk tugas yang sama. Sahkan dengan systemctl list-timers certbot.timer dan lakukan latihan dengan sudo certbot renew --dry-run — jangan tambah tugasan cron anda sendiri.

Bagaimanakah saya mendapatkan sijil wildcard dengan Certbot dan Apache?

Wildcard memerlukan cabaran DNS-01: Certbot mesti meletakkan rekod TXT pada _acme-challenge.example.com, yang bermaksud anda memerlukan plugin certbot-dns-* dengan kredensial API untuk pembekal DNS anda (alternatif --manual memerlukan rekod TXT yang disunting secara manual pada setiap pembaharuan). Jika anda hanya mempunyai beberapa subdomain yang diketahui, sijil SAN yang menyenaraikannya secara eksplisit adalah lebih mudah dan mengekalkan kunci API DNS daripada disimpan di dalam pelayan.