Встановлення Certbot для Apache на Ubuntu 24.04

Що ви створюєте

Сайт на Apache в Ubuntu 24.04, який працює через HTTPS з безкоштовним сертифікатом Let's Encrypt, що перевірений браузером. Сертифікат видається через Certbot і автоматично оновлюється за допомогою systemd timer, про який не потрібно турбуватися. Команда для виконання роботи складається з одного рядка. Будь-які помилки виникають до виконання цього рядка: vhost без ServerName, порт 80 закритий на фаєрволі провайдера або DNS все ще вказує на старий сервер. Тому більша частина цього посібника присвячена попереднім умовам; також наведено точні рядки помилок для кожної помилки.

Дві примітки. Якщо ваш вебсервер — nginx, алгоритм схожий, але плагін та конфігурації відрізняються — використовуйте nginx версію цього посібника. Якщо об'єкт захисту є внутрішнім (наприклад, панель адміністратора на приватній адресі або staging-сервер без зовнішнього доступу), центр сертифікації не потрібен; самопідписаний сертифікат потребує менше налаштувань і працює офлайн.

Prerequisites, and the three ways this fails before Certbot even runs

• Apache вже обслуговує ваш сайт через plain HTTP. Плагін Certbot для Apache редагує існуючий сайт, а не створює новий. Якщо ви використовуєте чистий VPS, спочатку встановіть LAMP stack on Ubuntu 24.04, а потім поверніться — цей посібник є розділом про TLS для цієї структури.
• Публічний домен з A record, що вказує на адресу вашого VPS. Метод Let's Encrypt HTTP-01 означає, що сервери перевірки підключаються до вашого сервера з інтернету: не підійде домашня лабораторія за NAT без прокидання портів, без .local імен або без прямих IP. dig +short example.com має повертати адресу вашого VPS; якщо ви змінили DNS протягом останньої години, зачекайте завершення TTL старого запису перед запуском.
• Якщо існує AAAA record, він має бути коректним. Let's Encrypt віддає перевагу IPv6, якщо опубліковано AAAA record. Застарілий AAAA призведе до помилки валідації, навіть якщо curl з вашого ноутбука — ймовірно, через IPv4 — працює стабільно. Опублікуйте коректний AAAA або не публікуйте його зовсім.

Порти 80 та 443 мають бути відкриті в ufw та у мережевому фаєрволі вашого провайдера — більшість панелей хостингу мають другий фаєрвол, який не видно в ОС. HTTP-01 виконує перевірку саме через порт 80; ви не можете використовувати лише 443.

sudo ufw allow "Apache Full"
sudo ufw status

Якщо всі умови виконано, вся робота займе п'ятнадцять хвилин, десять із яких — це читання.

Snap чи apt Certbot? У 24.04 apt нарешті підходить

Certbot перейшов на дистрибутив snap кілька років тому з вагомої причини: пакети дистрибутивів застарівають. Ubuntu 20.04 постачав Certbot 0.40 і не оновлювався, через що розробники витрачали час на виправлення п'ятирічних помилок. У 24.04 ця проблема зникла — архів містить Certbot 2.9.0 (актуальна версія), а unattended-upgrades забезпечує його оновлення. Моя рекомендація для цієї ОС: використовуйте apt. Ви не запускаєте демон snapd, плагін Apache встановлюється одним транзакційним процесом, а таймер оновлення інтегрується з systemd стандартним для Debian способом.

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

Правильний результат: certbot 2.9.0. Пакет python3-certbot-apache є плагіном, який зчитує та редагує конфігурації Apache — без нього certbot --apache видасть помилку The requested apache plugin does not appear to be installed.

Використання snap все ще є доцільним у двох випадках: вам потрібен найновіший Certbot у день його виходу або вам потрібен DNS-плагін, доступний лише у форматі snap (деякі плагіни провайдерів certbot-dns-* доступні лише так). Якщо ви оберете цей шлях:

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

Який би варіант ви не обрали, ніколи не використовуйте обидва одночасно. Два встановлення призведуть до конфлікту двох планувальників оновлення за /etc/letsencrypt, а certbot, який знайде ваша shell у PATH, може не бути тим, що керує вашими сертифікатами. Рядок apt remove вище не є необов'язковим прикрашанням.

Налаштування vhost для Certbot мають бути готові — ServerName є критичним

certbot --apache працює шляхом пошуку віртуального хоста на порту 80, чий ServerName або ServerAlias збігається з кожним доменом -d, який ви передаєте. Це підтверджує контроль над доменом через цей хост, після чого створюється SSL-дублікат цього vhost. Якщо відповідного ServerName немає, збіг не буде знайдено. У стандартному 000-default.conf в Ubuntu параметр ServerName закоментований. Це закоментоване поле є найчастішою причиною помилки при виконанні головної команди цього посібника.

Тому перед запуском Certbot налаштуйте для сайту відповідний vhost за іменем. Створіть /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>

Увімкніть його та переконайтеся, що Apache коректно зчитує конфігурацію та направляє запити на цей хост:

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

configtest має вивести Syntax OK. Якщо також виводиться AH00558: apache2: Could not reliably determine the server's fully qualified domain name, це попередження про глобальний ServerName, а не про ваш vhost — у цьому випадку це не критично, і echo "ServerName $(hostname -f)" | sudo tee /etc/apache2/conf-available/servername.conf && sudo a2enconf servername && sudo systemctl reload apache2 прибере це повідомлення.

Результат -S є ключовим для перевірки. Вам потрібен рядок на кшталт port 80 namevhost example.com (/etc/apache2/sites-enabled/example.com.conf:1) з alias www.example.com під ним. Apache звітує про симлінк sites-enabled, який він фактично зчитав, а не про файл, який ви редагували в sites-available. Якщо example.com не вказано для порту 80, Certbot також його не знайде.

Випуск сертифіката: certbot --apache

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

При першому запуску потрібно виконати три дії: вказати email (використовується для облікового запису ACME та термінових повідомлень CA; Let's Encrypt більше не надсилає попередження про закінчення терміну дії, тому ви повинні самостійно стежити за оновленнями), погодитися з умовами Let's Encrypt та вибрати, чи передавати ваш email організації EFF. Питання про перенаправлення більше не з'являється: починаючи з Certbot 2.0, модуль Apache за замовчуванням перенаправляє HTTP на HTTPS. Використовуйте прапор --no-redirect, якщо вам дійсно потрібно залишити звичайний HTTP для обслуговування контенту.

У разі успіху ви побачите наступне повідомлення. Його слід прочитати повністю, а не просто переглянути:

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

За цим повідомленням Certbot виконав чотири дії: увімкнув модуль Apache ssl, якщо він не був увімкнений, створив example.com-le-ssl.conf — копію вашого vhost на *:443 з SSLEngine on та шляхами до сертифікатів, увімкнув SSL та додав блок RewriteRule до оригінального vhost на порту 80, який виконує 301 redirect на HTTPS. Ваш оригінальний файл vhost редагується, а не замінюється; SSL-копія зберігається поруч, щоб ви могли перевірити кожен доданий рядок.

Де саме зберігається сертифікат і чому його не можна копіювати

Усі файли знаходяться в /etc/letsencrypt/live/example.com/: fullchain.pem (сертифікат та ланцюжок проміжних сертифікатів — те, на що мають посилатися сервери), privkey.pem (приватний ключ, доступний лише для root), а також cert.pem та chain.pem для програм, які потребують окремі компоненти. Ці файли є символьними посиланнями (symlinks) на /etc/letsencrypt/archive/. Така непряма адресація забезпечує механізм оновлення: процес оновлення записує нові файли в archive/ і перенаправляє символьні посилання. Якщо налаштувати інше програмне забезпечення на шляхи live/, воно отримуватиме оновлення автоматично. Якщо скопіювати файли в інше місце, через 90 днів ви отримаєте збій у роботі системи.

Інший важливий файл — /etc/letsencrypt/renewal/example.com.conf. Він містить дані про те, як було видано цей сертифікат: authenticator = apache, installer = apache та домени. Це дозволяє процесу оновлення виконуватися автоматично, включаючи подальше перезавантаження Apache.

Процес оновлення вже заплановано — перевірте його, а не запускайте вручну

Сертифікати Let's Encrypt діють 90 днів за замовчуванням. Пакет apt вже встановив необхідні компоненти: таймер systemd, який запускає Certbot двічі на добу у випадковий час. Він оновлює будь-який сертифікат, до закінчення терміну дії якого залишається 30 днів. Не створюйте додаткове завдання cron; другий планувальник лише створює зайві записи в логах та підвищує ризик блокування через обмеження частоти запитів (rate-limit).

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

Перша команда показує активний таймер із часом наступного запуску (NEXT) протягом наступних 24 годин. Графік передбачає два запуски на добу з випадковою затримкою, тому точний час неможливо передбачити (у snap-версії таймер має назву snap.certbot.renew.timer). Команда dry run виконує повну перевірку оновлення у staging-середовищі Let's Encrypt — це реальна перевірка, яка не видає сертифікат і не витрачає ліміти запитів. Успішний результат завершується так:

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

Якщо dry run завершиться помилкою, реальне оновлення через ~60 днів також не вдасться. Виправте проблему зараз, поки термін дії поточного сертифіката ще не вичерпано. Найчастішою причиною є правило firewall, додане після видачі сертифіката, яке знову закрило порт 80.

Перевірка за допомогою curl та очікуваний статус замка

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

Перший запит має повернути HTTP/1.1 301 Moved Permanently із заголовком Location: https://example.com/ — це перенаправлення, яке встановив Certbot. Другий запит має повернути HTTP/1.1 200 OK без помилок TLS у curl. Третій запит виведе видавця — рядок O = Let's Encrypt з коротким CN, наприклад R12 або E7, — та notAfter приблизно за 90 днів до закінчення терміну дії. У браузері з'явиться значок замка, а при натисканні на нього буде вказано того самого видавця. Якщо curl працює правильно, а браузер видає попередження, це майже напевно кеш сторінки або неправильне ім'я хоста, а не проблема з сертифікатом.

Кілька сайтів: один SAN-сертифікат або окремий сертифікат для кожного сайту

Обидва підходи працюють; процес оновлення однаковий. Для непов'язаних сайтів на одному хості запускайте команду видачі один раз для кожного сайту. Кожен сайт отримує власну директорію в live/ та власний конфігураційний файл оновлення. Проблема з одним доменом не перешкоджає оновленню інших. Це рекомендований метод.

Для одного сайту з декількома іменами використовуйте один SAN-сертифікат — один сертифікат може містити до 100 імен. Ви вже зробили це вище з example.com та www.example.com. Щоб пізніше додати ім'я до існуючого сертифіката, перевидайте його, вказавши назву сертифіката та повний новий список імен:

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

Certbot помітить зміну списку доменів, запитає підтвердження розширення та замінить сертифікат на місці. Шлях live/ залишається незмінним, тому інші налаштування не потребують коригування. Майте на увазі, що новий список повністю замінює старий, а не додається до нього: якщо ви пропустите www у команді, новий сертифікат просто видалить це ім'я.

Wildcards потребують DNS-01, і зазвичай вони вам не потрібні

HTTP-01 не може видати *.example.com — розміщення файлу на вебсервері підтверджує контроль лише над одним hostname, а не над усім namespace. Wildcards потребують перевірки DNS-01: Certbot створює TXT-запис у _acme-challenge.example.com. На практиці це означає використання certbot-dns-* plugin з API-ключами вашого DNS-провайдера або ручне редагування TXT-записів під час кожного оновлення через --manual (це незручно — не плануйте роботу таким чином). Повний посібник — від механіки TXT-записів до плагіна для автоматичного оновлення — наведено в wildcard certificates with Certbot over DNS-01. Порада: якщо у вас є чотири відомі subdomains, сертифікат SAN із переліком усіх чотирьох простіший за wildcard і не потребує зберігання DNS API-ключів на сервері.

Режими відмови та рядки, які ви побачите

Certbot відмовляється запускатися через помилку в конфігурації 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')

Плагін виконує configtest перед будь-якими діями та припиняє роботу, якщо Apache має помилки — \n є точними, оскільки Certbot виводить repr винятку. Запустіть sudo apache2ctl configtest самостійно: він вказує файл і рядок — зазвичай це помилка в написанні при ручному редагуванні, SSLCertificateFile на шлях, якого більше не існує, або згадка модуля, який не активовано. Виправте помилку до появи Syntax OK, потім запустіть Certbot знову.

Жоден vhost не відповідає домену.

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

Це помилка відсутності ServerName, про яку йшлося раніше, яку виявляється під час випуску сертифіката. Certbot перевірив усі увімкнені vhost на port-80 на наявність ServerName/ServerAlias, що відповідають вашому -d, і нічого не знайшов. sudo apache2ctl -S показує, куди фактично маршрутує запити Apache; додайте рядок ServerName у відповідний vhost, перезавантажте конфігурацію та повторіть спробу. Схожа проблема — валідація потрапляє на неправильний vhost: відповідь на challenge повертається Invalid response ... 404, оскільки запит перехопив інший сайт. Діагностика та інструмент ті самі: apache2ctl -S.

Тайм-аут валідації.

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

Let's Encrypt не зміг встановити TCP-з'єднання з port 80 за адресою, яку вказує ваш DNS. Найбільш імовірні причини: мережевий брандмауер провайдера (окремо від ufw, налаштовується в панелі хостингу), набір правил ufw, що дозволяє лише 443 або лише SSH, DNS все ще вказує на попередній сервер, або проблема застарілих записів AAAA — сервери Let's Encrypt намагаються використати IPv6, а ваш сервер відповідає лише на IPv4. Перевірте з зовні VPS: curl -I http://example.com з вашого ноутбука відтворить те, що бачить валідатор.

Ви перевищили ліміт через часті повторні спроби.

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

Let's Encrypt дозволяє 5 невдалих валідацій на один hostname на один account на годину — після оновлення лімітів у 2025 році це працює за принципом "відкритого бака", де ліміт відновлюється приблизно на одну спробу кожні 12 хвилин — часті повторні спроби при несправному брандмауері швидко вичерпають цей ліміт. Очікування допоможе, але правильне рішення — змінити підхід: після будь-якої помилки використовуйте staging-середовище для налагодження, доки операція не завершиться успішно.

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

Зверніть увагу на certonly: --dry-run приймається лише підкомандами certonly та renew, а звичайна форма certbot --apache --dry-run взагалі не запускається, видаючи --dry-run currently only works with the 'certonly' or 'renew' subcommands. Режим dry run виконує перевірку через staging, який має власні ліміти та не видає справжні сертифікати, тому ви можете проводити там тестування весь день. Запускайте основну команду лише після успішного проходження staging. Інші ліміти — 50 сертифікатів на зареєстрований домен на тиждень, 5 дублікатів одного імені на тиждень — ви зустрінете лише якщо скрипт виконує перевипуск у нескінченному циклі.

Коли HTTPS налаштовано, пам'ятайте, що сертифікат захищає транспорт, а не сервер: port 22 все ще приймає спроби підбору паролів. Поєднання цього з Fail2ban на Ubuntu 24.04 — це логічний наступний крок.

FAQ

Чи варто встановлювати Certbot через snap чи apt для Apache на Ubuntu 24.04?

Використовуйте apt. Ubuntu 24.04 постачає Certbot 2.9.0, версія якого достатня для всіх кроків цього посібника. Пакет отримує оновлення безпеки через unattended-upgrades і не потребує snapd. Обирайте snap лише якщо вам негайно потрібна найновіша версія або DNS-плагін, доступний виключно у форматі snap. Якщо ви переходите на snap, спочатку виконайте apt remove certbot python3-certbot-apache, щоб уникнути конфлікту двох планувальників оновлення.

Чому Certbot видає помилку "Unable to find a virtual host listening on port 80"?

Це стається, якщо жоден увімкнений vhost на порту 80 не має ServerName або ServerAlias, що відповідає домену, вказаному через -d. Стандартний vhost в Ubuntu має ServerName закоментованим. Виконайте sudo apache2ctl -S, знайдіть (або створіть) vhost, якому належить це ім'я, додайте ServerName example.com, перезавантажте Apache і знову запустіть Certbot.

Як виправити помилку "Timeout during connect (likely firewall problem)"?

Let's Encrypt не зміг підключитися до порту 80 за адресою, яку публікує ваш DNS. Перевірте мережевий фаєрвол у панелі керування провайдера, а також ufw. Переконайтеся, що dig +short example.com повертає IP цього VPS, і видаліть або виправте застарілі AAAA-записи — для перевірки пріоритет надається IPv6, якщо він існує. Перевірте виправлення ззовні сервера за допомогою curl -I http://example.com, а потім протестуйте процес за допомогою sudo certbot certonly --apache --dry-run -d example.com перед справжнім випуском сертифіката.

Чи оновлює Certbot сертифікати автоматично на Ubuntu 24.04?

Так. Пакет apt встановлює certbot.timer — таймер systemd, який запускається двічі на день і оновлює будь-який сертифікат за 30 днів до закінчення терміну дії, після чого перезавантажує Apache. Пакет snap використовує snap.certbot.renew.timer для тієї ж задачі. Перевірте статус за допомогою systemctl list-timers certbot.timer і протестуйте за допомогою sudo certbot renew --dry-run — не створюйте власні завдання cron додатково.

Як отримати wildcard-сертифікат за допомогою Certbot та Apache?

Wildcard-сертифікати потребують перевірки DNS-01: Certbot має розмістити TXT-запис за адресою _acme-challenge.example.com. Для цього потрібен certbot-dns-*-плагін з API-ключами вашого DNS-провайдера (альтернатива --manual потребує ручного редагування TXT-записів під час кожного оновлення). Якщо у вас лише кілька відомих піддоменів, простіше використати сертифікат SAN з явним переліком цих доменів — це дозволить не зберігати API-ключі DNS на сервері.