Продление домена и TLS-сертификата: зоны ответственности и проверки

Редакция Romanov Lab · Обновлено 13 октября 2026

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

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

Разделите четыре зоны ответственности

• Регистрация домена: право использования имени, срок регистрации, оплата и контактные данные владельца.
• DNS: записи, которые направляют посетителей и почту к нужным сервисам.
• Выпуск сертификата: подтверждение контроля домена и получение сертификата у удостоверяющего центра.
• Установка сертификата: применение на CDN, балансировщике или сервере, который обслуживает соединение.

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

Составьте реестр доменов и точек входа

Запишите основной домен, вариант с www, рабочие поддомены, регистратор, DNS-провайдер и места завершения TLS. Для каждого имени определите назначение: сайт, почта, API, личный кабинет или перенаправление. Забытый адрес рекламной страницы тоже может потребовать действующего сертификата, даже если он только перенаправляет посетителя.

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

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

Практическая карточка контроля домена

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

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

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

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

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

ICANN рекомендует продлевать регистрацию до истечения срока и разъясняет, что возможности восстановления зависят от условий. Правила конкретной зоны и регистратора проверяют отдельно; положения для общих доменных зон нельзя автоматически переносить на все национальные зоны. Ожидание льготного периода не должно быть обычным способом обслуживания.

После оплаты убедитесь, что срок регистрации действительно обновлён. Квитанция подтверждает операцию, но для эксплуатации важен статус нужного домена. Проверьте также доступность основного сайта и почты, особенно если истечение регистрации уже повлияло на DNS.

Разберите цепочку автоматического выпуска

Для сертификата важно знать используемый ACME-клиент или управляемую функцию платформы. В актуальном руководстве Let’s Encrypt рекомендуется автоматизация продления с использованием ACME Renewal Information, когда она поддерживается. Практический регламент должен опираться на возможности клиента и текущую документацию, а не на ручное напоминание о каждом выпуске.

Проверьте, как подтверждается контроль домена. При HTTP-01 специальный проверочный ресурс должен быть доступен по предусмотренному маршруту; изменения редиректов, прокси или конфигурации могут нарушить этот путь. При DNS-01 создаётся проверочная TXT-запись, поэтому важны работоспособность автоматизации DNS и время распространения изменений. Подробности обоих механизмов описаны в документации Let’s Encrypt.

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

Что проверить после смены DNS-провайдера

Перенос DNS способен затронуть сайт, почту и автоматическое подтверждение домена. До изменения составьте перечень нужных записей и их владельцев. После переноса проверьте основные имена, почтовые маршруты и конкретный механизм выпуска сертификата. Для DNS-01 важно, чтобы автоматизация могла создать TXT-запись в актуальной зоне, а не продолжала обращаться к старому провайдеру.

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

Отделите выпуск от установки

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

• Имя сайта присутствует среди допустимых имён сертификата.
• Период действия нового сертификата соответствует ожидаемому результату.
• Клиент получает корректную цепочку доверия без предупреждений.
• Основной домен, www и используемые поддомены проверены отдельно.
• При нескольких точках обслуживания обновление проверено на каждой из них.
• HTTP-перенаправления ведут на рабочий HTTPS-адрес без цикла.

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

Учебный пример: сертификат выпущен, но сайт выдаёт предупреждение

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

В другом сценарии новый сертификат установлен для основного имени, но старый остался на втором балансировщике. Ошибка тогда может проявляться лишь у части соединений. Поэтому в реестре нужны не только доменные имена, но и точки завершения TLS. Для управляемой платформы используйте её доступные проверки и документацию; для собственной инфраструктуры закрепите процедуру проверки каждого узла.

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

Диагностическая развилка при ошибке HTTPS

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

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

Закрепите регламент и передачу ответственности

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

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

Источники

• Let’s Encrypt: руководство по интеграции
• Let’s Encrypt: способы подтверждения домена
• ICANN: продление и окончание регистрации
• MDN: устройство защищённого соединения TLS