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ły HTTP. Wtyczka Apache dla Certbot modyfikuje istniejącą konfigurację witryny; nie tworzy jej od podstaw. Jeśli korzystasz z czystego VPS, najpierw skonfiguruj stos LAMP na Ubuntu 24.04, a następnie wróć 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 od Let’s Encrypt wymaga, aby ich serwery weryfikacyjne mogły połączyć się z Twoim serwerem z Internetu: nie zadziała to w środowisku homelab za NAT bez przekierowania portów, nie zadziała z nazwami .local ani z samymi adresami IP. Rekord dig +short example.com musi zwracać adres Twojego VPS. Jeśli w ciągu ostatniej godziny wprowadzono zmiany w DNS, przed wystawieniem certyfikatu należy odczekać na wygaśnięcie TTL starego rekordu.
• Jeśli istnieje rekord AAAA, musi być poprawny. Let’s Encrypt preferuje IPv6, jeśli opublikowano rekord AAAA. Nieaktualny rekord AAAA spowoduje niepowodzenie weryfikacji, nawet jeśli polecenie curl z Twojego laptopa (prawdopodobnie korzystającego z IPv4) działa poprawnie. Opublikuj poprawny rekord AAAA lub usuń go całkowicie.

Porty 80 oraz 443 muszą być otwarte w ufw oraz w zaporze sieciowej dostawcy usług (większość paneli hostingowych posiada drugą warstwę zapory, niewidoczną dla systemu operacyjnego). Wyzwanie HTTP-01 jest weryfikowane wyłącznie przez port 80; nie można przeprowadzić tego procesu, używając tylko portu 443.

sudo ufw allow "Apache Full"
sudo ufw status

Przy spełnieniu powyższych warunków cały proces zajmie piętnaście minut, z czego dziesięć poświęcisz na czytanie.

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

Projekt Certbot przeszedł na dystrybucję snap lata temu z istotnego powodu: pakiety dystrybucyjne ulegały przedawnieniu. Ubuntu 20.04 dostarczało Certbot 0.40 bez aktualizacji, a zespół projektu musiał diagnozować błędy sprzed pięciu lat. W wersji 24.04 ten problem nie występuje, gdyż repozytoria zawierają Certbot 2.9.0, czyli wydanie bieżącej generacji, a unattended-upgrades dba o poprawki bezpieczeństwa. Rekomendacja dla tego systemu operacyjnego: należy użyć apt. Pozwala to uniknąć demona snapd, wtyczka Apache instaluje się w tej samej transakcji, a harmonogram odnawiania integruje się z systemd w standardowy dla Debiana sposób.

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 używać 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 (używanego do konta ACME oraz pilnych powiadomień CA; Let's Encrypt nie wysyła już ostrzeżeń o wygasaniu, więc monitorowanie odnowień spoczywa na administratorze), zgody na warunki Let's Encrypt oraz decyzji o udostępnieniu adresu e-mail organizacji EFF. Pytanie o przekierowanie nie jest już zadawane: od wersji Certbot 2.0 instalator Apache domyślnie przekierowuje ruch HTTP na HTTPS, co jest pożądanym zachowaniem. Należy przekazać flagę --no-redirect, jeśli zachodzi rzeczywista potrzeba serwowania treści przez zwykły protokół HTTP.

Pomyślne zakończenie operacji wygląda następująco i należy zapoznać się z jego treścią, zamiast pobieżnego przeglądania:

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

Za tym komunikatem 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 *:443 wraz z dyrektywami SSLEngine on i ścieżkami do certyfikatów, włączył go oraz dodał blok RewriteRule do oryginalnego wirtualnego hosta na porcie 80, który przekierowuje cały ruch za pomocą kodu 301 na HTTPS. Oryginalny plik wirtualnego hosta jest edytowany, a nie zastępowany, 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 go ponownie

Certyfikaty Let’s Encrypt są z założenia 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 ważności. Nie należy dodawać dodatkowego zadania cron; drugi harmonogram nie wnosi żadnej wartości, generuje jedynie niepotrzebne wpisy w logach i ryzyko przekroczenia limitów zapytań.

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 dwa uruchomienia 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 staging Let’s Encrypt; wyzwanie jest prawdziwe, ale certyfikat nie jest wystawiany i nie zużywa limitów. Poprawny 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ż się nie powiedzie. 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 zamknęł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 R12 lub E7, oraz datę notAfter przypadającą za około 90 dni. W przeglądarce widoczna jest ikona kłódki, a po jej kliknięciu wyświetlają się dane tego samego wystawcy. 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 ono plik i linię, w której wystąpił błąd – zazwyczaj jest to literówka powstała podczas ręcznej edycji, SSLCertificateFile wskazujący na nieistniejącą ścieżkę lub odwołanie do nieaktywnego modułu. Usuń błędy, aż polecenie zwróci Syntax OK, a następnie uruchom ponownie Certbot.

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 aktywne vhosty na porcie 80 w poszukiwaniu ServerName/ServerAlias odpowiadającego Twojemu -d i nie znalazł dopasowania. sudo apache2ctl -S pokazuje, jak Apache faktycznie kieruje ruch; dodaj linię ServerName do właściwego vhosta, przeładuj konfigurację i spróbuj ponownie. Częstym przypadkiem jest sytuacja, w której weryfikacja trafia do niewłaściwego vhosta, a odpowiedź na wyzwanie zwraca Invalid response ... 404, ponieważ żądanie przechwyciła inna witryna. Diagnoza i narzędzie są takie same: apache2ctl -S.

Przekroczenie czasu oczekiwania na weryfikację.

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. Najczęstsze przyczyny w kolejności prawdopodobieństwa: firewall sieciowy dostawcy (niezależny od ufw, konfigurowany w panelu hostingu), reguły ufw zezwalające tylko na port 443 lub SSH, rekordy DNS wskazujące na poprzedni serwer lub problem ze starym rekordem AAAA, gdzie serwery weryfikacyjne próbowały połączyć się przez IPv6, podczas gdy serwer odpowiada tylko przez IPv4. Przetestuj połączenie z zewnątrz VPS: curl -I http://example.com z własnego laptopa odtworzy to, co widzi weryfikator.

Osiągnięcie limitu zapytań przez zbyt częste ponawianie prób.

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

Let's Encrypt zezwala na 5 nieudanych weryfikacji na nazwę hosta dla konta w ciągu godziny. Od czasu zmian w limitach w 2025 roku działa to na zasadzie „dopełniającego się wiadra”, odzyskując około jedną próbę co 12 minut. Wielokrotne ponawianie prób 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 użycie samego certbot --apache --dry-run kończy się odmową uruchomienia i komunikatem --dry-run currently only works with the 'certonly' or 'renew' subcommands. Tryb dry run weryfikuje konfigurację względem środowiska staging, które posiada własne, wysokie limity i nie wystawia rzeczywistych certyfikatów, dzięki czemu można testować bez ograniczeń. Dopiero po pomyślnej weryfikacji w staging uruchom właściwe polecenie. Pozostałe limity, takie jak 50 certyfikatów na zarejestrowaną domenę tygodniowo czy 5 duplikatów tego samego zestawu nazw tygodniowo, zostaną osiągnięte tylko w przypadku zapętlenia skryptu wystawiającego certyfikaty.

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 następne trzydzieści minut.

FAQ

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

Należy użyć apt. Ubuntu 24.04 dostarcza Certbot w wersji 2.9.0, która jest wystarczająco aktualna dla wszystkich zadań w tym przewodniku, otrzymuje poprawki bezpieczeństwa przez 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 usuń apt remove certbot python3-certbot-apache, aby dwa harmonogramy odnawiania nigdy nie działały jednocześnie.

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

Ponieważ żaden włączony vhost na porcie 80 nie posiada dyrektywy ServerName lub ServerAlias pasującej do domeny przekazanej za pomocą -d. Domyślny vhost w Ubuntu ma zakomentowaną dyrektywę ServerName. 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 mógł nawiązać połączenia z portem 80 pod adresem opublikowanym w DNS. Sprawdź sieciowy firewall w panelu dostawcy VPS oraz ufw, potwierdź, że dig +short example.com wskazuje na ten serwer, a następnie usuń lub popraw nieaktualne rekordy AAAA, ponieważ walidacja preferuje IPv6, jeśli jest dostępny. Potwierdź poprawkę z zewnątrz 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 działanie za pomocą systemctl list-timers certbot.timer i wykonaj próbę z sudo certbot renew --dry-run; nie dodawaj własnego zadania cron.

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

Certyfikaty wildcard wymagają wyzwania DNS-01: Certbot musi umieścić rekord TXT w _acme-challenge.example.com, co oznacza użycie 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 jawnym wykazem jest prostszy i pozwala uniknąć przechowywania kluczy API DNS na serwerze.