SiteGuard4 ноября 202617 мин чтения

Истёк SSL-сертификат: как продлить его и проверить автопродление

Если истёк SSL-сертификат, нужно выпустить новый сертификат, установить его в сервис, который принимает HTTPS-соединения, и проверить результат снаружи. Оплата продления, успешный выпуск и обновление сертификата на работающем сайте — три разных события. Предупреждение исчезнет только после того, как посетитель начнёт получать подходящий действующий сертификат с корректной цепочкой доверия.

Ошибка мешает посетителям открывать страницы, отправлять заявки и пользоваться личным кабинетом. Ниже — порядок восстановления HTTPS для управляемого хостинга, платных сертификатов и собственного сервера с Let's Encrypt и Certbot, а также проверка защиты от повторного сбоя.

Истёк SSL-сертификат: что делать в первую очередь

Назначьте ответственного и зафиксируйте точный адрес с ошибкой: например, https://www.example.com/. Проверьте основной домен, www и важные поддомены: они могут обслуживаться разными сертификатами.

Подтвердите истечение. Посмотрите дату окончания именно того сертификата, который предъявляет сайт, и сравните её с корректным текущим временем.
Найдите место управления. Это может быть панель хостинга, CDN, облачный балансировщик или ACME-клиент на вашем сервере.
Определите, где остановился процесс. Новый сертификат не заказан, проверка домена не завершена, выпуск закончился ошибкой либо готовый сертификат ещё не применён.
Исправьте конкретный этап. Запустите штатное продление или повторите неудачную операцию после устранения причины. Запишите результат и время.
Проверьте публичный HTTPS. Убедитесь, что нужный домен получает новый сертификат, а ключевые действия на сайте работают.
Восстановите автоматизацию. Проверьте следующий запуск, обработку ошибок и уведомление ответственного.

Не просите клиентов обходить предупреждение браузера и не переводите формы с персональными данными на HTTP. Не начинайте инцидент с удаления сертификатов, смены DNS-провайдера или переустановки сервера: такие действия расширяют задачу и затрудняют поиск исходной причины.

Как понять, что закончился именно срок действия SSL

В сертификате есть две даты: Not Before и Not After. Они задают начало и конец периода действия, как определено в RFC 5280. Учитывайте часовой пояс отображения: утилита может показывать GMT, а браузер — локальное время. Фраза «действует до сегодняшнего числа» без часов и минут не описывает точный момент окончания.

Проверяйте сертификат из нового подключения к проблемному адресу. Файл, скачанный из личного кабинета, может быть свежим, хотя сервер продолжает отправлять старый. И наоборот: в панели может оставаться старый заказ, когда новый сертификат уже работает на CDN.

Что обнаружено	Что это означает для восстановления
У предъявленного сертификата прошёл `Not After`	Нужен действующий сертификат и его применение в соответствующей точке HTTPS
Новый сертификат уже выпущен, но снаружи виден прежний	Ищите ошибку установки, выбора виртуального хоста, обновления узлов или перезагрузки конфигурации
Дата действующая, но имя сайта не соответствует сертификату	Проверьте SAN, SNI и привязку сертификата к нужному имени; простое продление с прежними параметрами может ничего не изменить
Проблема наблюдается только на одном устройстве	Сравните время, доверенные центры и сетевой путь этого устройства с независимой проверкой
Ошибка относится к промежуточному сертификату	Проверьте установленную цепочку, а не только дату сертификата самого сайта

Неверные часы устройства тоже могут вызывать ошибки срока действия. Такой случай отдельно разобран в справке Firefox. Если проблема подтверждается с нескольких независимых устройств с правильным временем, продолжайте проверку серверной стороны. Если у отдельных пользователей отличаются симптомы, сохраняйте точные коды ошибок: они помогают разделить несколько неисправностей.

Где продлевать сертификат: хостинг, CDN или свой сервер

Уточните, куда приходит посетитель и где завершается TLS-соединение. Регистратор домена не обязательно управляет сертификатом: сайт, DNS и публичный HTTPS могут обслуживаться разными компаниями.

Схема	Где искать продление	Что подтвердить
Конструктор или управляемый хостинг	Настройки домена и HTTPS в панели платформы	Домен подключён, условия выпуска выполнены, сертификат активирован для нужного сайта
Собственный VPS с Certbot	ACME-клиент, сохранённая конфигурация и планировщик на сервере	Проверка домена проходит, новый сертификат сохранён и загружен веб-сервером
Платный сертификат, установленный вручную	Личный кабинет поставщика и конфигурация сервера	Заказ активирован, проверки пройдены, новые файлы действительно установлены
CDN перед исходным сервером	Сертификат на стороне CDN и отдельно сертификат исходного сервера	Проверен каждый участок соединения и назначен ответственный за каждый сертификат
Несколько балансировщиков или серверов	Система распространения сертификатов по узлам	Все активные точки завершения TLS обновлены; нет узла со старой копией

Например, документация Cloudflare различает edge-сертификат, который видит браузер, и origin-сертификат на исходном сервере. У них могут быть разные издатели, сроки и способы обновления. Успешное продление одного не доказывает исправность другого.

Как продлить SSL-сертификат на управляемом хостинге

Если сертификатом управляет платформа, используйте её штатный механизм продления.

Откройте настройки именно проблемного сайта и найдите раздел домена, HTTPS или сертификатов.
Проверьте статус подключения домена и актуальные требования платформы к DNS. Особенно внимательно сравните основной домен и www.
Посмотрите статус сертификата: ожидает проверки, выпускается, активен, не продлён или требует действий. Сохраните полный текст ошибки.
Если предусмотрена повторная проверка или продление, сначала устраните указанную причину, затем запустите операцию один раз.
Дождитесь результата операции и проверьте сайт независимо от панели. В заявке поддержке просите подтвердить и выпуск, и применение сертификата.

Названия кнопок и условия автоматизации зависят от провайдера. Уточняйте их в инструкции для своего продукта: правила виртуального хостинга, конструктора и облачного балансировщика могут различаться даже у одной компании.

Для поддержки подготовьте адрес с ошибкой, время проверки, дату окончания предъявленного сертификата, статус в панели и недавние изменения DNS или CDN. Укажите, затронут ли один поддомен или весь проект.

Как продлить платный SSL-сертификат

У оплаченной услуги и у конкретного сертификата могут быть разные сроки. Продление подписки или заказа не означает, что браузер немедленно получит новый сертификат. Например, Рег.ру описывает продление как оформление услуги, активацию и установку нового сертификата; автоматизация доступна на определённых условиях.

Что проверить перед заказом

Какие имена должны входить в сертификат: основной домен, www, дополнительные поддомены.
Где будет создан и сохранён приватный ключ и кто отвечает за установку.
Как подтверждается контроль домена и доступны ли необходимые DNS-записи или другие выбранные способы проверки.
Нужны ли дополнительные действия для проверки организации в выбранном продукте.
Входит ли установка на ваш сервер в услугу или её выполняет администратор отдельно.

Согласуйте полный перечень имён до отправки запроса: выпуск для example.com не заменяет сертификат отдельного pay.example.com.

Последовательность продления

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

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

Отдельно выясните смысл переключателя «Автопродление». Он может относиться к оплате услуги, выпуску или к полному циклу с установкой в определённом хостинге. Запишите границы автоматизации, чтобы платёж не создавал ложного ощущения, что техническая часть завершена.

Как продлить Let's Encrypt на собственном сервере

Команды предназначены для администратора сервера, где сертификат уже обслуживается Certbot. Если им управляет панель или другой ACME-клиент, используйте инструкции этой системы.

1. Найдите нужный сертификат

certbot --version
sudo certbot certificates

Сопоставьте Certificate Name, список доменов, срок и путь с конфигурацией действующего сайта. Имя записи Certbot может отличаться от домена, например иметь суффикс -0001. В следующих командах example.com — пример имени записи, которое нужно заменить точным значением из вывода.

2. Проверьте сохранённый способ продления

По руководству Certbot, команда renew использует сохранённые плагины и параметры. Уточните, что применялось ранее: Nginx, Apache, webroot, standalone или DNS-плагин. Если после переноса сайта каталог, веб-сервер или DNS-провайдер изменились, старая схема может больше не работать.

Просмотрите ошибку в журнале, обычно /var/log/letsencrypt/letsencrypt.log, если пути не переопределены. Исправьте её причину; не редактируйте файлы продления наугад и не удаляйте состояние клиента.

3. Проверьте процесс тестовым запуском

sudo certbot renew --cert-name example.com --dry-run

--dry-run по умолчанию проверяет выпуск через тестовую среду Let's Encrypt и не устанавливает полученный тестовый сертификат вместо рабочего. Явный параметр --server в команде или конфигурации может изменить используемый сервер. Перед запуском проверьте настройки и существующие хуки — команды, связанные с процедурой обновления.

Тест не является полностью пассивной проверкой: возможны временные изменения конфигурации и reload веб-сервера; pre- и post-хуки запускаются по умолчанию. Deploy-хуки без отдельного включения не выполняются. Эти ограничения приведены в описании параметров Certbot. Учитывайте их, если хуки останавливают службы или изменяют внешнюю инфраструктуру.

4. Выполните обычное продление

sudo certbot renew --cert-name example.com

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

Как проверить автопродление Let's Encrypt

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

Проверьте планировщик, который установлен в вашей системе

В официальной инструкции Certbot указано, что поставка может включать задание cron или таймер systemd. Способ установки определяет, где искать расписание. На Linux с systemd начните с просмотра таймеров:

systemctl list-timers --all

Найдите задание, которое запускает ваш Certbot, и посмотрите время последнего и следующего запуска. Затем откройте состояние связанной службы и её журнал, используя фактическое имя из системы. У установки через snap имя отличается от имени в некоторых пакетах дистрибутива; отсутствие именно certbot.timer ещё не доказывает отсутствие автоматизации.

Для cron проверьте системные задания и crontab нужного пользователя; в контейнерах — внешний планировщик. Сначала найдите существующее расписание.

Сравните ручной и автоматический запуск

Сравните путь к программе, версию, исполнителя, права, доступ к DNS-учётным данным и сети. Например, вручную может запускаться новый Certbot, а старое задание обращаться к другому пути. Проверьте фактический результат штатного задания и получение сообщения о его неудаче.

Учитывайте изменение сроков действия

Не закрепляйте в инструкции универсальное правило «продлевать раз в 60 дней». Подходящий момент зависит от срока конкретного сертификата, возможностей клиента и ACME Renewal Information — ARI. Этот механизм позволяет центру сообщать клиенту рекомендуемое окно обновления.

В анонсе Let's Encrypt от 7 октября 2026 года стандартный переход на сертификаты сроком 64 дня назначен на 10 февраля 2027 года; доступны и более короткие профили. Для эксплуатации важнее читать реальные даты и поддерживать клиент в актуальном состоянии, чем вручную рассчитывать календарь по старому сроку. Регулярный запуск клиента не означает, что он обязан выпускать новый сертификат при каждой проверке.

Почему SSL-сертификат не продлевается автоматически

Ищите причину по последней неуспешной попытке. Состояние «ожидает проверки» отличается от ошибки скачивания сертификата, а успешный выпуск — от ошибки применения. Таблица помогает выбрать проверку, которая соответствует этапу сбоя.

Симптом	Что проверить	Следующее действие
HTTP-проверка получает 404 или чужую страницу	Адреса DNS, маршрут `/.well-known/acme-challenge/`, выбранный webroot и правила прокси	Обеспечить выдачу проверочного ответа из нужного места
Соединение при HTTP-проверке не устанавливается	Порт 80, firewall, NAT и доступность сайта извне	Восстановить предусмотренный доступ или согласованно перейти на другой поддерживаемый способ проверки
IPv4 работает, но проверка домена не проходит	Запись AAAA и сервер, отвечающий по IPv6	Исправить несоответствующую маршрутизацию и проверочный ответ по IPv6
DNS-проверка не находит нужный TXT	Авторитетные DNS-серверы, правильную зону, полномочия токена и публикацию записи	Восстановить автоматическое создание записи и дождаться её доступности для проверки
Ошибка CAA или SERVFAIL	Политику разрешённых центров, доступность DNS и корректность DNSSEC	Исправить конкретную DNS-проблему с ответственным за зону
Ручной выпуск успешен, фоновый — нет	Исполнителя, пути, окружение и права задания	Исправить штатный автоматический процесс и проверить его результат
Новый сертификат есть на диске, ошибка остаётся	Загруженный сертификат, пути, reload, CDN и все узлы	Завершить установку и повторить внешнюю проверку

HTTP-01: сайт должен отдать правильный проверочный ответ

В HTTP-01 проверка начинается на порту 80. Проверочный путь не должны перехватывать авторизация, CAPTCHA или неподходящее правило прокси. Ответ должен быть доступен на всех фронтендах, куда может попасть проверка.

Отдельная ловушка — устаревшая запись AAAA. Let's Encrypt при наличии IPv4 и IPv6 сначала предпочитает IPv6; успешный ответ неправильного IPv6-сервера не означает обязательного повторения через IPv4. Подробности описаны в документации поддержки IPv6. Исправьте конфигурацию адресов осознанно, учитывая пользователей, которые уже подключаются по IPv6.

DNS-01: ручное добавление TXT не равно автоматизации

Ручное добавление TXT при первом выпуске не обеспечивает автоматическое обновление. Нужен поддерживаемый DNS-плагин или автоматические хуки. Проверьте действительность учётных данных, нужную зону и ограниченные права; не публикуйте API-токен в журнале или переписке.

Wildcard-сертификаты Let's Encrypt требуют DNS-01. После смены DNS-провайдера убедитесь, что плагин работает с авторитетной зоной, а не со старой копией.

CAA, DNSSEC и повторные попытки

CAA определяет, каким центрам разрешён выпуск для домена. Ошибка получения CAA тоже может блокировать процедуру, даже если владелец намеренно не создавал таких записей. Причины SERVFAIL, включая проблемы DNSSEC, разобраны в справке Let's Encrypt по CAA. Исправляйте подписи, делегирование или ответы DNS с провайдером, не отключая защитные механизмы вслепую.

Для отладки используйте тестовую среду; при ограничении запросов следуйте указанному времени повторения. Правила лимитов различают продления через ARI и другие запросы. Бесконечные повторные попытки не исправляют неверный DNS.

Новый сертификат выпущен: как убедиться, что он установлен

Если сервис читает старый файл или держит прежний сертификат в памяти, успешный выпуск не меняет ответ сайта.

Для собственной инфраструктуры проверьте путь к сертификату, соответствующий приватный ключ, промежуточную цепочку и механизм применения. В контейнере убедитесь, что новые файлы доступны внутри контейнера, а не только на хосте. Если сертификаты копируются на балансировщик или несколько серверов, проверьте доставку и активацию на каждом адресате.

Пример для Nginx

В документации HTTPS для Nginx отдельно заданы файл сертификата и файл ключа; в файле цепочки сертификат сайта должен предшествовать промежуточным. Используйте комплект именно нового выпуска и согласованные пути. Не заменяйте ключ посторонним файлом и не делайте его общедоступным ради устранения ошибки доступа.

Для обычной установки Nginx, где команда обращается к той же конфигурации, что и работающий сервер, сначала проверьте конфигурацию:

sudo nginx -t

Если проверка успешна, примените изменения штатным способом. В такой установке это может быть:

sudo nginx -s reload

Параметры -t и -s reload описаны в справке Nginx. При нестандартных путях, нескольких экземплярах или управлении через контейнер используйте команду для конкретного процесса. После reload проверьте журнал и новый ответ сайта: успешная проверка синтаксиса не доказывает, что выбран правильный виртуальный хост.

Проверьте применение при следующем автоматическом обновлении

Если установку выполняет поддерживаемый плагин, проверьте его результат. Если используется собственный deploy-hook, он должен применяться после успешного выпуска, работать с нужным сервисом и сообщать об ошибке. Не добавляйте второй reload «на всякий случай», пока не выяснили, как уже устроена установка.

Обычный --dry-run deploy-хуки не запускает. В Certbot параметр --run-deploy-hooks позволяет отдельно проверить их после успешного теста, причём используется текущий активный сертификат, а не временный тестовый. Такой запуск действительно выполняет ваши команды применения; сначала прочитайте их и оцените последствия для сервисов. Семантика параметра приведена в официальной справке.

Что проверить после продления SSL-сертификата

Проверяйте снаружи реальные имена и порты: главный сайт, www, личный кабинет, API и другие используемые HTTPS-сервисы.

Короткая техническая проверка

В интерактивном терминале Linux/macOS с OpenSSL и корректным хранилищем доверенных центров можно проверить соединение так:

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error

-servername передаёт имя через SNI, -verify_hostname включает сопоставление имени, а -verify_return_error не позволяет проигнорировать ошибку проверки сертификата. Назначение параметров описано в документации OpenSSL. Изучайте итог проверки и причины ошибок; хранилище доверия OpenSSL может отличаться от браузерного.

Не перенаправляйте ввод из /dev/null для этой основной проверки: документация предупреждает о возможном преждевременном закрытии при конце ввода, особенно с TLS 1.3. Дождитесь завершения TLS-рукопожатия и результата верификации, сохраните вывод и завершите сеанс клавишами Ctrl+C. Одной строки CONNECTED недостаточно. При незавершённом обмене сохраните последний этап и прервите ожидание, не делая вывода об исправности сертификата. Команда проверяет TLS-соединение; загрузку страницы и пользовательские действия проверьте отдельно.

Откройте предъявленный сертификат в браузере и запишите Not After, имена и при необходимости отпечаток. Чтение даты локального файла не заменяет эту проверку: на публичном сервере может использоваться другая копия.

Чек-лист приёмки

У предъявленного сертификата действующие даты; новый Not After зафиксирован.
Нужные имена входят в SAN, а запрос попадает в правильную конфигурацию SNI.
Цепочка доверия проходит проверку в целевых браузерах и клиентах.
Все активные адреса IPv4 и IPv6 и все управляемые узлы выдают подходящий сертификат.
При CDN проверены публичная сторона и защищённое подключение к origin по правилам провайдера.
Открываются ключевые страницы, работает авторизация и проверены основные пользовательские сценарии.
В журналах нет новой ошибки применения сертификата, а автоматическое задание имеет следующий запуск.

Для балансировщика одна загрузка страницы не покрывает все узлы. Сопоставьте результаты по известным точкам проверки. Разные допустимые сертификаты могут использоваться намеренно; важна корректность каждого маршрута, а не обязательное совпадение отпечатков во всех сетях.

Как не допустить повторного истечения

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

Контроль	Что он помогает обнаружить	Кто получает сигнал
Внешняя проверка сертификата нужного имени	Приближение окончания и неверный сертификат, который реально виден пользователю	Ответственный за доступность сайта
Результат попытки ACME или операции в панели	Сбой проверки домена и выпуска до наступления срока	Администратор или поддержка провайдера
Результат доставки и применения	Новый файл получен, но сервис продолжает работать со старым	Владелец инфраструктуры
Состояние планировщика	Задание отключено, потеряло доступ или больше не запускается	Ответственный за сервер
Проверка после переноса и изменения DNS	Старая схема валидации не соответствует новому размещению	Исполнитель изменений

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

Не рассчитывайте на письмо от Let's Encrypt об истечении. Сервис таких уведомлений завершил работу 4 июня 2025 года, что подтверждено официальным объявлением. Настройте собственные уведомления или подходящую внешнюю проверку и убедитесь, что сообщение доходит до действующего ответственного.

Сохраните инструкцию: ответственные, доступы к DNS и серверу, расположение журнала и порядок проверки. После смены подрядчика, хостинга, CDN или DNS обновляйте её и проверяйте автоматизацию повторно.

Что передать специалисту для восстановления HTTPS

Подготовьте список доменов, хостинг и CDN, издателя, текущий Not After, ошибку из журнала и время последней успешной проверки. Укажите, выпущен ли новый сертификат и где находится. Приватные ключи, пароли и токены передавайте через согласованный защищённый механизм доступа, а не в обычном описании задачи.

Хотите системно подойти к защите и стабильности сайта? Перейдите на SiteGuard и сопоставьте доступные решения с задачами своего проекта. Используйте приведённый чек-лист, чтобы обсуждать конкретный результат: работающий HTTPS сегодня и проверяемый процесс обновления в дальнейшем.

Частые вопросы о продлении SSL

Можно ли изменить дату окончания в старом сертификате?

Рабочее продление предполагает получение нового подписанного сертификата. Редактирование даты в существующем файле не даёт действующей подписи удостоверяющего центра. После выпуска новый сертификат необходимо применить там, где обслуживается HTTPS.

Я оплатил SSL, почему браузер всё ещё показывает ошибку?

Проверьте статус активации и проверок, затем факт выпуска и установки. Если новый сертификат уже готов, сравните его с тем, который предъявляет сайт. Частая область поиска — отдельный CDN, балансировщик, старый путь к файлу или узел, до которого обновление не дошло.

Нужно ли платить за продление Let's Encrypt?

Сам Let's Encrypt не взимает плату за сертификаты, что указано в официальном FAQ. Работа администратора, услуги хостинга или сопровождение могут оплачиваться отдельно по условиям выбранного поставщика.

Успешный dry-run гарантирует, что следующее продление пройдёт?

Нет: до следующего запуска могут измениться DNS, доступы или расписание. Проверяйте автоматизацию, применение и внешний срок отдельно; учитывайте ограничения теста, описанные выше.

Нужно ли ждать истечения, чтобы обновить сертификат?

Нет. Плановый процесс должен завершаться заранее и оставлять время на исправление сбоя. Используйте штатную логику ACME-клиента или правила своего поставщика. Фактический срок нового сертификата проверяйте после выпуска, не предполагая, что к нему автоматически добавятся оставшиеся дни старого.

Можно ли временно выключить HTTPS, чтобы сайт открылся?

Это не восстанавливает защищённые подключения и может нарушить работу клиентов, которым требуется HTTPS. Исправляйте выпуск и применение сертификата. Пользователям не следует предлагать игнорировать предупреждения или отправлять чувствительные данные по незащищённому соединению.

Документация и актуальность

Материал проверен 31 октября 2026 года. Интерфейсы хостингов и сроки сертификатов меняются; для конкретной установки сверяйте актуальные инструкции поставщика и реальные даты сертификата.