Установка Certbot для Apache в Ubuntu 24.04

Что вы создаете

Сайт на базе Apache в Ubuntu 24.04, работающий по протоколу HTTPS с бесплатным, доверенным браузерами сертификатом Let's Encrypt. Сертификат выпускается утилитой Certbot и автоматически обновляется через systemd-таймер, о котором вам не придется вспоминать. Основная работа выполняется одной командой. Все возможные ошибки возникают до выполнения этой команды: виртуальный хост без ServerName, закрытый порт 80 в сетевом экране провайдера или DNS, указывающий на старый сервер. Поэтому данное руководство уделяет основное внимание предварительным условиям и приводит точные тексты ошибок для каждой ситуации.

Два примечания по области применения. Если ваш веб-сервер — nginx, логика действий аналогична, но плагин и конфигурационные файлы будут другими; используйте nginx-версию этого руководства. Если вы защищаете внутренний ресурс — панель администратора с приватным адресом или тестовый сервер, доступный только вам, — центр сертификации не требуется; самоподписанный сертификат требует меньше настроек и работает без подключения к сети.

Предварительные требования и три причины, по которым процесс завершается неудачей еще до запуска Certbot

• Apache уже обслуживает ваш сайт по протоколу HTTP. Плагин Certbot для Apache вносит изменения в существующий сайт; он не создает его с нуля. Если вы начинаете с «чистого» VPS, сначала разверните стек LAMP на Ubuntu 24.04, а затем вернитесь к этому руководству — оно является недостающей главой о TLS.
• Публичный домен с A-записью, указывающей на адрес вашего VPS. Проверка HTTP-01 от Let's Encrypt означает, что их валидационные серверы подключаются к вашей машине из интернета: это исключает домашние лаборатории за NAT без проброса портов, использование имен .local и работу с голыми IP-адресами. dig +short example.com должен возвращать адрес вашего VPS. Если вы изменили DNS в течение последнего часа, дождитесь истечения TTL старой записи перед выпуском сертификата.
• Если существует AAAA-запись, она должна быть корректной. Let's Encrypt отдает предпочтение IPv6 при наличии опубликованной AAAA-записи. Поэтому устаревшая 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, который ваша оболочка находит в PATH, может не иметь прав на ваши сертификаты. Строка apt remove выше — это не просто украшение, она обязательна.

Виртуальный хост, который редактирует Certbot, должен существовать, а ServerName — это ключевой элемент

certbot --apache работает путем поиска виртуального хоста на 80 порту, чей ServerName или ServerAlias совпадает с каждым доменом -d, который вы передаете. Он подтверждает контроль над доменом через этот хост, а затем создает SSL-копию этого виртуального хоста. Если нет соответствующего ServerName, совпадения не будет, а стандартный 000-default.conf в Ubuntu поставляется с закомментированным ServerName. Эта единственная закомментированная строка — самая частая причина, по которой основная команда из этого руководства завершается ошибкой.

Поэтому перед тем, как использовать Certbot, создайте для сайта полноценный виртуальный хост на основе имени. Создайте /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, а не о вашем виртуальном хосте; в данном случае это безопасно и устраняется с помощью 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

При первом запуске утилита запрашивает три параметра: адрес электронной почты (используется для вашей учетной записи 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: включение модуля ssl в Apache (если он не был активен), создание файла example.com-le-ssl.conf (копии вашего vhost в *:443 с директивами SSLEngine on и путями к сертификатам), его активация и добавление блока RewriteRule в исходный vhost на 80-м порту, который выполняет 301-й редирект всего трафика на HTTPS. Ваш исходный файл vhost редактируется, а не заменяется, а SSL-версия создается рядом с ним, где вы можете изучить каждую добавленную строку.

Где физически хранятся сертификаты и почему их нельзя копировать

Все файлы находятся в /etc/letsencrypt/live/example.com/: fullchain.pem (сертификат вместе с промежуточной цепочкой, на который должны ссылаться серверы), privkey.pem (закрытый ключ, доступный для чтения только пользователю root), а также cert.pem и chain.pem для программ, требующих раздельные компоненты. Эти файлы являются символическими ссылками на /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-задачу; второй планировщик не принесет ничего, кроме лишних записей в логах и риска превышения лимитов запросов.

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

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

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

Если пробный запуск завершился ошибкой, реальное обновление через ~60 дней также не удастся. Исправьте проблему сейчас, пока у текущего сертификата еще есть запас времени. Чаще всего причиной является правило брандмауэра, добавленное после выпуска сертификата, которое снова закрыло 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 в этой команде, новый сертификат будет выпущен без этого домена.

Для подстановочных (wildcard) сертификатов требуется DNS-01, но обычно в них нет необходимости

Метод HTTP-01 не позволяет выпустить *.example.com, так как размещение файла на веб-сервере подтверждает контроль только над одним именем хоста, а не над всем пространством имен. Для подстановочных сертификатов требуется проверка DNS-01: Certbot устанавливает TXT-запись по адресу _acme-challenge.example.com. На практике это означает использование плагина certbot-dns-* с API-ключами вашего DNS-провайдера или ручное редактирование TXT-записей при каждом обновлении с помощью --manual (это крайне неудобно, не стоит рассчитывать на такой вариант). Полное руководство, от механики работы TXT-записей до настройки плагина для автоматического обновления, приведено в подстановочные сертификаты с Certbot через DNS-01. Совет: если у вас есть четыре известных поддомена, сертификат SAN с перечислением всех четырех будет проще, чем подстановочный, и не потребует хранения API-ключей DNS на сервере.

Режимы сбоев и сообщения об ошибках

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 выводит строковое представление исключения. Запустите 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 на 80 порту в поисках ServerName/ServerAlias, соответствующих вашему -d, и ничего не нашел. sudo apache2ctl -S показывает, как Apache фактически маршрутизирует запросы; добавьте строку ServerName в нужный vhost, перезагрузите конфигурацию и повторите попытку. Схожая проблема возникает, когда проверка попадает не на тот vhost: ответ на запрос приходит со статусом Invalid response ... 404, так как запрос перехватил другой сайт. Диагностика и инструмент те же: apache2ctl -S.

Тайм-аут проверки.

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

Let's Encrypt не удалось установить TCP-соединение с 80 портом по адресу, указанному в вашем DNS. Возможные причины в порядке убывания вероятности: сетевой брандмауэр провайдера (отдельный от ufw, настраивается в панели управления хостингом), правила ufw, разрешающие только 443 порт или только SSH, DNS, указывающий на старый сервер, или проблема с устаревшей записью AAAA (их серверы пытаются подключиться по 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 неудачных проверок на имя хоста для одной учетной записи в час. После обновления правил в 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) проверяет конфигурацию в тестовой среде, где действуют мягкие лимиты и не выпускаются реальные сертификаты, поэтому там можно ошибаться сколько угодно. Запускайте реальную команду только после того, как тестовая среда подтвердит успех. Другие лимиты — 50 сертификатов на зарегистрированный домен в неделю и 5 дубликатов одного набора имен в неделю — вы встретите, только если скрипт зациклен на перевыпуске.

Когда HTTPS заработает, помните, что сертификат защищает только транспорт, а не сам сервер: порт 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»?

Это происходит потому, что ни один активный виртуальный хост на 80 порту не содержит ServerName или ServerAlias, соответствующих домену, который вы передали через -d. Виртуальный хост по умолчанию в Ubuntu поставляется с закомментированным ServerName. Выполните sudo apache2ctl -S, найдите (или создайте) виртуальный хост, который должен отвечать за это имя, добавьте 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 на сервере.