Автопродление TLS включено, а сертификат истекает: что проверить

Если сертификат скоро истекает, одной отметки «автопродление включено» мало. Проверьте пять отдельных этапов: запуск задания, подтверждение домена, выпуск, установку в сервис и сертификат, который реально получают посетители. Сбой на любом шаге оставляет в браузере старый срок, хотя панель может выглядеть вполне успокаивающе.

Автоматизация TLS — цепочка, а не одна кнопка. Планировщик запускает ACME-клиент, центр сертификации проверяет контроль над доменом, клиент получает новый сертификат, сервис применяет его, а балансировщики и CDN начинают отдавать новую версию. Поэтому сначала определяют этап сбоя и только затем меняют настройки.

Вот тут интересно: успешный код завершения ещё не доказывает выпуск нового сертификата. В документации Certbot указано, что команда обновления может завершиться с кодом 0 и тогда, когда сертификаты ещё не подошли к порогу продления. Нужны журнал конкретной попытки, новый серийный номер и более поздняя дата окончания.

Сначала зафиксируйте то, что видит внешний клиент, а не то, что лежит файлом на сервере. Это исходная точка для разговора с хостингом или администратором.

• Имя хоста, порт и точное время проверки.

• Издатель, серийный номер или отпечаток, даты начала и окончания действия.

• Список имён в сертификате и полнота цепочки.

• Публичная точка ответа: исходный сервер, балансировщик, CDN или другой фронтенд.

• Результат для каждой точки, если один домен обслуживают несколько узлов.

Для первой внешней сверки подойдёт инструмент проверки SSL-сертификата: он помогает увидеть фактически отдаваемый сертификат. Но один результат не проверяет все узлы за балансировщиком, поэтому для распределённой схемы нужен перечень точек и повторяемая проверка каждой.

В описании проверок Let’s Encrypt HTTP-01 привязан к доступности служебного файла через порт 80. Если запросы принимают несколько фронтендов, проверочный файл должен быть доступен на каждом из них либо маршрутизироваться в одно согласованное место.

При DNS-01 центр сертификации ищет TXT-запись _acme-challenge. Здесь чаще мешают задержка распространения DNS, неправильная зона или слишком широкие и устаревшие учётные данные DNS-провайдера. Руководство Let’s Encrypt для интеграторов отдельно советует проектировать хранение сертификатов и доставку challenge для нескольких фронтендов, а не надеяться на локальный файл одного узла.

• Для HTTP-01 подтвердите доступность порта 80 извне и одинаковую выдачу challenge на всех фронтендах.

• Для DNS-01 подтвердите, какая система меняет TXT-запись, видна ли новая запись авторитетным серверам и ограничены ли права ключа нужной зоной.

• Для каждого имени из сертификата проверьте отдельный успешный результат: один удачный домен не закрывает остальные.

Запись CAA отвечает на другой вопрос: каким центрам сертификации разрешён выпуск для домена. По RFC 8659 это ограничение для выпуска, а не проверка браузером и не подтверждение исправности автопродления. Текущая CAA может быть корректной, а challenge или установка всё равно завершатся ошибкой.

После успешного выпуска сертификата проверьте путь от файла до процесса веб-сервера. Certbot может только получить сертификат, а применение к веб-серверу выполняет установщик или deploy-hook. Такой hook запускается после успешного продления; его ошибка, неверный путь или отсутствие штатного применения конфигурации оставят сервис на прежнем файле.

Отдельно проверьте CDN, балансировщик и каждый фронтенд. Сертификат на исходном сервере не меняет автоматически сертификат, завершённый на внешнем CDN. В кластере один узел может сохранить старую версию, поэтому случайные проверки будут то проходить, то показывать близкий срок окончания.

1. Назначьте владельца сертификата и составьте список доменных имён, публичных точек и систем, где завершается TLS.

2. Сверьте расписание и журнал последней попытки. Отсутствие свежей попытки означает проблему до обращения к центру сертификации.

3. Попросите администратора выполнить штатную пробную проверку через staging-среду центра сертификации. Для Certbot dry-run проверяет получение тестового сертификата; установку нужно проверять отдельно с учётом настроенных hooks.

4. Подтвердите выбранный challenge и его условия: порт 80 и маршрутизация для HTTP-01 либо TXT-запись, распространение и минимальные права для DNS-01.

5. После реального продления сравните серийный номер, даты и цепочку сначала в сервисе, затем на каждой внешней точке.

6. Настройте предупреждение по сертификату, который реально отдаётся снаружи, с запасом времени на ручное исправление.

Автопродление можно считать принятым, когда есть свежая успешная попытка для всех имён, новый сертификат получен, штатно применён, а каждая публичная точка отдаёт ожидаемый серийный номер и более поздний срок. Дополнительно должно срабатывать внешнее предупреждение до критического остатка срока.

• Планировщик запускается на ожидаемом узле.

• ACME challenge проходит для каждого имени.

• Получен новый сертификат с проверяемыми датами и серийным номером.

• Сервис применил именно новый файл без незапланированной остановки.

• Все фронтенды и CDN отдают одну ожидаемую версию.

• Внешний мониторинг проверяет фактический TLS-ответ, а не наличие файла.

Источники и поведение Certbot и Let’s Encrypt проверены 5 ноября 2026 года. У другого ACME-клиента названия параметров и hooks могут отличаться, поэтому переносить шаги механически не стоит.

If a certificate is nearing expiration, a single "auto-renewal enabled" status is insufficient. Verify five distinct stages: job initiation, domain validation, certificate issuance, installation in the service, and the certificate actually served to visitors. A failure at any step leaves the browser with the old expiration date, even if the control panel appears reassuring.

TLS automation is a chain, not a single button. The scheduler launches the ACME client, the certificate authority validates domain control, the client receives the new certificate, the service applies it, and load balancers and CDN begin serving the new version. Therefore, identify the failing stage first, then adjust settings.

Here is the interesting part: a successful exit code does not prove that a new certificate has been issued. The documentation for Certbot states that the update command can complete with code 0 even when certificates have not yet reached the renewal threshold. You need the log of the specific attempt, the new serial number, and a later expiration date.

First, record what an external client sees, not what is stored as a file on the server. This is the starting point for discussions with the hosting provider or administrator.

• Hostname, port, and the exact time of the check.

• Issuer, serial number or fingerprint, and start and end dates.

• List of names in the certificate and chain completeness.

• Public endpoint: origin server, load balancer, CDN, or other frontend.

• Result for each endpoint when a single domain is served by multiple nodes.

For the first external check, use the SSL certificate checker tool: it shows the certificate actually being served. However, a single result does not verify all nodes behind the load balancer, so a distributed setup requires a list of endpoints and a repeatable check for each.

In the Let's Encrypt verification description, HTTP-01 is tied to the availability of a helper file via port 80. If multiple frontends handle requests, the verification file must be accessible on each of them or routed to a single agreed location.

For DNS-01, the certificate authority searches for the TXT record _acme-challenge. The most common issues are DNS propagation delays, an incorrect zone, or overly broad and outdated DNS provider credentials. Let's Encrypt's Integration Guide for Integrators specifically recommends designing certificate storage and challenge delivery for multiple frontends rather than relying on a local file on a single node.

• For HTTP-01, verify that port 80 is accessible from outside and that the challenge is issued consistently across all frontends.

• For DNS-01, confirm which system updates the TXT record, whether the new record is visible to authoritative servers, and whether the key's permissions are restricted to the required zone.

• For each name in the certificate, verify a separate successful result: one successful domain does not validate the others.

The CAA record answers a different question: which certificate authorities are permitted to issue certificates for the domain. According to RFC 8659, this is a restriction on issuance, not a browser check or a confirmation of auto-renewal health. The current CAA record may be correct, yet the challenge or installation can still fail.

After successfully issuing the certificate, verify the path from the file to the web server process. Certbot can only obtain the certificate; applying it to the web server is done by the installer or a deploy-hook. Such a hook runs after successful renewal; an error, incorrect path, or failure to apply the configuration as expected will leave the service on the old file.

Independently check the CDN, load balancer, and each frontend. A certificate on the origin server does not automatically update the certificate on an external CDN. In a cluster, one node may retain the old version, so random checks will intermittently pass or show an approaching expiration date.

1. Assign a certificate owner and compile a list of domain names, public endpoints, and systems where TLS terminates.

2. Compare the schedule and the log of the last attempt. The absence of a recent attempt indicates a problem before contacting the certificate authority.

3. Ask the administrator to perform a standard trial check via the certificate authority's staging environment. For a Certbot dry-run, verify receipt of a test certificate; installation must be checked separately, taking configured hooks into account.

4. Confirm the selected challenge and its conditions: port 80 and routing for HTTP-01, or a TXT record, propagation, and minimum permissions for DNS-01.

5. After actual renewal, compare the serial number, dates, and chain first in the service, then at each external endpoint.

6. Configure a certificate warning based on the certificate actually served externally, allowing sufficient time for manual correction.

Auto-renewal can be considered accepted when there is a fresh successful attempt for all names, a new certificate has been obtained, is applied normally, and each public endpoint serves the expected serial number and a later expiration date. Additionally, an external warning must trigger before the remaining time becomes critical.

• The scheduler runs on the expected node.

• The ACME challenge passes for each name.

• A new certificate with verifiable dates and serial number has been obtained.

• The service applied exactly the new file without an unplanned stop.

• All frontends and CDN serve the same expected version.

• External monitoring checks the actual TLS response, not just the presence of the file.

Sources and behavior of Certbot and Let's Encrypt were verified on November 5, 2026. For other ACME clients, parameter names and hooks may differ, so do not mechanically transfer steps.