Cara Pasang Certbot Apache di Ubuntu 24.04

Apa yang anda sedang bina

Satu tapak Apache pada Ubuntu 24.04 yang menjawab melalui HTTPS dengan sijil Let's Encrypt percuma yang dipercayai pelayar, dikeluarkan oleh Certbot, dan diperbaharui secara automatik oleh pemasa systemd yang tidak perlu anda fikirkan lagi. Perintah yang melakukan kerja ini hanyalah satu baris. Segala perkara yang tidak menjadi akan berlaku sebelum baris tersebut: vhost tanpa ServerName, port 80 ditutup pada firewall penyedia, atau DNS masih menghala ke pelayan lama. Oleh itu, panduan ini menghabiskan sebahagian besar masa untuk prasyarat, dan menamakan rentetan ralat tepat yang dipaparkan oleh setiap kesilapan.

Dua nota skop. Jika pelayan web anda ialah nginx, alirannya mempunyai bentuk yang sama tetapi pemalam dan konfigurasi berbeza, gunakan versi nginx bagi panduan ini sebaliknya. Dan jika perkara yang anda lindungi adalah untuk kegunaan dalaman sahaja, seperti panel pentadbir pada alamat peribadi atau kotak staging yang tidak dilawati orang lain, anda tidak memerlukan pihak berkuasa sijil sama sekali; sijil yang ditandatangani sendiri memerlukan kurang jentera dan berfungsi di luar talian.

Prasyarat, dan tiga punca kegagalan sebelum Certbot dijalankan

• Apache sudah pun menghidangkan tapak anda melalui HTTP biasa. Plugin Apache untuk Certbot menyunting tapak sedia ada; ia tidak mencipta tapak baharu. Jika anda bermula daripada VPS kosong, bina LAMP stack pada Ubuntu 24.04 terlebih dahulu kemudian kembali semula, panduan ini merupakan bab TLS yang tertinggal.
• Domain awam dengan rekod A pada alamat VPS anda. Cabaran HTTP-01 Let's Encrypt bermaksud pelayan pengesahan mereka akan menyambung ke kotak anda dari internet: tiada homelab NAT tanpa port forward, tiada nama .local, dan tiada IP kosong. dig +short example.com mesti memulangkan alamat VPS anda, dan jika anda menukar DNS dalam tempoh sejam yang lalu, tunggu sehingga TTL rekod lama tamat sebelum melakukan pengeluaran sijil.
• Jika rekod AAAA wujud, ia mestilah tepat. Let's Encrypt lebih mengutamakan IPv6 apabila rekod AAAA diterbitkan, jadi rekod AAAA yang lapuk akan menyebabkan pengesahan gagal walaupun curl daripada komputer riba anda, yang mungkin menggunakan IPv4, berfungsi dengan baik. Terbitkan rekod 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 mengesahkan melalui port 80 secara khusus; anda tidak boleh menjalankan ini dengan port 443 sahaja.

sudo ufw allow "Apache Full"
sudo ufw status

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

Snap atau apt untuk Certbot? Pada 24.04, apt akhirnya boleh digunakan

Certbot beralih kepada pengedaran snap beberapa tahun lalu atas sebab yang kukuh: pakej distro menjadi lapuk. Ubuntu 20.04 membekalkan Certbot 0.40 dan tidak pernah dikemas kini, menyebabkan pihak projek penat menyahpepijat ralat berusia lima tahun. Pada 24.04, sebab tersebut sudah tiada; arkib membekalkan Certbot 2.9.0, iaitu keluaran generasi semasa, dan unattended-upgrades memastikan ia sentiasa ditampal. Cadangan saya untuk OS ini: gunakan apt. Anda tidak perlu menggunakan daemon snapd, pemalam Apache dipasang dalam transaksi yang sama, dan pemasa pembaharuan disepadukan 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 ialah pemalam yang membaca dan menyunting konfigurasi Apache anda; tanpanya, 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 paling baharu pada hari ia dikeluarkan, atau anda memerlukan pemalam DNS yang hanya diedarkan sebagai snap (beberapa pemalam penyedia 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

Walau apa pun pilihan anda, jangan sekali-kali menjalankan kedua-duanya. Dua pemasangan bermakna dua penjadual pembaharuan yang akan bertembung pada /etc/letsencrypt, dan certbot yang ditemui oleh shell anda dalam PATH mungkin bukan yang menguruskan sijil anda. Baris apt remove di atas bukanlah hiasan pilihan.

Vhost yang disunting oleh Certbot mesti sedia ada, ServerName adalah kunci utama

certbot --apache berfungsi dengan mencari virtual host port-80 yang ServerName atau ServerAlias miliknya sepadan dengan setiap domain -d yang anda berikan, membuktikan kawalan ke atas domain tersebut melaluinya, kemudian menulis pasangan SSL bagi vhost tersebut. Tanpa ServerName yang sepadan, tiada padanan akan ditemui, dan 000-default.conf lalai Ubuntu didatangkan dengan ServerName yang diletakkan dalam komen. Baris yang dikomen itu merupakan punca paling kerap mengapa satu arahan besar dalam panduan ini gagal.

Oleh itu, sebelum menyentuh Certbot, berikan tapak tersebut nama 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 bahawa Apache menghuraikan 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 turut memaparkan AH00558: apache2: Could not reliably determine the server's fully qualified domain name, itu hanyalah amaran mengenai ServerName global, bukan vhost anda, ia tidak berbahaya di sini dan boleh disenyapkan dengan 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 mahukan 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.

Issue the certificate: certbot --apache

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

First run asks three things: an email address (used for your ACME account and urgent CA notices; Let's Encrypt no longer sends expiry warnings, so monitoring renewals is on you), agreement to the Let's Encrypt terms, and whether to share your email with the EFF. There is no redirect question anymore: since Certbot 2.0 the Apache installer redirects HTTP to HTTPS by default, which is what you want. Pass --no-redirect if you genuinely need plain HTTP to keep serving content.

Success looks like this, and you should read it rather than skim it:

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

Behind that message Certbot did four things: enabled Apache's ssl module if it was not already, wrote example.com-le-ssl.conf, a copy of your vhost on *:443 with SSLEngine on and the certificate paths, enabled it, and added a RewriteRule block to the original port-80 vhost that 301s everything to HTTPS. Your original vhost file is edited, not replaced, and the SSL twin sits beside it where you can read every line it added.

Lokasi sebenar sijil dan sebab anda tidak boleh menyalinnya

Segala-galanya disimpan di bawah /etc/letsencrypt/live/example.com/: fullchain.pem (sijil berserta 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 bahagian tersebut secara berasingan. Fail-fail ini merupakan symlink ke /etc/letsencrypt/archive/, dan pengantaraan tersebut adalah mekanisme pembaharuan: proses pembaharuan menulis fail baharu ke dalam archive/ dan mengubah hala symlink tersebut. Halakan mana-mana perisian lain ke laluan live/ supaya ia menerima pembaharuan secara automatik; jika anda menyalin fail tersebut ke tempat lain, anda akan menyebabkan gangguan perkhidmatan selepas 90 hari.

Satu lagi fail yang perlu diketahui ialah /etc/letsencrypt/renewal/example.com.conf, yang merekodkan cara sijil ini dikeluarkan, authenticator = apache, installer = apache, serta domain yang terlibat, supaya pembaharuan boleh mengulangi proses tersebut tanpa pengawasan, termasuk memuat semula Apache selepas itu.

Pembaharuan sudah dijadualkan, sahkan ia, jangan bina semula

Sijil Let’s Encrypt bertahan selama 90 hari mengikut reka bentuk, dan pakej apt telah pun memasang mekanismenya: satu pemasa systemd yang menjalankan Certbot dua kali sehari pada waktu rawak, memperbaharui mana-mana sijil dalam tempoh 30 hari sebelum tamat tempoh. Jangan tambah cron job tambahan; penjadual kedua tidak memberikan apa-apa selain gangguan log dan pendedahan kepada had kadar (rate-limit).

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

Perintah pertama menunjukkan pemasa aktif, dengan waktu NEXT dalam tempoh 24 jam akan datang. Jadualnya adalah dua kali sehari dengan lengah rawak, jadi waktu tepatnya sengaja dibuat tidak dapat diramal (pada pemasangan snap, pemasa tersebut ialah snap.certbot.renew.timer). Ujian kering (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 ujian kering gagal, pembaharuan sebenar dalam masa ~60 hari akan gagal dengan cara yang sama. Selesaikan sekarang, sementara sijil semasa masih mempunyai tempoh hayat yang panjang. Punca biasa ialah peraturan firewall yang ditambah selepas pengeluaran sijil yang menutup semula port 80.

Sahkan dengan curl, dan apa yang sepatutnya 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

Perintah pertama sepatutnya memulangkan HTTP/1.1 301 Moved Permanently dengan header Location: https://example.com/, iaitu lencongan (redirect) yang dipasang oleh Certbot. Perintah kedua sepatutnya memulangkan HTTP/1.1 200 OK tanpa sebarang aduan TLS daripada curl. Perintah ketiga mencetak pengeluar (issuer), baris O = Let's Encrypt dengan CN ringkas seperti R12 atau E7, dan notAfter kira-kira 90 hari dari sekarang. Dalam pelayar web, anda akan melihat ikon mangga, dan klik padanya akan memaparkan pengeluar yang sama. Jika curl berfungsi tetapi pelayar web memberi amaran, anda hampir pasti melihat halaman yang disimpan dalam cache atau hostname yang salah, bukannya masalah sijil.

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

Kedua-duanya berfungsi; proses pembaharuan adalah sama. Bagi tapak yang tidak berkaitan pada pelayan yang sama, jalankan arahan pengeluaran 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.

Bagi satu tapak dengan beberapa nama, letakkan kesemuanya 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 akan mengesan perubahan set domain, meminta anda mengesahkan pengembangan tersebut, dan menggantikan sijil di lokasi asal, iaitu laluan live/ yang sama, jadi tiada bahagian lain yang perlu diubah. Perlu diingat bahawa senarai tersebut adalah penggantian, bukan penambahan: jika anda tidak menyertakan www dalam arahan tersebut, sijil baharu akan menggugurkan domain itu tanpa sebarang amaran.

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

HTTP-01 tidak boleh mengeluarkan *.example.com, meletakkan fail pada pelayan web hanya membuktikan kawalan ke atas satu hostname, bukan keseluruhan ruang nama. Wildcard memerlukan cabaran DNS-01: Certbot menetapkan rekod TXT pada _acme-challenge.example.com, yang secara praktikalnya bermaksud pemalam certbot-dns-* dengan kelayakan API untuk pembekal DNS anda, atau menyunting rekod TXT secara manual pada setiap pembaharuan dengan --manual (sangat menyusahkan, jangan jadikan ini sebagai rancangan). Panduan lengkap, daripada mekanik rekod TXT sehingga pemalam 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 kesemua empat adalah lebih mudah daripada wildcard dan tidak memerlukan kunci API DNS disimpan pada pelayan.

Mod kegagalan, berserta 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')

Pemalam tersebut menjalankan configtest sebelum mengubah apa-apa dan akan berhenti jika Apache sendiri bermasalah. \n adalah literal kerana Certbot mencetak repr pengecualian tersebut. Jalankan sudo apache2ctl configtest sendiri: ia akan menamakan fail dan baris yang bermasalah, biasanya disebabkan oleh kesilapan taip semasa penyuntingan manual, SSLCertificateFile yang menghala ke laluan yang tidak lagi wujud, atau modul yang dirujuk tetapi tidak didayakan. Betulkan 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 missing-ServerName yang disebut sebelum ini, dikesan semasa proses pengeluaran sijil. Certbot mencari setiap vhost port 80 yang didayakan untuk ServerName/ServerAlias yang sepadan dengan -d anda dan tidak menemui apa-apa. sudo apache2ctl -S menunjukkan perkara yang sebenarnya dihalakan oleh Apache; tambah baris ServerName ke vhost yang betul, muat semula, dan cuba lagi. Masalah yang hampir sama ialah pengesahan sampai ke vhost yang salah, respons cabaran kembali sebagai Invalid response ... 404 kerana tapak lain telah menangkap permintaan tersebut. Diagnosis yang sama, alat yang sama: apache2ctl -S.

Pengesahan tamat masa (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, dikonfigurasikan dalam panel pengehosan), set peraturan ufw yang hanya membenarkan 443 atau hanya SSH, DNS masih menghala ke pelayan lama, atau masalah stale-AAAA, di mana pelayan mereka mencuba IPv6 tetapi pelayan anda hanya menjawab pada IPv4. Uji dari luar VPS: curl -I http://example.com daripada komputer riba anda akan menghasilkan semula apa yang dilihat oleh pengesah mereka.

Anda mencuba berkali-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 pengesahan gagal bagi setiap nama hos bagi setiap akaun dalam satu jam. Sejak rombakan had kadar tahun 2025 mereka, ia berfungsi seperti baldi yang diisi semula, memperoleh semula kira-kira satu percubaan setiap 12 minit. Melakukan percubaan berulang kali terhadap firewall yang rosak akan menghabiskan had tersebut dengan cepat. Menunggu adalah satu cara, tetapi penyelesaian sebenar adalah dari segi 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, dan bentuk certbot --apache --dry-run kosong enggan berjalan sama sekali, 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 perintah sebenar setelah staging berjaya. Had lain, iaitu 50 sijil bagi setiap domain berdaftar seminggu, dan 5 pendua bagi set nama yang sama seminggu, hanya akan ditemui jika skrip mengeluarkan semula sijil dalam gelung.

Setelah HTTPS aktif, ingat bahawa sijil tersebut menjamin pengangkutan, bukan pelayan: port 22 masih menerima tekaan kata laluan sepanjang hari. Menggabungkan ini dengan Fail2ban pada Ubuntu 24.04 adalah langkah seterusnya yang wajar untuk dilakukan dalam masa tiga puluh minit.

FAQ

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

Gunakan apt. Ubuntu 24.04 membekalkan Certbot 2.9.0, yang cukup terkini untuk semua keperluan dalam panduan ini, menerima tampalan keselamatan melalui unattended-upgrades, dan tidak memerlukan snapd. Pilih snap hanya jika anda memerlukan keluaran terbaharu dengan segera atau pemalam DNS yang diedarkan secara eksklusif sebagai snap. Jika anda bertukar, apt remove certbot python3-certbot-apache dahulu supaya dua penjadual pembaharuan tidak wujud serentak.

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

Ini kerana tiada vhost port 80 yang diaktifkan mempunyai ServerName atau ServerAlias yang sepadan dengan domain yang anda berikan melalui -d. Vhost lalai Ubuntu dibekalkan dengan ServerName yang diletakkan dalam komen. Jalankan sudo apache2ctl -S, cari (atau cipta) vhost yang sepatutnya memiliki nama tersebut, tambahkan ServerName example.com, muat semula Apache, dan jalankan semula Certbot.

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

Let's Encrypt tidak dapat mencapai port 80 pada alamat yang diterbitkan oleh DNS anda. Semak firewall rangkaian pada peringkat panel pembekal anda serta ufw, sahkan dig +short example.com mengembalikan VPS ini, dan padam atau betulkan sebarang rekod AAAA yang lapuk kerana pengesahan lebih mengutamakan IPv6 jika ia wujud. Sahkan pembaikan dari luar pelayan dengan curl -I http://example.com, kemudian buat 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 sebarang sijil dalam tempoh 30 hari sebelum tamat tempoh, kemudian memuat semula Apache; snap menggunakan snap.certbot.renew.timer untuk tugas yang sama. Sahkan dengan systemctl list-timers certbot.timer dan buat latihan dengan sudo certbot renew --dry-run, jangan tambah cron job anda sendiri di atasnya.

Bagaimanakah cara mendapatkan sijil wildcard dengan Certbot dan Apache?

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