renew, выполнить certbot renew --dry-run и убедиться, что веб-сервер безопасно применит обновлённые файлы.Когда инструкция применима
Инструкция рассчитана на публичный веб-сервис Linux с доменным именем, которым вы управляете. Нужные права зависят от выбранного способа проверки: для HTTP-01 требуется возможность разместить challenge-файл, освободить порт 80 либо разрешить плагину изменить конфигурацию веб-сервера; для DNS-01 — изменить TXT-запись вручную или через API DNS-провайдера. Certbot запускайте с привилегиями, необходимыми выбранному способу установки и доступу к его каталогам.
- Для HTTP-01 все опубликованные A- и AAAA-записи имени ведут к точкам, которые корректно обслуживают проверку. Не оставляйте ошибочную AAAA-запись при рабочей A-записи.
- Для DNS-01 вы контролируете DNS-зону либо можете поручить изм енение TXT-записей DNS-плагину Certbot через API DNS-провайдера.
- Для HTTP-01 доступен входящий HTTP на TCP-порту 80; при standalone этот порт должен быть свободен в момент проверки.
- При webroot или плагине веб-сервер и обратный прокси не подменяют путь
/.well-known/acme-challenge/страницей приложения, авторизацией или другим ответом. - Время сервера синхронизировано, а у Certbot есть исходящий доступ к инфраструктуре центра сертификации.
Не проверяйте HTTP-01 только из локальной сети
Выберите HTTP-01 или DNS-01
Проверка владения доменом — обязательная часть выпуска: сертификат не выдают только на основании заявки. Для обычного сайта обычно подходит HTTP-01. Для wildcard-сертификата, например *.example.com, необходим DNS-01: HTTP-01 не подтверждает wildcard-имена.
Выбор ACME-проверки
| Способ | Что проверяет Let’s Encrypt | Когда выбирать | Ограничения |
|---|---|---|---|
| HTTP-01 | Ресурс http://<домен>/.well-known/acme-challenge/<токен> | Обычный сайт с доступным HTTP-входом | Проверка выполняется через TCP-порт 80; wildcard не поддерживается |
| DNS-01 | TXT-запись _acme-challenge.<домен> | Wildcard, сервис без публичного HTTP или централизованное DNS-управление | Нужно менять DNS; автоматизация зависит от API провайдера и плагина |
При HTTP-01 Let’s Encrypt запрашивает файл только по HTTP на порту 80. Перенаправления поддерживаются только на HTTP или HTTPS и на порты 80 либо 443; поэтому нельзя заменять проверку произвольным HTTPS-портом. Веб-сервер должен отдать именно созданный Certbot ресурс по пути /.well-known/acme-challenge/, а не страницу приложения, ошибку авторизации или другой редирект.
Для DNS-01 центр сертификации ищет TXT-запись в _acme-challenge. Для wildcard-заявки это единственный допустимый тип проверки по правилам Let’s Encrypt. Если сертификат содержит и example.com, и *.example.com, проверка нужна для каждого заявленного идентификатора; Certbot и DNS-плагин покажут требуемые зап иси или создадут их через API.
Проверьте DNS и HTTP до выпуска
Подставьте своё имя вместо example.com. Эти проверки не изменяют конфигурацию.
- 1Проверьте адресную записьЗапросите публичную DNS-запись. В ответе должен быть ожидаемый публичный IP-адрес точки публикации. Если адрес другой или ответа нет, исправьте DNS и дождитесь распространения изменений.
- 2Проверьте путь HTTP-01Для webroot создайте временный файл в каталоге, который реально обслуживает виртуальный хост, и запросите его по полному публичному URL. Ожидается HTTP-ответ с содержимым файла. Если возвращается 404, 403, страница приложения или другой сайт, исправьте mapping виртуального хоста до запуска Certbot.
- 3Проверьте DNS-01 при ручном сценарииПосле публикации TXT-записи запросите её у публичного резолвера. Значение должно совпасть с тем, которое выдал Certbot. Если его нет, не продолжайте: дождитесь распространения DNS или проверьте делегирование зоны.
dig +short A example.com
dig +short AAAA example.comsudo mkdir -p /var/www/example/.well-known/acme-challenge
printf 'acme-preflight\n' | sudo tee /var/www/example/.well-known/acme-challenge/check.txt
curl -i http://example.com/.well-known/acme-challenge/check.txtdig +short TXT _acme-challenge.example.comУстановите Certbot и выберите интеграцию
Способ установки, названия пакетов и плагинов, расположение файлов и механизм расписания зависят от дистрибутива, источника установки и версии Certbot. В официальном мастере Certbot Instructions выберите свою ОС, Nginx, Apache либо вариант без автоматической интеграции и выполните предложенный для этой комбинации способ установки; также учитывайте документацию дистрибутива. После установки проверьте, что запускается именно ожидаемый клиент.
certbot --versionСпособы выпуска и установки
| Вариант Certbot | Когда использовать | Что изменяет |
|---|---|---|
| Плагин Nginx | Nginx установлен локально, конфигурация доступна Certbot и подходит для автоматического изменения | Может получить сертификат и предложить установить TLS-настройки в конфигурацию Nginx |
| Плагин Apache | Apache HTTP Server установлен локально и его конфигурация доступна Certbot | Может получить сертификат и предложить установить TLS-настройки в Apache |
webroot | Веб-сервер уже обслуживает сайт, но конфигурацию менять автоматически не нужно или нельзя | Кладёт временный challenge-файл в указанный webroot; TLS-конфигурацию вы меняете сами |
standalone | Нет работающего веб-сервера либо его можно кратковременно остановить, а порт 80 свободен | Certbot временно запускает собственный HTTP-сервер для проверки |
| DNS-плагин | Нужен wildcard или HTTP недоступен, а DNS-провайдер имеет поддерживаемый API | Создаёт и удаляет TXT-записи через API при корректно настроенных реквизитах |
Сначала отладьте сценарий в staging
--staging: он направляет запросы в тестовую среду Let’s Encrypt и не расходует производственн ые лимиты. Полученный сертификат не будет доверенным в браузерах, поэтому не оставляйте его в рабочей конфигурации сайта. У staging также есть собственные ограничения. Актуальные значения и исключения смотрите на официальной странице Let’s Encrypt Rate Limits.Обычное имя: выпуск через HTTP-01
Выберите один из следующих сценариев. Не запускайте несколько способов одновременно для одного и того же выпуска: это усложняет диагностику и может привести к ненужным проверкам.
Выпустите сертификат для example.com
Примеры запрашивают сертификат для example.com и www.example.com. Уберите имя, если оно не должно быть в сертификате.
- 1Используйте плагин веб-сервера, если готовы дать ему изменить конфигурациюДля Nginx используйте
certbot --nginx, для Apache —certbot --apacheс параметрами доменов. Certbot обнаружит подходящие виртуальные хосты, выполнит HTTP-01 и обычно предложит установить сертификат. После выполнения проверьте конфигурацию веб-сервера и открытие сайта по HTTPS. - 2Или выполните выпуск через webrootУкажите каталог, который обслуживает именно нужный HTTP-виртуальный хост. Certbot положит туда временный challenge-файл и после успешной проверки сохранит сертификат, но не обязан менять TLS-конфигурацию в еб-сервера. Далее подключите созданные Certbot файлы вручную.
- 3Используйте standalone только при свободном порте 80Остановите либо временно освободите сервис, который слушает TCP-порт 80, затем запустите Certbot в standalone-режиме. После выпуска верните веб-сервер в работу и настройте его на файлы Certbot. При продлении порт 80 также должен быть доступен Certbot, если в renewal-конфигурации сохранён standalone.
- 4Безопасно проверьте первоначальный выпуск в stagingЕсли production-сертификата ещё нет, сначала проверьте выбранный способ в режиме
certonly --staging, чтобы тестовый сертификат не был автоматически установлен в рабочий виртуальный хост. После успешной проверки найдите тестовую линейку черезcertbot certificates, убедитесь, что сервисы не ссылаются на её файлы, и удалите её черезcertbot delete. Затем отдельно выполните нужную production-команду без--staging. Для уже существующей production-линейки используйтеcertbot renew --dry-run, а не заменяйте её staging-сертификатом.
sudo certbot --nginx -d example.com -d www.example.comsudo certbot --apache -d example.com -d www.example.comsudo certbot certonly --webroot -w /var/www/example -d example.com -d www.example.comsudo certbot certonly --standalone -d example.com -d www.example.comWildcard-сертификат: выпуск через DNS-01
Для *.example.com используйте DNS-01. В типичной заявке добавляют и базовое имя example.com: wildcard охватывает имена на один уровень ниже, но не само базовое имя. DNS-плагин должен поддерживать API вашего DNS-провайдера; реквизиты API храните в отдельном файле с минимальными правами, достаточными только для нужной DNS-зоны.
sudo certbot certonly --dns-<provider> -d example.com -d '*.example.com'Если API-плагина нет, Certbot может показать TXT-запись для ручного создания. Такой выпуск возможен, но автоматическое продление потребует повторного ручного изменения DNS и потому не является автономным. Некоторые DNS-плагины умеют ожидать распространения записи, но интервалы, реквизиты и поведение определяются документацией выбранного плагина и DNS-провайдера.
Ограничьте доступ DNS-реквизитов
CSR и файлы, созданные Certbot
При стандартном выпуске через Certbot вручную создавать CSR и ключ через OpenSSL обычно не нужно. Certbot создаёт закрытый ключ, формирует CSR и выполняет ACME-процесс сам. Создание произвольного CSR через OpenSSL — отдельная задача; назначение CSR и различия форматов описаны в статье SSL/TLS-сертификаты на сервере: как работают, какие бывают и что выбрать.
В стандартном каталоге Certbot, обычно /etc/letsencrypt/live/<имя-сертификата>/, находятся PEM-файлы. Пути из этого каталога следует использовать в веб-сервере, а не копировать сертификаты в произвольное место: Certbot обновляет их при продлении. Точное имя каталога смотрите в выводе certbot certificates.
Файлы Certbot в каталоге live
| Файл | Назначение | Типичное использование |
|---|---|---|
cert.pem | Только конечный сертификат сервера | Нужен отдельным приложениям, если они сами запрашивают серверный сертификат без цепочки |
chain.pem | Цепочка сертификатов промежуточных центров без конечного сертификата | Используется только там, где программа требует цепочку отдельным файлом |
fullchain.pem | Конечный сертификат вместе с промежуточной цепочкой | Обычный файл сертификата для Nginx, Apache и многих TLS-серверов |
privkey.pem | Закрытый ключ, соответствующий сертификату | Указывается как файл ключа и не передаётся клиентам |
Для типичной ручной интеграции Nginx указывает fullchain.pem как сертификат и privkey.pem как ключ. В актуальных конфигурациях Apache обычно также используют fullchain.pem как файл сертификата и privkey.pem как файл ключа. Названия директив и допустимость отдельного файла цепочки зависят от веб-сервера и его версии; не добавляйте корневой сертификат в серверную цепочку.
# Nginx: пути подставьте из certbot certificates
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# Apache HTTP Server: синтаксис и размещение зависят от версии и конфигурации
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pemЗакрытый ключ — секрет
privkey.pem пользователем root и учётной записью, от имени которой веб-серверу действительно нужно прочитать ключ. Не выводите его содержимое, не прикладывайте к заявкам и не храните в репозитории. Если обязательный SELinux или AppArmor блокирует доступ сервиса, исправляйте контекст или профиль, а не отключайте защитный механизм: SELinux на сервере: Enforcing, контексты и устранение отказов.Подключите файлы и примените конфигурацию
Выполните после успешного выпуска через certonly или если плагин не установил конфигурацию автоматически.
- 1Возьмите пути из CertbotЗапустите
certbot certificatesи найдите строкуCertificate PathиPrivate Key Pathдля нужного имени. Обычно этоfullchain.pemиprivkey.pemв каталогеlive. - 2Укажите сертификат и ключ в нужном виртуальном хостеИспользуйте путь к
fullchain.pemдля сертификата и кprivkey.pemдля ключа. Не подменяйте их содержимымcert.pemбез цепочки и не указывайтеchain.pemвместо серверного сертификата. - 3Проверьте конфигурацию до reloadДля Nginx обычно применяют
nginx -t, для Apache —apachectl configtest. Ожидается успешная проверка синтаксиса. При ошибке не выполняйте reload: исправьте путь, права либо конфигурацию. - 4Безопасно примените конфигурациюВыполните reload штатной командой или механизмом управления службой вашего дистрибутива. Затем проверьте выдаваемый сертификат снаружи на нужном имени. Подробная диагностика цепочки, имени и истечения срока — в статье Ошибки SSL/TLS-сертификатов: expired, chain incomplete, mismatch и verify failed.
sudo certbot certificatessudo nginx -t && sudo systemctl reload nginxsudo apachectl configtest && sudo systemctl reload apache2Проверьте автопродление Let’s Encrypt
Сертификаты Let’s Encrypt имеют короткий срок действия. По состоянию на октябрь 2026 года стандартный срок составляет 64 дня, а Let’s Encrypt планирует дальнейшее сокращение, поэтому не закладывайте в мониторинг постоянные 90 дней и сверяйтесь с официальной документацией Let’s Encrypt. certbot renew не выпускает замену при каждом запуске: он проверяет управляемые сертификаты и пытается продлить только те, для которых наступило предусмотренное Certbot окно продления. Для успеха должны сохраниться условия настроенного метода проверки: доступность DNS, порта 80, webroot, виртуального хоста, прав на файлы и DNS API может измениться после выпуска.
Установка Certbot часто добавляет systemd timer или cron-задачу, но конкретные unit-файлы, расписание и даже наличие такого задания зависят от пакета и способа установки. Не считайте автопродление включённым, пока не увидите действующий планировщик и успешный тест.
Подтвердите, что продление сможет работать сейчас
- 1Найдите механизм планированияПроверьте список systemd timers и задания cron. Ожидается запись, запускающая Certbot или
certbot renew. Если её нет, настройте поддерживаемый планировщик по документации способа установки Certbot, а не создавайте вторую конкурирующую задачу поверх неизвестной штатной. - 2Выполните тест продленияКоманда
certbot renew --dry-runиспользует тестовую среду и проверяет сохранённые методы продления без замены рабочего сертификата. Ожидается успешное завершение по всем обрабатываемым сертификатам. Ошибка проверки домена означает, что реальное продление также может не пройти. - 3Проверьте способ применения сертификатаПосмотрите renewal-конфигурацию нужной линейки и выясните, сохранён ли installer-плагин Nginx или Apache: такой плагин может сам установить обновление и выполнить необходимый reload. Для сертификатов, выпущенных через
certonly, настройте постоянный deploy hook — например, исполняемый файл в каталогеrenewal-hooks/deployстандартной установки Certbot — либо добавьте hook в фактическую команду планировщика. Одноразовый параметр--deploy-hookпри ручном запуске не сохраняет настройку для timer или cron. - 4Контролируйте срок и результаты в мониторингеОтслеживайте срок сертификата, ошибки заданий Certbot и неуспешные reload. Успешный dry-run подтверждает состояние на момент теста, но не гарантирует, что будущая смена DNS, firewall, webroot, прав или конфигурации не остановит продление.
systemctl list-timers --all | grep -i certbot
systemctl list-unit-files | grep -i certbotsudo grep -R "certbot\|certbot renew" /etc/cron* /var/spool/cron 2>/dev/nullsudo certbot renew --dry-runsudo install -d -m 0755 /etc/letsencrypt/renewal-hooks/deploy
sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx >/dev/null <<'EOF'
#!/bin/sh
nginx -t && systemctl reload nginx
EOF
sudo chmod 0755 /etc/letsencrypt/renewal-hooks/deploy/reload-nginxDeploy hook и dry-run
--dry-run Certbot обычно не запускает deploy hooks, чтобы тест не воздействовал на сервис. Если нужно отдельно проверить hook, изучите параметры вашей версии Certbot, включая --run-deploy-hooks, и заранее оцените влияние reload на рабочую нагрузку.Диагностика lets encrypt renewal failed и acme challenge failed
Проблема
acme challenge failed при HTTP-01
Возможные причины
- A- или AAAA-запись ведёт не на тот сервер; особенно часто забывают про IPv6.
- TCP-порт 80 недоступен извне либо занят другим сервисом при standalone.
- Неверно указан webroot, виртуальный хост обслуживает другой каталог или приложение перехватывает путь.
- Прокси, CDN, редирект или правило доступа возвращают не challenge-файл.
Решение
Сопоставьте доменные A- и AAAA-записи с реальной точкой публикации, повторите проверку временного файла по HTTP и посмотрите журналы веб-сервера. Для standalone убедитесь, что порт 80 свободен именно в момент запуска. Если сертификат выпускается впервые, отладьте выбранный способ через certonly --staging: не устанавливайте тестовый сертификат в рабочий виртуальный хост, после проверки убедитесь, что сервисы не ссылаются на тестовую линейку, удалите её и отдельно выполните production-выпуск. Для существующей production-линейки используйте certbot renew --dry-run.
Как избежать
После изменений DNS, прокси, webroot или виртуального хоста запускайте `certbot renew --dry-run`.
Проблема
acme challenge failed при DNS-01
Возможные причины
- TXT-запись создана не в той зоне или с неверным именем `_acme-challenge`.
- Запись ещё не распространилась по авторитетным DNS-серверам.
- Токен API не имеет прав на DNS-зону, истёк или используется неверный файл реквизитов.
- У DNS-плагина нет нужного времени ожидания распространения либо оно недостаточно для провайдера.
Решение
Сверьте точное имя и значение TXT из вывода Certbot через dig, проверьте делегирование зоны и права API-токена. Для автоматизированного сценария используйте параметры ожидания и формат реквизитов из документации конкретного DNS-плагина.
Как избежать
Выдавайте API-токену минимальные права и тестируйте DNS-01 в staging после смены DNS-провайдера, токена или плагина.
Проблема
lets encrypt renewal failed или сертификат не обновился
Возможные причины
- Планировщик не установлен, отключён или запускает другой экземпляр Certbot.
- Изменились условия HTTP-01 или DNS-01.
- У Certbot нет прав записи в свои каталоги либо веб-сервер не может читать ключ.
- Reload не настроен, не выполнился или конфигурация веб-сервера содержит старые пути.
Решение
Запустите certbot renew --dry-run вручную и прочитайте его вывод. Проверьте состояние timer либо cron, журнал соответствующего unit и журнал Certbot; в типичной установке его ищут в /var/log/letsencrypt/, но путь зависит от установки. Затем проверьте конфигурацию веб-сервера и безопасно выполните reload.
Как избежать
Мониторьте срок действия сертификата извне, код завершения задания Certbot и ошибки reload; не ограничивайтесь наличием timer.
sudo journalctl -u <certbot-unit> --since '7 days ago' --no-pagersudo tail -n 100 /var/log/letsencrypt/letsencrypt.logПросмотр, удаление и отзыв сертификата
certbot certificates показывает сертификаты, которыми управляет Certbot, и помогает увидеть имя сертификата для дальнейших операций. Перед любым удалением проверьте, какие виртуальные хосты, приложения и задания продления используют его пути.
sudo certbot delete --cert-name example.com`certbot delete` не отзывает сертификат
certbot delete удаляет локальную запись и файлы, которыми управляет Certbot; он не выполняет отзыв сертификата. Удаление может сломать работающий веб-сервер, если его конфигурация ссылается на fullchain.pem или privkey.pem. После удаления проверьте конфигурацию, работу службы, ссылки на пути Certbot и задания продления.Отзыв применяют, когда действующему сертификату больше нельзя доверять, например при компрометации закрытого ключа или ошибочном выпуске. Это отдельная операция certbot revoke, требующая осознанно выбрать сертификат и способ подтверждения; перед выполнением сверяйтесь с актуальной документацией Certbot. После отзыва замените сертификат в сервисе и при подозрении на компрометацию проведите ротацию затронутого ключевого материала как инцидент, а не просто удалите локальные файлы.
Термины в статье
- ACME
- ACME — прикладной протокол автоматизации выпуска, продления и отзыва сертификатов, подтверждающий контроль заявителя над доменом или иным идентификатором.
- CSR
- CSR — запрос на выпуск сертификата, содержащий открытый ключ и сведения о субъекте, подписанные соответствующим закрытым ключом для подтверждения владения ключевой парой.
- Certbot
- Certbot — ACME-клиент с открытым исходным кодом для запроса, установки и продления TLS-сертификатов; он автоматизирует проверку домена и операции с ключами.
- DNS-01
- DNS-01 — тип проверки контроля домена в ACME, при котором центр сертификации сверяет TXT-запись _acme-challenge со значением, вычисленным из токена и ключа учётной записи ACME.
- HTTP-01
- HTTP-01 — тип проверки владения доменом в ACME, при котором центр сертификации запрашивает специальный HTTP-ресурс на проверяемом имени.
- Let’s Encrypt
- Let’s Encrypt — публичный центр сертификации, выпускающий сертификаты TLS после автоматизированной проверки контроля над доменным именем по протоколу ACME.
- PEM
- PEM — текстовый формат представления криптографических объектов в Base64 между строками BEGIN/END с меткой типа объекта; он не задаёт алгоритм шифрования или тип ключа.
- Wildcard-сертификат
- Wildcard-сертификат — сертификат X.509 для TLS с wildcard-идентификатором DNS в SAN, обычно охватывающим имена с одной меткой перед базовым доменом.
- Закрытый ключ
- Закрытый ключ — секретная часть асимметричной ключевой пары для создания подписей, расшифрования данных или подтверждения владения ключом при аутентификации.
- Отзыв сертификата
- Отзыв сертификата — прекращение доверия к действующему сертификату до истечения его срока, фиксируемое центром сертификации в CRL или через OCSP.
- Проверка владения доменом
- Проверка владения доменом — процедура подтверждения контроля над DNS-именем, обычно для выпуска сертификата, через DNS-запись, HTTP-файл, электронную почту или иной контр ольный метод.
- Сертификат TLS
- Сертификат TLS — цифровой документ X.509, содержащий открытый ключ и идентификаторы субъекта и подписанный издателем; доверие к связи определяется цепочкой и политикой клиента.
- Срок действия сертификата
- Срок действия сертификата — интервал между полями Not Before и Not After, в пределах которого сертификат может считаться действующим при успешной проверке остальных условий.
- Цепочка сертификатов
- Цепочка сертификатов — последовательность от конечного сертификата через сертификаты центров сертификации к точке доверия, позволяющая проверить подписи и построить путь доверия.