Cara Pasang Certbot Apache di Ubuntu 24.04

Apa yang anda bina

Sebuah laman web 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 pembekal, atau DNS masih menghala ke pelayan lama. Oleh itu, panduan ini menghabiskan sebahagian besar masanya pada 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, 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 penyelenggaraan dan berfungsi di luar talian.

Prasyarat, dan tiga punca kegagalan sebelum Certbot dijalankan

• Apache sudah pun menghidangkan laman anda melalui HTTP biasa. Plugin Apache Certbot menyunting laman sedia ada; ia tidak mencipta laman baharu. Jika anda bermula dengan 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 dari 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 perkara tersebut disediakan, keseluruhan tugas 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 mengemas kininya, manakala pihak projek sudah penat menyahpepijat pepijat 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, plugin 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 plugin 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 plugin DNS yang hanya diedarkan sebagai snap (beberapa plugin 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 sesekali jalankan kedua-duanya. Dua pemasangan bermakna dua penjadual pembaharuan yang akan bertembung untuk /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 mestilah sudah wujud, 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 masukkan, membuktikan kawalan ke atas domain tersebut melaluinya, kemudian menulis pasangan SSL bagi vhost tersebut. Tiada ServerName yang sepadan bermakna tiada padanan, 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 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 menghuraikannya serta menghalakan nama tersebut kepadanya:

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

configtest mestilah 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 dibacanya, bukan fail yang anda sunting dalam sites-available. Jika example.com tidak disenaraikan pada port 80, Certbot juga tidak akan menemuinya.

Terbitkan sijil: certbot --apache

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

Permulaan pertama meminta tiga perkara: alamat e-mel (digunakan untuk akaun ACME anda dan notis penting CA; Let's Encrypt tidak lagi menghantar amaran tamat tempoh, jadi pemantauan pembaharuan adalah tanggungjawab anda), persetujuan terhadap terma Let's Encrypt, dan sama ada untuk berkongsi e-mel anda dengan EFF. Tiada lagi soalan mengenai pengalihan (redirect): sejak Certbot 2.0, pemasang Apache akan mengalihkan HTTP ke HTTPS secara lalai, iaitu tetapan yang anda perlukan. Gunakan --no-redirect jika anda benar-benar memerlukan HTTP biasa untuk terus menghidangkan kandungan.

Pengenalan kepada Reverse Proxy

Reverse proxy dengan TLS termination memudahkan self-hosting apabila beberapa aplikasi berkongsi satu pelayan dan satu alamat IP awam. Daripada setiap aplikasi membuka port sendiri serta mengurus sijil HTTPS masing-masing, Nginx, Caddy atau Traefik menerima trafik pada port 80 dan 443 lalu menghala permintaan mengikut hostname atau path, contohnya git.example.com ke Gitea dan cloud.example.com ke Nextcloud. Sijil Let’s Encrypt boleh diperbaharui secara berpusat, manakala aplikasi dalaman hanya perlu mendengar pada localhost atau rangkaian Docker peribadi. Ini mengurangkan pendedahan port, memudahkan firewall dan mengelakkan konfigurasi TLS berulang. Reverse proxy juga menyediakan satu lokasi untuk menetapkan HTTP security headers, redirect HTTP ke HTTPS, rate limiting, access log, basic authentication dan WebSocket forwarding. Apabila perlu menambah aplikasi baharu, pentadbir biasanya hanya mencipta DNS record serta virtual host atau router baharu tanpa mengubah konfigurasi rangkaian asas pelayan.

Penyelesaian Masalah Servis

Jika sesuatu servis tidak mahu bermula selepas reboot, semak dahulu status unit dan log systemd, bukan terus mengubah fail konfigurasi. Jalankan systemctl status nama-servis untuk melihat exit code, mesej ralat ringkas dan sama ada unit gagal kerana dependency, permission atau konfigurasi tidak sah. Seterusnya gunakan journalctl -u nama-servis -b untuk membaca log bagi boot semasa; parameter -b penting kerana ia menapis mesej lama. Periksa juga sama ada servis memang diaktifkan dengan systemctl is-enabled nama-servis, serta sama ada dependency seperti network, database atau fail sistem sudah sedia ada.

FAQ

Adakah saya perlu membuka port 80 dan 443 pada firewall?

Ya, anda perlu membenarkan trafik masuk pada port 80 dan 443 untuk membolehkan reverse proxy menerima permintaan daripada internet.

Bolehkah saya menggunakan reverse proxy untuk aplikasi bukan web?

Boleh, tetapi anda perlu menggunakan stream module atau TCP/UDP forwarding jika aplikasi tersebut tidak menggunakan protokol HTTP.

Adakah TLS termination selamat?

Ya, ia selamat selagi trafik antara reverse proxy dan aplikasi dalaman berada dalam rangkaian yang dipercayai atau disulitkan melalui VPN/WireGuard.

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: mendayakan modul ssl Apache jika ia belum didayakan, menulis example.com-le-ssl.conf, iaitu salinan vhost anda pada *:443 dengan SSLEngine on serta laluan sijil, mendayakannya, dan menambah blok RewriteRule pada vhost port-80 asal yang melakukan 301 untuk semua trafik ke HTTPS. Fail vhost asal anda disunting, bukannya diganti, dan pasangan SSL tersebut diletakkan di sebelahnya supaya anda boleh membaca setiap baris yang ditambah.

Lokasi sebenar sijil dan sebab anda tidak boleh menyalinnya

Semua fail 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 mendapat kemas kini 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 memuatkan semula Apache selepas itu.

Pembaharuan sudah dijadualkan, sahkan ia, jangan bina semula

Sijil Let’s Encrypt direka untuk bertahan selama 90 hari, dan pakej apt telah memasang mekanismenya: pemasa systemd yang menjalankan Certbot dua kali sehari pada waktu rawak, memperbaharui mana-mana sijil yang mempunyai tempoh kurang daripada 30 hari sebelum tamat. Jangan tambah cron job tambahan; penjadual kedua tidak memberikan apa-apa faedah selain gangguan log dan risiko 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 kelewatan rawak, jadi waktu tepatnya sengaja dibuat tidak dapat diramal (pada pemasangan snap, pemasa tersebut adalah snap.certbot.renew.timer). Ujian dry run melakukan simulasi pembaharuan penuh terhadap persekitaran staging Let’s Encrypt, menggunakan cabaran sebenar, tanpa sijil dikeluarkan, dan tanpa 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 masa ~60 hari akan gagal dengan cara yang sama. Selesaikan masalah 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 maklumat yang dipaparkan pada 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 mengembalikan HTTP/1.1 301 Moved Permanently dengan pengepala Location: https://example.com/, iaitu lenalaan (redirect) yang dipasang oleh Certbot. Perintah kedua sepatutnya mengembalikan HTTP/1.1 200 OK tanpa sebarang ralat TLS daripada curl. Perintah ketiga memaparkan pengeluar sijil, baris O = Let's Encrypt dengan CN ringkas seperti R12 atau E7, dan notAfter yang tamat tempoh kira-kira 90 hari lagi. Dalam pelayar web, anda akan melihat ikon mangga, dan klik pada ikon tersebut akan memaparkan pengeluar yang sama. Jika curl berfungsi tetapi pelayar web memberi amaran, anda hampir pasti melihat halaman yang disimpan dalam cache atau nama hos 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 dalam 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 pengesahan anda untuk melakukan pengembangan, dan menggantikan sijil tersebut di lokasi asal. Laluan live/ kekal sama, jadi tiada bahagian lain yang perlu diubah. Perhatikan 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 perlukan wildcard

HTTP-01 tidak boleh mengeluarkan *.example.com, kerana meletakkan fail pada pelayan web hanya membuktikan kawalan ke atas satu nama hos, bukan keseluruhan ruang nama. Wildcard memerlukan cabaran DNS-01: Certbot menetapkan rekod TXT pada _acme-challenge.example.com, yang secara praktikalnya bermaksud penggunaan pemalam certbot-dns-* dengan kelayakan API untuk pembekal DNS anda, atau menyunting rekod TXT secara manual pada setiap pembaharuan dengan --manual (proses yang sukar, jangan jadikan ini sebagai perancangan). Panduan lengkap, daripada mekanik rekod TXT sehingga pemalam yang melakukan pembaharuan tanpa pengawasan, terdapat dalam sijil wildcard dengan Certbot melalui DNS-01. Nasihat jujur: jika anda mempunyai empat subdomain yang diketahui, sijil SAN yang menyenaraikan kesemua empat subdomain 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 ini menjalankan configtest sebelum menyentuh 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. 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 ServerName yang hilang seperti yang dibincangkan 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; tambahkan 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.

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 yang masih menghala ke pelayan lama, atau masalah AAAA yang lapuk, di mana pelayan mereka mencuba IPv6, manakala 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.

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 tempoh sejam. Sejak rombakan had kadar 2025 mereka, ia menggunakan sistem baldi yang diisi semula, memperoleh semula kira-kira satu percubaan setiap 12 minit. Mencuba berulang kali terhadap firewall yang rosak akan menghabiskan had ini dengan cepat. Menunggu memang berkesan, 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, dan jika anda bertukar, apt remove certbot python3-certbot-apache dahulu supaya dua penjadual pembaharuan tidak wujud serentak.

Mengapa 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 membekalkan ServerName dalam bentuk komen. 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 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 sampingnya.

Bagaimanakah cara untuk 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 segelintir subdomain yang diketahui, sijil SAN yang menyenaraikannya secara eksplisit adalah lebih mudah dan memastikan kunci API DNS tidak berada pada pelayan.