Закончился срок домена или SSL-сертификата

Как восстановить сайт, почту и безопасное соединение и не допустить повторной остановки

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

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

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

Разберём, как определить причину, восстановить работу и организовать контроль сроков.

Домен и SSL-сертификат — не одно и то же

Путаница возникает потому, что оба объекта связаны с адресом сайта и имеют срок действия.

Доменное имя

Домен — это адрес вида example.ru. Он регистрируется через регистратора в определённой доменной зоне. Регистратор передаёт необходимые сведения в реестр зоны, а владелец управляет продлением, контактами и DNS-серверами.

Через DNS домен может направлять:

• основной сайт;
• поддомены;
• корпоративную почту;
• API;
• личные кабинеты;
• VPN и другие внутренние сервисы;
• механизмы подтверждения прав и выпуска сертификатов.

Если регистрация прекращается и DNS перестаёт обслуживаться, проблема затрагивает не один HTML-сайт, а всю инфраструктуру, использующую имя.

SSL/TLS-сертификат

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

Сертификат может покрывать:

• один домен;
• домен и вариант с www;
• несколько конкретных поддоменов;
• поддомены по маске при использовании wildcard-сертификата.

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

Как быстро понять, что именно закончилось

Признаки просроченного домена

• домен не разрешается в IP-адрес;
• вместо сайта показывается страница регистратора или сообщение о просрочке;
• перестали работать сразу сайт, поддомены и корпоративная почта;
• в панели регистратора статус указывает на окончание регистрации;
• сведения реестра показывают особый статус истёкшего или удаляемого домена;
• DNS-серверы или записи изменились без действий технической команды.

Признаки просроченного сертификата

• домен разрешается и сервер отвечает;
• браузер сообщает, что соединение не защищено или сертификат просрочен;
• техническая проверка показывает прошедшую дату Not After;
• по HTTP сервер может отвечать, но HTTPS вызывает ошибку;
• часть клиентов или интеграций прекращает подключение из-за ошибки TLS.

Проблемы могут совпасть

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

Первые действия при любой из двух аварий

До изменения настроек соберите минимальную картину инцидента.

1. Зафиксируйте время первого сообщения о проблеме.
2. Проверьте сайт с нескольких сетей и устройств.
3. Сохраните точный текст ошибки и скриншот.
4. Уточните, работает ли корпоративная почта.
5. Проверьте основной домен, www и важные поддомены.
6. Узнайте, проводились ли изменения у регистратора, DNS-провайдера, хостинга или CDN.
7. Назначьте одного координатора восстановления.
8. Не передавайте пароли и секретные ключи через обычную переписку.
9. Не советуйте клиентам обходить предупреждение браузера.

Если сайт принимает оплату, персональные данные или используется для авторизации, попытка «временно разрешить небезопасное подключение» особенно недопустима.

Если закончился срок регистрации домена

Что происходит после истечения срока

Точный жизненный цикл зависит от доменной зоны, регистратора и договора. Нельзя рассчитывать на единый для всех доменов льготный срок.

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

Для доменов .RU и .РФ Координационный центр описывает период преимущественного продления. Однако и здесь актуальные сроки и порядок операции следует уточнять у действующего регистратора и в текущих правилах зоны.

Возможные состояния выглядят так:

1. Срок закончился, но обычное продление ещё доступно. Домен может уже не обслуживать сайт и почту, однако прежний администратор сохраняет возможность продлить его.
2. Домен перешёл в период восстановления. Возврат может выполняться только через текущего регистратора и стоить дороже обычного продления.
3. Ожидается окончательное удаление. Изменение и перенос домена часто ограничены.
4. Домен освободился. Его может зарегистрировать другое лицо в соответствии с правилами зоны и регистратора.

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

Шаг 1. Найдите действующего регистратора

Проверьте:

• старые счета и уведомления;
• договоры;
• кабинет, где домен приобретался;
• данные регистрационной службы соответствующей зоны;
• сведения в реестре или WHOIS/RDAP, если они доступны.

Не путайте регистратора с хостинг-провайдером и разработчиком. Иногда одна компания предоставляет все услуги, но юридически и технически это разные объекты.

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

Шаг 2. Проверьте статус домена

В кабинете или через официальную службу данных уточните:

• дату окончания регистрации;
• текущий статус;
• можно ли выполнить обычное продление;
• действует ли период восстановления;
• стоимость операции;
• не началось ли удаление;
• кто указан администратором;
• какие DNS-серверы назначены;
• не установлены ли ограничения или блокировки.

Технический сотрудник не должен делать вывод только по сообщению браузера. Страница-заглушка регистратора, отсутствие DNS и серверная ошибка требуют разных действий.

Шаг 3. Продлите или восстановите домен

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

Перед оплатой убедитесь, что:

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

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

Шаг 4. Проверьте DNS после продления

Оплата не всегда мгновенно восстанавливает все сервисы. Нужно проверить:

• вернулись ли прежние DNS-серверы;
• сохранились ли записи A, AAAA, CNAME;
• корректны ли почтовые записи MX;
• сохранены ли TXT, включая SPF, DKIM, DMARC и подтверждения сервисов;
• работают ли поддомены;
• не осталась ли парковочная страница регистратора;
• нет ли чужих или неожиданных записей.

Изменения DNS распространяются не мгновенно. Разные рекурсивные серверы и провайдеры могут обновить кеш в разное время в пределах заданного TTL и фактической работы кешей. Поэтому сайт способен открываться у одного сотрудника и не открываться у другого.

Не стоит хаотично менять записи несколько раз подряд. Это усложняет диагностику и может продлить нестабильность.

Шаг 5. Восстановите сайт и поддомены

После возвращения DNS проверьте:

• главную страницу;
• ключевые разделы;
• вариант с www и без него;
• редирект с HTTP на HTTPS;
• формы и отправку уведомлений;
• личные кабинеты;
• API;
• платёжные страницы;
• CDN;
• статические ресурсы;
• внешние интеграции, проверяющие домен.

Не ограничивайтесь одной страницей в собственном браузере: локальный кеш может скрывать реальную ситуацию.

Шаг 6. Проверьте корпоративную почту

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

После восстановления:

• проверьте MX;
• отправьте тестовые письма с внешних почтовых систем;
• проверьте исходящую отправку;
• убедитесь в наличии SPF, DKIM и DMARC;
• изучите журналы и очередь почтового сервера;
• предупредите сотрудников о возможных недоставленных сообщениях;
• при необходимости попросите ключевых клиентов повторить отправку.

Нельзя гарантировать, что вся корреспонденция за время остановки автоматически придёт позднее.

Шаг 7. Проверьте SSL-сертификат

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

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

Если сертификат выпускался через проверку DNS, восстановление нужных TXT или прав API также может быть критичным.

Если домен уже зарегистрировал другой человек

Если имя освободилось и было зарегистрировано заново, прежний владелец не может просто «продлить» его в старом кабинете.

Необходимо:

1. Зафиксировать текущие регистрационные данные и содержание сайта.
2. Проверить права на товарный знак и фирменное наименование.
3. Не вступать в сомнительные сделки и не передавать документы неизвестным посредникам.
4. Обратиться к профильному юристу и регистратору.
5. Оценить предусмотренные для зоны процедуры спора.
6. Параллельно подготовить план перехода на другой домен, если быстро вернуть имя невозможно.

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

Если закончился срок SSL-сертификата

Что видит посетитель

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

Последствия:

• посетители закрывают страницу;
• формы и личные кабинеты становятся недоступны;
• API-клиенты и мобильные приложения отвергают соединение;
• платёжные и внешние системы прекращают обмен;
• поисковый робот может зафиксировать ошибку;
• автоматические проверки доступности сообщают об аварии;
• снижается доверие к компании.

Если для домена включён HSTS, браузер может не предложить пользователю кнопку обхода предупреждения. Это правильное защитное поведение, а не дополнительная ошибка.

Не переводите сайт временно на HTTP

Попытка убрать HTTPS и оставить незашифрованный HTTP обычно создаёт больше проблем:

• данные передаются без необходимой защиты;
• сохранённая политика HSTS всё равно заставляет браузер использовать HTTPS;
• ломаются безопасные cookie и функции, требующие защищённого контекста;
• возникают смешанный контент и неправильные редиректы;
• поисковые системы видят смену протокола;
• внешние интеграции продолжают ожидать HTTPS.

Правильное решение — выпустить и корректно установить действующий сертификат.

Шаг 1. Определите, какой сертификат реально отдаёт сервер

Нужно проверить внешний ответ для каждого имени:

• основного домена;
• варианта с www;
• поддоменов;
• API;
• почтовых и иных TLS-сервисов.

Смотрите:

• дату окончания;
• список имён в SAN;
• издателя;
• серийный номер;
• цепочку промежуточных сертификатов;
• сервер или узел, который фактически завершает TLS-соединение.

Последний пункт особенно важен. Сертификат может быть установлен не на веб-сервере приложения, а на CDN, балансировщике, reverse proxy, панели хостинга или внешнем защитном сервисе.

Шаг 2. Выясните способ выпуска и продления

Возможные варианты:

• автоматическая выдача хостинг-провайдером;
• ACME-клиент на сервере;
• сертификат CDN;
• платный сертификат, продлеваемый через удостоверяющий центр;
• ручной выпуск и установка;
• сертификат в облачном балансировщике;
• wildcard-сертификат через DNS-подтверждение.

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

Шаг 3. Выпустите новый сертификат

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

Распространённые способы проверки:

• запрос специального файла или ответа по HTTP;
• специальная DNS-запись;
• механизм, связанный с TLS.

Выбор зависит от инфраструктуры и удостоверяющего центра. Для wildcard-сертификатов обычно требуется DNS-подтверждение.

Причины неудачи:

• домен не разрешается;
• порт недоступен;
• проверочный запрос перенаправляется неправильно;
• защитный сервис блокирует удостоверяющий центр;
• DNS-запись не обновилась;
• у клиента нет прав на DNS;
• исчерпан лимит запросов;
• часы сервера настроены неправильно;
• выбран неверный домен;
• IPv6-запись ведёт на другой сервер;
• предыдущая автоматизация перестала работать после обновления.

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

Шаг 4. Установите новый сертификат и цепочку

Получить новый файл недостаточно. Сервер должен начать отдавать его посетителям.

Проверьте:

• путь к сертификату и закрытому ключу;
• соответствие ключа сертификату;
• полный комплект промежуточных сертификатов;
• конфигурацию нужного виртуального хоста;
• сертификаты всех доменов и поддоменов;
• права на чтение файлов;
• настройки CDN и балансировщика;
• необходимость безопасной перезагрузки или перечитывания конфигурации.

Перед применением проверьте синтаксис конфигурации. Ошибка может не только оставить старый сертификат, но и остановить веб-сервер.

Шаг 5. Перезагрузите сервис и убедитесь, что используется новый файл

Частая ситуация: сертификат успешно выпущен, но сервер продолжает отдавать старый. Причины:

• веб-сервис не перечитал конфигурацию;
• обновлён не тот виртуальный хост;
• TLS завершается на другом узле;
• один сервер кластера не обновился;
• CDN кеширует или использует собственный сертификат;
• в конфигурации осталась ссылка на старый путь;
• автоматизация создала новый каталог, но сервер смотрит на прежний;
• сертификат обновлён для example.ru, но не для www.example.ru.

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

Шаг 6. Проверьте все узлы и имена

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

Проверьте:

• все IP-адреса из DNS;
• IPv4 и IPv6;
• все балансировщики;
• региональные узлы CDN;
• резервный сервер;
• основной домен и www;
• поддомены, указанные в сертификате;
• отдельные сервисы на нестандартных портах;
• почтовые протоколы, если сертификат используется почтой.

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

Шаг 7. Проверьте цепочку доверия

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

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

После установки используйте внешнюю проверку TLS и протестируйте несколько типов клиентов.

Шаг 8. Проверьте не только браузер

Веб-страница может открыться, а связанные сервисы остаться неисправными.

Нужно протестировать:

• API;
• формы;
• оплату;
• мобильные приложения;
• webhook;
• CRM-интеграции;
• SMTP, IMAP и другие почтовые соединения;
• панели администрирования;
• автоматические задания;
• мониторинг;
• поисковых роботов и панели вебмастера.

У некоторых систем собственное хранилище доверенных центров и более строгие требования к цепочке.

В чём разница между самоподписанным и публично доверенным сертификатом

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

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

Как истёкший домен влияет на SEO

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

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

После восстановления нельзя менять URL или домен без необходимости. Сначала верните прежние ответы и проверьте, что:

• страницы доступны по старым адресам;
• не включён случайный noindex;
• robots.txt не закрывает сайт;
• Sitemap доступен;
• канонические ссылки правильные;
• заглушка регистратора исчезла;
• сервер отдаёт 200 OK для существующих страниц.

Затем контролируйте статистику обхода и страницы в поиске. Данные обновятся не мгновенно.

Как истёкший SSL-сертификат влияет на SEO

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

После исправления:

• проверьте HTTPS на всех шаблонах;
• убедитесь, что HTTP ведёт на правильный HTTPS-адрес;
• не меняйте протокол обратно;
• проверьте канонические ссылки и Sitemap;
• устраните смешанный контент;
• проверьте Вебмастер и другие панели;
• дождитесь повторного обхода.

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

Коммуникация с клиентами и сотрудниками

При заметном простое молчание усиливает недоверие. Сообщение должно быть коротким и фактическим:

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

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

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

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

Включите автопродление

Автопродление полезно, но не является единственной защитой. Платёж может не пройти из-за истёкшей карты, лимита, недостатка средств или смены плательщика.

Продлевайте заранее

Критичный домен не следует продлевать в последний день. Возможность многолетнего продления зависит от зоны и регистратора, но запас времени нужен всегда.

Используйте корпоративные данные

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

Поддерживайте контакты актуальными

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

Храните сведения в реестре активов

Для каждого домена фиксируют:

• регистратора;
• владельца;
• дату окончания;
• кабинет;
• ответственного;
• резервного ответственного;
• способ оплаты;
• DNS-провайдера;
• назначение;
• критичные сервисы.

Секреты не нужно хранить в открытой таблице. Используйте корпоративный менеджер паролей и разграничение доступа.

Настройте независимый мониторинг

Уведомления должны приходить не только от регистратора, но и из отдельной системы контроля сроков и доступности.

Как предотвратить просрочку SSL-сертификата

Автоматизируйте выпуск и установку

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

Проверяйте автоматическое продление заранее

Наличие планового задания не означает, что оно работает. Нужно регулярно запускать предусмотренную клиентом тестовую проверку и контролировать результат.

Настройте мониторинг внешнего сертификата

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

Учитывайте все поддомены и узлы

В реестре сертификатов указывают:

• имена;
• издателя;
• срок;
• место установки;
• способ подтверждения;
• ответственного;
• автоматизацию;
• зависимые сервисы.

Ограничивайте права DNS-автоматизации

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

Следите за изменениями инфраструктуры

Автоматизация ломается после:

• переноса DNS;
• смены хостинга;
• добавления CDN;
• изменения firewall;
• замены веб-сервера;
• удаления служебной записи;
• смены API-ключа;
• обновления ACME-клиента;
• появления IPv6;
• добавления нового поддомена.

Каждое такое изменение должно включать проверку продления сертификатов.

Как организовать ответственность внутри компании

Основная организационная причина просрочки — не отсутствие уведомления, а отсутствие владельца процесса.

Для доменов и сертификатов должны быть определены:

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

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

Чего не нужно делать

• Не ждать несколько дней в надежде, что домен восстановится автоматически.
• Не менять регистратора во время ограниченного статуса без проверки возможности операции.
• Не оплачивать продление по ссылке из подозрительного письма.
• Не создавать новую учётную запись вместо восстановления доступа к действующему домену.
• Не менять DNS многократно без плана.
• Не советовать посетителям игнорировать ошибку сертификата.
• Не отключать HTTPS как основное решение.
• Не устанавливать самоподписанный сертификат на публичный сайт.
• Не проверять только файл сертификата на сервере — проверяйте внешний ответ.
• Не забывать про www, поддомены, IPv6, CDN и балансировщики.
• Не считать инцидент закрытым, пока не проверены почта, формы и интеграции.
• Не удалять журналы, которые помогут определить причину.

Аварийный чек-лист: истёк домен

1. Найти регистратора и официальный кабинет.
2. Восстановить доступ к учётной записи.
3. Проверить статус и этап жизненного цикла домена.
4. Немедленно продлить или запросить восстановление.
5. Проверить администратора и контактные данные.
6. Проверить DNS-серверы и все записи.
7. Протестировать сайт и поддомены.
8. Восстановить и проверить почту.
9. Проверить SSL-сертификаты.
10. Проверить формы, API, оплату и интеграции.
11. Убедиться, что в поиске доступна рабочая версия, а не заглушка.
12. Настроить автопродление, независимые уведомления и ответственность.

Аварийный чек-лист: истёк SSL-сертификат

1. Проверить внешний сертификат и точную ошибку.
2. Определить узел, завершающий TLS.
3. Найти систему выпуска и продления.
4. Устранить причину сбоя автоматизации.
5. Выпустить новый сертификат для всех нужных имён.
6. Установить сертификат, ключ и корректную цепочку.
7. Проверить конфигурацию и перечитать её без остановки сервиса, если это возможно.
8. Убедиться, что внешний сервер отдаёт новый сертификат.
9. Проверить все IP, узлы, поддомены, IPv4 и IPv6.
10. Протестировать браузеры, API, почту и интеграции.
11. Проверить HTTPS, редиректы, HSTS и смешанный контент.
12. Настроить мониторинг срока и тест автоматического продления.

Вывод

Истёкший домен и просроченный SSL-сертификат имеют разные причины, но оба инцидента способны остановить работу сайта и связанных сервисов.

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

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

Лучший способ справиться с такой аварией — не допустить её. Для этого нужны актуальные корпоративные доступы, заранее назначенные ответственные, автопродление, независимый мониторинг, резервные каналы уведомлений и периодическая проверка автоматизации. Домены и сертификаты следует учитывать как критичные ИТ-активы, а не как разовые покупки при создании сайта.