Instalacja Certbot dla Apache na Ubuntu 24.04

Co budujesz

Witryna Apache na systemie Ubuntu 24.04, odpowiadająca przez HTTPS z darmowym, zaufanym przez przeglądarki certyfikatem Let's Encrypt. Certyfikat jest wystawiany przez Certbot i automatycznie odnawiany przez timer systemd, co eliminuje potrzebę ręcznej obsługi. Cały proces sprowadza się do wykonania jednego polecenia. Wszystkie potencjalne problemy występują przed uruchomieniem tego polecenia: wirtualny host bez ServerName, port 80 zablokowany przez firewall dostawcy lub rekordy DNS wskazujące na stary serwer. Dlatego ten przewodnik skupia się głównie na warunkach wstępnych i wskazuje dokładne komunikaty błędów generowane przez poszczególne pomyłki.

Dwie uwagi dotyczące zakresu. Jeśli używasz serwera WWW nginx, schemat działania jest podobny, ale wtyczka oraz pliki konfiguracyjne różnią się; skorzystaj wówczas z wersji tego przewodnika dla nginx. Jeśli zabezpieczasz usługę dostępną wyłącznie wewnętrznie, panel administracyjny w sieci prywatnej lub środowisko testowe, do którego nikt inny nie ma dostępu, urząd certyfikacji nie jest potrzebny; certyfikat z podpisem własnym wymaga mniej konfiguracji i działa w trybie offline.

Wymagania wstępne oraz trzy przyczyny niepowodzenia przed uruchomieniem Certbot

• Apache już obsługuje witrynę przez zwykłe HTTP. Wtyczka Apache dla Certbot modyfikuje istniejącą konfigurację witryny; nie tworzy jej od podstaw. W przypadku czystego serwera VPS należy najpierw skonfigurować stos LAMP na Ubuntu 24.04, a następnie powrócić do tego przewodnika, który stanowi brakujący rozdział dotyczący TLS.
• Publiczna domena z rekordem A wskazującym na adres VPS. Wyzwanie HTTP-01 stosowane przez Let’s Encrypt wymaga, aby serwery walidacyjne łączyły się z serwerem z Internetu: nie zadziała to w środowisku domowym za NAT bez przekierowania portów ani w przypadku nazw .local. HTTP-01 pozwala na walidację adresu IP, jednak Let’s Encrypt wydaje certyfikaty dla adresów IP wyłącznie w ramach opcjonalnego profilu shortlived (z okresem ważności 160 godzin), a wersja Certbot 2.9.0 dostępna w apt nie obsługuje ani profili ACME, ani adresów IP, dlatego ten przewodnik wymaga posiadania nazwy domenowej. Rekord dig +short example.com musi wskazywać na adres VPS, a w przypadku zmiany ustawień DNS w ciągu ostatniej godziny należy odczekać na wygaśnięcie TTL starego rekordu przed próbą wydania certyfikatu.
• Jeśli istnieje rekord AAAA, musi być poprawny. Let’s Encrypt zawsze podejmuje próbę połączenia przez IPv6, jeśli opublikowano rekord AAAA. Jeśli połączenie przekroczy limit czasu, ponawia próbę przez IPv4, jednak żaden inny błąd nie skutkuje taką drugą szansą: rekord AAAA wskazujący na adres odrzucający połączenia lub na inny aktywny serwer powoduje niepowodzenie walidacji, nawet jeśli curl z poziomu laptopa (prawdopodobnie przez IPv4) działa poprawnie. Należy opublikować poprawny rekord AAAA lub usunąć go całkowicie.

Porty 80 oraz 443 muszą być otwarte w ufw oraz w zaporze sieciowej dostawcy; większość paneli hostingowych posiada drugą zaporę, której system operacyjny nie widzi. Walidacja HTTP-01 odbywa się konkretnie przez port 80; nie można uruchomić tego procesu wyłącznie na porcie 443.

sudo ufw allow "Apache Full"
sudo ufw status

Po spełnieniu tych warunków cały proces zajmuje piętnaście minut, z czego dziesięć poświęca się na lekturę.

Snap czy apt dla Certbot? W wersji 24.04 pakiet apt jest wreszcie odpowiedni

Projekt Certbot przeszedł na dystrybucję przez snap z istotnego powodu: pakiety dystrybucyjne stały się przestarzałe. Ubuntu 20.04 dostarczało Certbot 0.40 bez aktualizacji, a zespół projektowy przestał wspierać usuwanie błędów sprzed pięciu lat. W wersji 24.04 ten problem nie występuje, gdyż repozytorium zawiera Certbot 2.9.0, wydanie z lutego 2024 roku z nowoczesnej linii 2.x, a unattended-upgrades instaluje wszelkie poprawki bezpieczeństwa publikowane przez Ubuntu. Autorzy oprogramowania przeszli już na serię 5.x, jednak żadne z założeń tego poradnika jej nie wymaga. Rekomendacja dla tego systemu operacyjnego: należy użyć apt. Pozwala to pominąć demona snapd, wtyczka Apache instaluje się w tej samej transakcji, a harmonogram odnawiania integruje się z systemd w standardowy sposób dla systemu Debian.

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

Poprawny wynik: certbot 2.9.0. Pakiet python3-certbot-apache to wtyczka, która odczytuje i edytuje konfiguracje Apache; bez niej certbot --apache kończy się błędem The requested apache plugin does not appear to be installed.

Instalacja przez snap pozostaje właściwym wyborem w dwóch przypadkach: gdy wymagana jest najnowsza wersja Certbot w dniu premiery lub gdy potrzebna jest wtyczka DNS dostępna wyłącznie jako snap (dotyczy to wielu wtyczek dostawców certbot-dns-*). W takim przypadku należy wykonać:

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

Niezależnie od wyboru, nigdy nie należy uruchamiać obu metod jednocześnie. Dwie instalacje oznaczają dwa harmonogramy odnawiania rywalizujące o /etc/letsencrypt, a plik certbot wykryty przez powłokę w PATH może nie być tym, który zarządza certyfikatami. Linia apt remove powyżej nie jest opcjonalnym dodatkiem.

Wirtualne hosty edytowane przez Certbot muszą już istnieć, kluczowe znaczenie ma ServerName

certbot --apache działa poprzez wyszukiwanie wirtualnego hosta na porcie 80, którego ServerName lub ServerAlias odpowiada każdej domenie -d przekazanej w poleceniu. Narzędzie weryfikuje kontrolę nad domeną, a następnie tworzy bliźniaczą konfigurację SSL dla tego hosta. Brak pasującego wpisu ServerName uniemożliwia dopasowanie, a domyślny plik 000-default.conf w systemie Ubuntu zawiera zakomentowaną dyrektywę ServerName. Ta jedna zakomentowana linia jest najczęstszą przyczyną niepowodzenia głównego polecenia opisanego w tym przewodniku.

Zanim uruchomisz Certbot, skonfiguruj dla witryny poprawny wirtualny host oparty na nazwie. Utwórz plik /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>

Włącz go i potwierdź, że Apache poprawnie przetwarza konfigurację oraz kieruje ruch na odpowiednią nazwę:

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

Polecenie configtest musi zwrócić Syntax OK. Jeśli wyświetli również AH00558: apache2: Could not reliably determine the server's fully qualified domain name, jest to ostrzeżenie dotyczące globalnego parametru ServerName, a nie Twojego wirtualnego hosta; w tym przypadku jest ono nieistotne i można je wyciszyć za pomocą echo "ServerName $(hostname -f)" | sudo tee /etc/apache2/conf-available/servername.conf && sudo a2enconf servername && sudo systemctl reload apache2.

Dane wyjściowe -S stanowią najważniejszą weryfikację. Powinieneś zobaczyć linię typu port 80 namevhost example.com (/etc/apache2/sites-enabled/example.com.conf:1) z przypisanym do niej alias www.example.com. Apache raportuje dowiązanie symboliczne sites-enabled, które faktycznie zostało odczytane, a nie plik edytowany w sites-available. Jeśli example.com nie znajduje się na liście dla portu 80, Certbot również go nie odnajdzie.

Wystawienie certyfikatu: certbot --apache

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

Pierwsze uruchomienie wymaga podania trzech informacji: adresu e-mail (Let's Encrypt nie przechowuje go już w ramach konta ACME i nie wysyła powiadomień o wygaśnięciu, więc monitorowanie odnowień spoczywa na administratorze), zgody na warunki korzystania z Let's Encrypt oraz decyzji o udostępnieniu adresu e-mail organizacji EFF. Pytanie o przekierowanie nie jest już zadawane: od wersji 1.0 instalator Certbot dla Apache domyślnie przekierowuje ruch HTTP na HTTPS (samo pytanie usunięto w wersji 1.4), co jest pożądanym zachowaniem. Należy przekazać flagę --no-redirect, jeśli obsługa zwykłego HTTP jest niezbędna do serwowania treści.

Komunikat o sukcesie wygląda następująco i należy go przeczytać, zamiast pobieżnie przeglądać:

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 2027-01-09.

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

W tle tego komunikatu Certbot wykonał cztery operacje: włączył moduł ssl serwera Apache, jeśli nie był aktywny, utworzył plik example.com-le-ssl.conf, będący kopią wirtualnego hosta w lokalizacji *:443 z dyrektywami SSLEngine on oraz ścieżkami do certyfikatów, aktywował go, a także dodał blok RewriteRule do oryginalnego wirtualnego hosta na porcie 80, który przekierowuje cały ruch na HTTPS za pomocą kodu 301. Oryginalny plik wirtualnego hosta zostaje zmodyfikowany, a nie zastąpiony, natomiast jego odpowiednik SSL znajduje się obok, co pozwala na weryfikację każdej dodanej linii.

Gdzie faktycznie znajdują się certyfikaty i dlaczego nie należy ich kopiować

Wszystkie pliki trafiają do /etc/letsencrypt/live/example.com/: fullchain.pem (certyfikat wraz z łańcuchem pośrednim, na który powinny wskazywać serwery), privkey.pem (klucz prywatny, dostępny tylko dla użytkownika root), oraz cert.pem i chain.pem dla oprogramowania wymagającego oddzielnych plików. Są to dowiązania symboliczne do /etc/letsencrypt/archive/, a ta pośredniość stanowi mechanizm odnawiania: proces odnawiania zapisuje nowe pliki w archive/ i aktualizuje dowiązania. Wskazanie dowolnego innego oprogramowania na ścieżki live/ pozwala na automatyczne pobieranie odnowionych certyfikatów; skopiowanie plików w inne miejsce spowoduje awarię po upływie 90 dni.

Innym istotnym plikiem jest /etc/letsencrypt/renewal/example.com.conf, który rejestruje sposób wydania certyfikatu, authenticator = apache, installer = apache oraz nazwy domen, dzięki czemu proces odnawiania może być powtarzany bez nadzoru, włącznie z przeładowaniem serwera Apache po zakończeniu operacji.

Odnowienie jest już zaplanowane, zweryfikuj je, nie twórz własnego

Certyfikaty Let’s Encrypt są domyślnie ważne przez 90 dni, a pakiet apt zainstalował już odpowiedni mechanizm: timer systemd, który uruchamia Certbot dwa razy dziennie o losowych porach, odnawiając każdy certyfikat, któremu pozostało mniej niż 30 dni do wygaśnięcia. Nie należy dodawać dodatkowego zadania cron; drugi harmonogram generuje jedynie niepotrzebne wpisy w logach i ryzyko przekroczenia limitów zapytań (rate-limit). Organizacja Let’s Encrypt ogłosiła, że od 10 lutego 2027 roku nowe certyfikaty będą miały domyślny okres ważności wynoszący 64 dni. Okno 30-dniowe pozostaje w pełni funkcjonalne, odnowienie nastąpi po prostu około 34. dnia zamiast 60., więc na tym serwerze nie trzeba wprowadzać żadnych zmian.

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

Pierwsze polecenie pokazuje aktywny timer z czasem NEXT przypadającym w ciągu najbliższych 24 godzin. Harmonogram przewiduje uruchomienie dwa razy dziennie z losowym opóźnieniem, więc dokładny czas jest celowo nieprzewidywalny (w przypadku instalacji snap timer nazywa się snap.certbot.renew.timer). Testowe uruchomienie (dry run) wykonuje pełną próbę odnowienia w środowisku testowym (staging) Let’s Encrypt; wyzwanie jest prawdziwe, ale certyfikat nie jest wystawiany i nie obciąża limitów. Prawidłowy wynik kończy się komunikatem:

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

Jeśli testowe uruchomienie zakończy się niepowodzeniem, właściwe odnowienie za około 60 dni również zakończy się błędem. Należy usunąć przyczynę teraz, gdy obecny certyfikat ma jeszcze pełny okres ważności. Najczęstszą przyczyną jest reguła firewalla dodana po wystawieniu certyfikatu, która ponownie zablokowała port 80.

Weryfikacja za pomocą curl i opis poprawnego certyfikatu

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

Pierwsze polecenie powinno zwrócić HTTP/1.1 301 Moved Permanently wraz z nagłówkiem Location: https://example.com/, co oznacza przekierowanie skonfigurowane przez Certbot. Drugie polecenie powinno zwrócić HTTP/1.1 200 OK bez żadnych ostrzeżeń TLS ze strony curl. Trzecie polecenie wyświetla wystawcę, linię O = Let's Encrypt z krótką nazwą CN, taką jak YE1 lub YE2 (klucze ECDSA) albo YR1 lub YR2 (klucze RSA), oraz notAfter z datą wygaśnięcia za około 90 dni. Certyfikat wystawiony przed wycofaniem przez Let's Encrypt starszych certyfikatów pośrednich może nadal wyświetlać CN typu R12 lub E7 aż do momentu kolejnego odnowienia; nie jest to błąd. W przeglądarce widoczna jest ikona kłódki, a po jej kliknięciu wyświetlany jest ten sam wystawca. Jeśli curl działa poprawnie, a przeglądarka zgłasza ostrzeżenie, przyczyną jest niemal na pewno pamięć podręczna strony lub błędna nazwa hosta, a nie problem z certyfikatem.

Wiele witryn: jeden certyfikat SAN lub jeden certyfikat na witrynę

Oba rozwiązania działają i odnawiają się w ten sam sposób. W przypadku niepowiązanych witryn na tym samym serwerze należy uruchomić polecenie wydania certyfikatu raz dla każdej witryny. Każda z nich otrzyma własny katalog w live/ oraz własną konfigurację odnawiania, dzięki czemu problem z jedną domeną nigdy nie zablokuje odnawiania pozostałych. Jest to ustawienie domyślne.

W przypadku jednej witryny z wieloma nazwami należy umieścić je na jednym certyfikacie SAN; pojedynczy certyfikat może zawierać do 100 nazw. Zostało to już wykonane powyżej przy użyciu example.com oraz www.example.com. Aby dodać nazwę do istniejącego certyfikatu w późniejszym czasie, należy ponownie wydać polecenie, podając nazwę certyfikatu oraz pełną nową listę:

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

Certbot wykryje zmieniony zestaw domen, poprosi o potwierdzenie rozszerzenia i zastąpi certyfikat w tej samej lokalizacji, zachowując ścieżkę live/, więc żadne inne elementy nie wymagają modyfikacji. Należy pamiętać, że lista stanowi zastąpienie, a nie dopisanie: pominięcie www w tym poleceniu spowoduje, że nowy certyfikat po cichu usunie tę domenę.

Certyfikaty typu wildcard wymagają wyzwania DNS-01, a zazwyczaj nie są one potrzebne

Wyzwanie HTTP-01 nie pozwala na wydanie *.example.com, ponieważ umieszczenie pliku na serwerze WWW potwierdza kontrolę nad jedną nazwą hosta, a nie nad całą przestrzenią nazw. Certyfikaty typu wildcard wymagają wyzwania DNS-01: Certbot ustawia rekord TXT w _acme-challenge.example.com, co w praktyce oznacza użycie wtyczki certbot-dns-* z danymi uwierzytelniającymi API dostawcy DNS lub ręczną edycję rekordów TXT przy każdym odnowieniu za pomocą --manual (jest to uciążliwe i nie należy na tym polegać). Pełny opis procedury, od mechaniki rekordu TXT po wtyczkę umożliwiającą automatyczne odnawianie, znajduje się w certyfikaty wildcard z Certbot przez DNS-01. Szczera rada: jeśli posiadasz cztery znane subdomeny, certyfikat SAN zawierający wszystkie cztery jest prostszy w obsłudze niż wildcard i nie wymaga przechowywania kluczy API DNS na serwerze.

Tryby awarii i towarzyszące im komunikaty

Certbot odmawia uruchomienia z powodu błędnej konfiguracji 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')

Wtyczka uruchamia configtest przed wprowadzeniem jakichkolwiek zmian i przerywa działanie, jeśli Apache zgłasza błędy. Ciągi \n są dosłowne, ponieważ Certbot wyświetla reprezentację wyjątku. Uruchom samodzielnie sudo apache2ctl configtest: wskaże on plik oraz linię błędu, co zazwyczaj wynika z literówki przy ręcznej edycji, SSLCertificateFile wskazującego na nieistniejącą już ścieżkę lub odwołania do modułu, który nie został włączony. Popraw konfigurację, aż polecenie zwróci Syntax OK, a następnie uruchom Certbot ponownie.

Brak vhosta pasującego do domeny.

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

Jest to wspomniany wcześniej błąd braku ServerName, wykryty w momencie wystawiania certyfikatu. Certbot przeszukał wszystkie włączone vhosty na porcie 80 pod kątem ServerName/ServerAlias pasującego do Twojego -d i nie znalazł dopasowania. sudo apache2ctl -S pokazuje, jak Apache faktycznie kieruje ruch; dodaj linię ServerName do odpowiedniego vhosta, przeładuj konfigurację i spróbuj ponownie. Podobnym problemem jest sytuacja, w której walidacja trafia do niewłaściwego vhosta, a odpowiedź na wyzwanie zwraca Invalid response ... 404, ponieważ inny serwis przechwycił żądanie. Diagnostyka i narzędzie pozostają te same: apache2ctl -S.

Przekroczono czas oczekiwania na walidację.

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

Let's Encrypt nie mogło nawiązać połączenia TCP na porcie 80 pod adresem wskazywanym przez DNS. W kolejności prawdopodobieństwa: firewall sieciowy dostawcy (niezależny od ufw, konfigurowany w panelu hostingu), reguły ufw zezwalające tylko na ruch 443 lub tylko SSH, albo rekordy DNS wskazujące nadal na poprzedni serwer. Nieaktualny rekord AAAA zazwyczaj nie powoduje tego błędu, ponieważ po przekroczeniu czasu próby IPv6, Let's Encrypt ponawia połączenie przez IPv4; problemy z AAAA częściej objawiają się jako Connection refused lub Invalid response z niewłaściwego serwera. Przetestuj połączenie spoza VPS: curl -I http://example.com z laptopa pozwoli odtworzyć to, co widzi walidator.

Przekroczenie limitu zapytań wskutek zbyt częstych prób.

Error creating new order :: too many failed authorizations (5) for "example.com" in the last 1h0m0s, retry after ... UTC: see https://letsencrypt.org/docs/rate-limits/...

Let's Encrypt zezwala na 5 nieudanych walidacji na nazwę hosta na konto w ciągu godziny. Jest to mechanizm „wiadra”, które odzyskuje około jedną próbę co 12 minut, a wielokrotne ponawianie przy niedziałającym firewallu szybko wyczerpuje ten limit. Czekanie rozwiązuje problem, ale właściwym podejściem jest zmiana nawyków: po każdej awarii należy debugować konfigurację w środowisku staging, aż do uzyskania sukcesu.

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

Zwróć uwagę na certonly: --dry-run jest akceptowane tylko przez podkomendy certonly oraz renew, a sama forma certbot --apache --dry-run odmawia uruchomienia, wyświetlając --dry-run currently only works with the 'certonly' or 'renew' subcommands. Tryb dry run przeprowadza walidację w środowisku staging, które ma własne, łagodne limity i nie wystawia rzeczywistych certyfikatów, więc można tam testować przez cały dzień. Uruchom właściwe polecenie dopiero po pomyślnej walidacji w staging. Pozostałe limity, czyli 50 certyfikatów na zarejestrowaną domenę tygodniowo oraz 5 duplikatów tego samego zestawu nazw tygodniowo, zostaną osiągnięte tylko w przypadku skryptu zapętlonego w procesie ponownego wystawiania certyfikatów.

Gdy HTTPS jest już aktywny, pamiętaj, że certyfikat zabezpiecza transport, a nie sam serwer: port 22 jest nadal narażony na próby odgadnięcia hasła. Połączenie tego z Fail2ban na Ubuntu 24.04 to naturalny kolejny krok, który zajmie około trzydziestu minut.

FAQ

Czy na Ubuntu 24.04 należy zainstalować Certbot przez snap czy apt dla Apache?

Należy użyć apt. Ubuntu 24.04 dostarcza Certbot 2.9.0, co jest wersją wystarczającą dla wszystkich kroków w tym poradniku, otrzymuje aktualizacje bezpieczeństwa publikowane przez Ubuntu w ramach unattended-upgrades i nie wymaga snapd. Wybierz snap tylko wtedy, gdy natychmiast potrzebujesz najnowszego wydania lub wtyczki DNS dystrybuowanej wyłącznie jako snap. W przypadku zmiany metody instalacji, najpierw wykonaj apt remove certbot python3-certbot-apache, aby uniknąć współistnienia dwóch harmonogramów odnawiania certyfikatów.

Dlaczego Certbot zgłasza "Unable to find a virtual host listening on port 80"?

Ponieważ żaden aktywny vhost na porcie 80 nie posiada dyrektywy ServerName lub ServerAlias zgodnej z domeną przekazaną w -d, a domyślny vhost w Ubuntu ma ServerName w komentarzu. Uruchom sudo apache2ctl -S, znajdź lub utwórz vhost, który powinien obsługiwać tę nazwę, dodaj ServerName example.com, przeładuj Apache i uruchom ponownie Certbot.

Jak naprawić błąd "Timeout during connect (likely firewall problem)"?

Let's Encrypt nie uzyskał połączenia z portem 80 pod adresem wskazywanym przez DNS. Sprawdź sieciową zaporę ogniową w panelu dostawcy oraz ufw, potwierdź, że dig +short example.com zwraca adres tego VPS, a także popraw lub usuń nieaktualne rekordy AAAA, ponieważ walidacja najpierw próbuje IPv6 i dopiero po przekroczeniu czasu oczekiwania przechodzi na IPv4. Potwierdź poprawkę spoza serwera za pomocą curl -I http://example.com, a następnie wykonaj próbę z sudo certbot certonly --apache --dry-run -d example.com przed właściwym wydaniem certyfikatu.

Czy Certbot automatycznie odnawia certyfikaty na Ubuntu 24.04?

Tak. Pakiet apt instaluje certbot.timer, czyli timer systemd, który uruchamia się dwa razy dziennie i odnawia każdy certyfikat, któremu pozostało mniej niż 30 dni do wygaśnięcia, przeładowując po tym Apache; wersja snap używa do tego samego celu snap.certbot.renew.timer. Zweryfikuj stan za pomocą systemctl list-timers certbot.timer i wykonaj próbę z sudo certbot renew --dry-run; nie dodawaj własnych zadań cron.

Jak uzyskać certyfikat wildcard za pomocą Certbot i Apache?

Certyfikaty wildcard wymagają wyzwania DNS-01: Certbot musi umieścić rekord TXT w _acme-challenge.example.com, co wymaga wtyczki certbot-dns-* z danymi uwierzytelniającymi API dostawcy DNS (alternatywa --manual wymaga ręcznej edycji rekordów TXT przy każdym odnowieniu). Jeśli posiadasz tylko kilka znanych subdomen, certyfikat SAN z ich jawną listą jest prostszy i pozwala uniknąć przechowywania kluczy API DNS na serwerze.