Instalacja Certbot dla Apache na Ubuntu 24.04

Cel projektu

Serwer Apache na systemie Ubuntu 24.04 obsługujący protokół HTTPS przy użyciu bezpłatnego certyfikatu Let's Encrypt, zaufanego przez przeglądarki. Certyfikat jest wystawiany przez Certbot i odnawiany automatycznie przez timer systemd. Proces odnawiania odbywa się w tle. Do wykonania głównego zadania wystarczy jedna komenda. Większość błędów występuje przed wykonaniem tej komendy: brak konfiguracji ServerName w vhost, port 80 zablokowany na firewallu u dostawcy lub rekordy DNS wskazujące na stary serwer. Niniejszy poradnik skupia się głównie na wymaganiach wstępnych i podaje dokładne komunikaty błędów dla każdego przypadku.

Uwagi dotyczące zakresu. Jeśli używany serwer to nginx, proces przebiega analogicznie, lecz wymagane są inne wtyczki i pliki konfiguracyjne — należy skorzystać z wersji tego poradnika dla nginx. Jeśli zabezpieczany zasób jest dostępny wyłącznie w sieci wewnętrznej — np. panel administracyjny pod prywatnym adresem lub serwer stagingowy — nie jest wymagane centrum certyfikacji; certyfikat self-signed jest prostszym rozwiązaniem działającym offline.

Wymagania wstępne oraz trzy powody niepowodzenia przed uruchomieniem Certbot

• Apache obsługuje już witrynę przez protokół HTTP. Wtyczka Apache dla Certbot edytuje istniejącą konfigurację; nie tworzy nowej. Jeśli korzystasz z czystego VPS, najpierw zainstaluj LAMP stack on Ubuntu 24.04, a następnie wróć do instrukcji — ten poradnik 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 połączenia serwerów walidacyjnych z serwerem przez internet: wymagane jest przekierowanie portów (brak możliwości użycia NAT w domowym laboratorium), brak nazw .local oraz brak samych adresów IP. dig +short example.com musi zwracać adres VPS. Jeśli zmieniono ustawienia DNS w ciągu ostatniej godziny, należy odczekać na wygaśnięcie TTL starego rekordu przed wystawieniem certyfikatu.
• Jeśli istnieje rekord AAAA, musi być poprawny. Let's Encrypt preferuje IPv6 w przypadku publikacji rekordu AAAA. Niepoprawny rekord AAAA spowoduje błąd walidacji, nawet jeśli curl z laptopa — prawdopodobnie przez IPv4 — działa poprawnie. Należy opublikować poprawny rekord AAAA lub nie publikować żadnego.

Porty 80 oraz 443 muszą być otwarte w ufw oraz w firewallu sieciowym dostawcy — większość paneli hostingowych posiada drugi firewall niewidoczny dla systemu operacyjnego. Protokół HTTP-01 wymaga walidacji konkretnie przez port 80; nie można przeprowadzić procesu wyłącznie przez port 443.

sudo ufw allow "Apache Full"
sudo ufw status

Po spełnieniu powyższych warunków cała procedura zajmie piętnaście minut, z czego dziesięć to czytanie.

Snap czy apt Certbot? W wersji 24.04 apt jest wystarczający

Certbot został przeniesiony do dystrybucji snap z konkretnego powodu: pakiety dystrybucyjne stają się przestarzałe. Ubuntu 20.04 dostarczało Certbot 0.40 i nie wprowadzało aktualizacji, co powodowało problemy z debugowaniem błędów sprzed pięciu lat. W wersji 24.04 ten problem nie występuje — repozytorium dostarcza Certbot 2.9.0, czyli wersję z bieżącej generacji, a unattended-upgrades zapewnia aktualizacje łatek. Rekomendacja dla tego systemu: należy używać apt. Pozwala to uniknąć demona snapd, wtyczka Apache jest instalowana w ramach tej samej operacji, a harmonogram odnawiania integruje się z systemd w standardowy sposób 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 służąca do odczytu i edycji konfiguracji Apache — bez niej certbot --apache zgłosi błąd The requested apache plugin does not appear to be installed.

Instalacja snap jest właściwa w dwóch przypadkach: gdy wymagana jest najnowsza wersja Certbot natychmiast po jej wydaniu lub gdy wymagana jest wtyczka DNS dostępna wyłącznie jako snap (kilka wtyczek dostawców certbot-dns-* jest dostępnych tylko w tej formie). 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

Należy wybrać tylko jedną metodę instalacji. Dwie instalacje powodują konflikt dwóch harmonogramów odnawiania o /etc/letsencrypt, a certbot wykryty przez powłokę w PATH może nie być narzędziem zarządzającym certyfikatami. Linia apt remove powyżej nie jest opcjonalnym elementem dekoracyjnym.

Konfiguracja vhost dla Certbot musi istnieć — kluczowe znaczenie ma ServerName

certbot --apache działa poprzez wyszukiwanie wirtualnego hosta na porcie 80, którego ServerName lub ServerAlias odpowiada każdemu przekazanemu domenowi -d. Potwierdza to kontrolę nad domeną, a następnie tworzy plik SSL będący kopią tego vhosta. Brak dopasowania ServerName powoduje brak dopasowania — domyślna konfiguracja 000-default.conf w systemie Ubuntu posiada ServerName zakomentowane. Ta jedna zakomentowana linia jest najczęstszą przyczyną błędów podczas wykonywania głównej komendy z tego poradnika.

Przed uruchomieniem Certbot należy przypisać witrynie poprawny vhost oparty na nazwie. Należy utworzyć /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>

Należy aktywować konfigurację i potwierdzić, że Apache poprawnie ją parsuje oraz przekierowuje nazwę do tego hosta:

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

Polecenie configtest musi wyświetlić 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 vhosta — w tym przypadku nie ma to znaczenia i zostanie wyciszone przez echo "ServerName $(hostname -f)" | sudo tee /etc/apache2/conf-available/servername.conf && sudo a2enconf servername && sudo systemctl reload apache2.

Kluczowe jest sprawdzenie wyjścia -S. Wymagana jest linia typu port 80 namevhost example.com (/etc/apache2/sites-enabled/example.com.conf:1) z alias www.example.com poniżej — Apache raportuje faktycznie odczytany link symboliczny sites-enabled, a nie plik edytowany w sites-available. Jeśli example.com nie jest wymieniony dla portu 80, Certbot również go nie odnajdzie.

Issue the certificate: certbot --apache

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

Pierwsze uruchomienie wymaga podania trzech danych: adresu e-mail (używanego do konta ACME oraz pilnych powiadomień CA; Let's Encrypt nie wysyła już ostrzeżeń o wygaśnięciu, więc monitorowanie odnowień leży po stronie użytkownika), akceptacji warunków Let's Encrypt oraz zgody na udostępnienie adresu e-mail organizacji EFF. Pytanie o przekierowanie nie jest już zadawane: od wersji Certbot 2.0 instalator Apache domyślnie przekierowuje HTTP na HTTPS, co jest pożądanym zachowaniem. Należy użyć flagi --no-redirect, jeśli wymagane jest pozostawienie protokołu HTTP do serwowania treści.

W przypadku sukcesu komunikat wygląda następująco; należy go dokładnie przeczytać:

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

Po wyświetleniu tego komunikatu Certbot wykonał cztery operacje: aktywował moduł ssl w Apache (jeśli nie był aktywny), utworzył plik example.com-le-ssl.conf — kopię vhost w lokalizacji *:443 zawierającą SSLEngine on oraz ścieżki do certyfikatów, aktywował moduł oraz dodał blok RewriteRule do oryginalnego vhost na porcie 80, który przekierowuje ruch (301) na HTTPS. Oryginalny plik vhost zostaje zmodyfikowany, a nie zastąpiony; plik SSL znajduje się obok, co umożliwia weryfikację wszystkich dodanych linii.

Lokalizacja certyfikatu i powody, dla których nie należy go kopiować

Wszystkie pliki znajdują się w /etc/letsencrypt/live/example.com/: fullchain.pem (certyfikat wraz z łańcuchem pośrednim — właściwy dla serwerów), privkey.pem (klucz prywatny, dostępny tylko dla użytkownika root), oraz cert.pem i chain.pem dla oprogramowania wymagającego oddzielnych plików. Pliki te są linkami symbolicznymi do /etc/letsencrypt/archive/. Ta pośrednia struktura stanowi mechanizm odnawiania: proces odnawiania zapisuje nowe pliki w archive/ i aktualizuje linki symboliczne. Skonfigurowanie dowolnego innego oprogramowania przy użyciu ścieżek live/ zapewnia automatyczne pobieranie odnowionych certyfikatów; skopiowanie plików w inne miejsce spowoduje awarię systemu po 90 dniach.

Innym istotnym plikiem jest /etc/letsencrypt/renewal/example.com.conf. Zawiera on informacje o sposobie wystawienia certyfikatu — authenticator = apache, installer = apache, domeny — co umożliwia automatyczne odnawianie procesu, w tym automatyczne przeładowanie usługi Apache.

Odnowienie jest już zaplanowane — należy je zweryfikować, a nie uruchamiać ponownie

Certyfikaty Let's Encrypt są domyślnie ważne przez 90 dni. Pakiet apt zainstalował już niezbędne mechanizmy: timer systemd, który uruchamia Certbot dwa razy dziennie o losowych porach, odnawiając każdy certyfikat na 30 dni przed wygaśnięciem. Nie należy tworzyć dodatkowych zadań cron; drugi harmonogram generuje jedynie niepotrzebne wpisy w logach i zwiększa ryzyko przekroczenia limitów (rate-limit).

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

Pierwsza komenda 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ładna godzina jest celowo nieprzewidywalna (w przypadku instalacji snap timer to snap.certbot.renew.timer). Tryb dry run przeprowadza pełną próbę odnowienia w środowisku staging Let's Encrypt — proces obejmuje rzeczywiste wyzwania (challenges), ale nie wydaje certyfikatu 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 dry run zakończy się błędem, rzeczywiste odnowienie za około 60 dni zakończy się w ten sam sposób. Należy naprawić błąd natychmiast, póki obecny certyfikat jest wciąż ważny. Najczęstszą przyczyną jest reguła firewall dodana po wystawieniu certyfikatu, która ponownie zamknęła port 80.

Weryfikacja za pomocą curl oraz wygląd ikony kłódki

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 żądanie powinno zwrócić HTTP/1.1 301 Moved Permanently z nagłówkiem Location: https://example.com/ — jest to przekierowanie zainstalowane przez Certbot. Drugie żądanie powinno zwrócić HTTP/1.1 200 OK bez błędów TLS w curl. Trzecie żądanie wyświetli wystawcę — linię O = Let's Encrypt z krótkim CN, takim jak R12 lub E7 — oraz notAfter datę wygaśnięcia za około 90 dni. W przeglądarce wyświetlana jest ikona kłódki, a po jej kliknięciu widoczny jest ten sam wystawca. Jeśli curl działa poprawnie, a przeglądarka wyświetla ostrzeżenie, przyczyną jest najprawdopodobniej pamięć cache lub błędna nazwa hosta, a nie problem z certyfikatem.

Wiele witryn: jeden certyfikat SAN czy jeden certyfikat na każdą witrynę

Obie metody są poprawne; proces odnawiania przebiega tak samo. W przypadku niezwiązanych ze sobą witryn na tym samym serwerze, należy uruchomić polecenie generowania certyfikatu osobno dla każdej witryny. Każda z nich otrzyma własny katalog w live/ oraz własną konfigurację odnawiania. Błąd dotyczący jednej domeny nie blokuje odnawiania pozostałych. Jest to zalecana metoda.

W przypadku jednej witryny posiadającej wiele nazw, należy umieścić je w jednym certyfikacie SAN — pojedynczy certyfikat może zawierać do 100 nazw. Zostało to wykonane powyżej dla example.com oraz www.example.com. Aby później dodać nazwę do istniejącego certyfikatu, należy wygenerować go ponownie, 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 wykrywa zmianę zestawu domen, prosi o potwierdzenie rozszerzenia i podmienia certyfikat w tym samym miejscu — ścieżka live/ pozostaje niezmieniona, więc nie wymaga dodatkowych modyfikacji. Należy pamiętać, że lista służy do zastąpienia starych danych, a nie do dopisywania nowych: pominięcie www w poleceniu spowoduje usunięcie tej domeny z nowego certyfikatu.

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

HTTP-01 nie pozwala na wystawienie *.example.com — umieszczenie pliku na serwerze WWW potwierdza kontrolę nad jedną nazwą hosta, a nie nad całym namespace. Certyfikaty wildcard wymagają wyzwania DNS-01: Certbot tworzy rekord TXT w _acme-challenge.example.com. W praktyce wymaga to użycia pluginu certbot-dns-* z danymi uwierzytelniającymi API dostawcy DNS lub ręcznej edycji rekordów TXT przy każdym odnowieniu za pomocą --manual (proces uciążliwy — nie należy go planować). Pełny przewodnik, od mechaniki rekordów TXT po plugin automatyzujący odnawianie, znajduje się w certyfikaty wildcard z Certbot przez DNS-01. Rekomendacja: jeśli posiadane są 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 oraz wyświetlane komunikaty

Certbot nie może się uruchomić, ponieważ konfiguracja Apache jest błędna.

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 wykonuje configtest przed podjęciem jakichkolwiek działań i przerywa pracę, jeśli Apache zgłasza błąd — komunikaty \n są dosłowne, ponieważ Certbot wypisuje repr wyjątku. Należy samodzielnie uruchomić sudo apache2ctl configtest: wskazuje on plik oraz linię — 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. Należy naprawić błąd, aż pojawi się Syntax OK, a następnie ponownie uruchomić Certbot.

Żaden vhost nie pasuje do domeny.

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

Jest to błąd typu brak-ServerName, wykryty podczas wystawiania certyfikatu. Certbot przeszukał wszystkie aktywne vhosty na porcie 80 w poszukiwaniu ServerName/ServerAlias pasującego do -d i nie znalazł dopasowania. sudo apache2ctl -S pokazuje rzeczywiste przekierowania Apache; należy dodać linię ServerName do właściwego vhosta, przeładować konfigurację i ponowić próbę. Podobnym problemem jest walidacja trafiająca do niewłaściwego vhosta — odpowiedź na wyzwanie (challenge response) zwraca Invalid response ... 404, ponieważ żądanie przechwyciła inna witryna. Diagnoza i narzędzie pozostają te same: apache2ctl -S.

Przekroczenie czasu oczekiwania walidacji (timeout).

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

Let's Encrypt nie może nawiązać połączenia TCP na porcie 80 pod adresem wskazanym przez DNS. Najczęstsze przyczyny: firewall sieciowy dostawcy (oddzielny od ufw, konfigurowany w panelu hostingu), reguły ufw zezwalające tylko na port 443 lub tylko SSH, DNS wciąż wskazujący na poprzedni serwer lub problem ze starymi rekordami AAAA — serwery walidujące próbują połączenia IPv6, podczas gdy serwer odpowiada tylko na IPv4. Należy przeprowadzić test z zewnątrz VPS: curl -I http://example.com z laptopa pozwoli odtworzyć sytuację widoczną dla walidatora.

Zbyt częste ponawianie prób doprowadziło do limitu (rate limit).

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

Let's Encrypt zezwala na 5 nieudanych walidacji na hostname na konto na godzinę — po zmianach w limitach z 2025 roku obowiązuje mechanizm odnawialnego limitu (refilling bucket), który przywraca około jednej próby co 12 minut — intensywne ponawianie prób przy uszkodzonym firewallu szybko wyczerpuje dostępny limit. Konieczne jest odczekanie, jednak właściwym rozwiązaniem jest zmiana procedury: po każdym błędzie należy przeprowadzać debugowanie w środowisku staging, aż do uzyskania sukcesu.

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

Należy zwrócić uwagę na certonly: --dry-run jest akceptowany wyłącznie przez podkomendy certonly oraz renew, natomiast sama forma certbot --apache --dry-run nie zostanie uruchomiona, wyświetlając komunikat --dry-run currently only works with the 'certonly' or 'renew' subcommands. Tryb dry run waliduje połączenie ze stagingiem, który posiada własne, wysokie limity i nie wystawia rzeczywistych certyfikatów, co pozwala na wielokrotne testowanie. Rzeczywistą komendę należy uruchomić dopiero po pomyślnym zakończeniu testów na stagingu. Inne limity — 50 certyfikatów na zarejestrowaną domenę na tydzień oraz 5 duplikatów tej samej nazwy na tydzień — wystąpią tylko w przypadku zapętlenia skryptu wystawiającego certyfikaty.

Po uruchomieniu HTTPS należy pamiętać, że certyfikat zabezpiecza transport, a nie serwer: port 22 nadal pozostaje podatny na ataki typu brute-force. Kolejnym krokiem powinno być Zainstalowanie Fail2ban na Ubuntu 24.04.

FAQ

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

Należy użyć apt. Ubuntu 24.04 dostarcza wersję Certbot 2.9.0, która jest wystarczająco aktualna dla wszystkich elementów tego poradnika, otrzymuje poprawki bezpieczeństwa przez unattended-upgrades i nie wymaga snapd. Należy wybrać snap tylko wtedy, gdy wymagana jest natychmiastowa aktualizacja do najnowszej wersji lub gdy wymagany jest plugin DNS dystrybuowany wyłącznie jako snap — w przypadku zmiany metody należy najpierw wykonać apt remove certbot python3-certbot-apache, aby uniknąć współistnienia dwóch harmonogramów odnawiania.

Dlaczego Certbot wyświetla komunikat "Unable to find a virtual host listening on port 80"?

Błąd występuje, gdy żaden aktywny vhost na porcie 80 nie posiada ServerName lub ServerAlias pasującego do domeny przekazanej za pomocą -d — domyślny vhost w Ubuntu ma ServerName zakomentowane. Należy uruchomić sudo apache2ctl -S, odnaleźć (lub utworzyć) vhost przypisany do danej nazwy, dodać ServerName example.com, przeładować Apache i ponownie uruchomić Certbot.

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

Let's Encrypt nie może połączyć się z portem 80 pod adresem wskazanym przez DNS. Należy sprawdzić firewall sieciowy w panelu dostawcy oraz ufw, potwierdzić, że dig +short example.com zwraca ten adres VPS, oraz usunąć lub poprawić nieaktualne rekordy AAAA — proces walidacji preferuje IPv6, jeśli taki rekord istnieje. Należy potwierdzić rozwiązanie spoza serwera za pomocą curl -I http://example.com, a następnie przeprowadzić próbę testową za pomocą sudo certbot certonly --apache --dry-run -d example.com przed właściwym wystawieniem 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 na 30 dni przed wygaśnięciem, a następnie przeładowuje Apache; wersja snap używa snap.certbot.renew.timer do tego samego zadania. Należy zweryfikować to za pomocą systemctl list-timers certbot.timer i przeprowadzić próbę testową za pomocą sudo certbot renew --dry-run — nie należy tworzyć 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 pluginu certbot-dns-* z danymi uwierzytelniającymi API dla dostawcy DNS (alternatywa --manual wymaga ręcznej edycji rekordów TXT przy każdym odnowieniu). Jeśli występuje tylko kilka znanych subdomen, prostszym rozwiązaniem jest certyfikat SAN z jawnie wymienionymi nazwami, co pozwala uniknąć przechowywania kluczy API DNS na serwerze.