Режисcёрская версия распологается на сайте: 
https://gubaidulin-ks.ru/2026/01/10/SertInvalidDate/

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

Сообщение намекало либо на неверно настроенные системные часы, либо на проблемы с SSL‑сертификатом, но время на сервере и на клиенте было выставлено корректно, так что подозрение сразу пало на сертификат. Проверка через браузер подтвердила догадку: в деталях соединения в поле «действителен до» было видно, что сертификат для gubaidulin-ks.ru истёк 3 января 2026 года. То же самое показал и certbot: в его выводе статус сертификата числился как EXPIRED, с датой окончания в начале января.

Следующий логичный шаг — попробовать обновить сертификат вручную и понять, что мешает автопродлению. При запуске команды вида sudo certbot certificates стало видно, что нужный сертификат найден, но уже недействителен, а система явно не смогла продлить его вовремя.

Попытка аккуратно проверить процесс через sudo certbot renew --dry-run закончилась неудачей: вместо успешной симуляции обновления появилась ошибка Temporary failure in name resolution. Это звучит уже не как проблема Let’s Encrypt или самого certbot, а как невозможность вообще достучаться до нужных серверов по имени. Если утилита не может даже разрешить домен ACME‑серверов, нормального обновления сертификата она провести не сможет.

Дальше началась проверка сетевого уровня.

Первым делом был сделан запрос curl к адресу ACME‑серверов Let’s Encrypt, но команда сразу вернулась с ошибкой Could not resolve host, что подтвердило проблемы с DNS‑резолвингом. Для чистоты эксперимента аналогичный запрос был отправлен к чему‑то попроще, вроде ya.ru, и результат оказался таким же: имена не резолвятся вообще. В качестве варианта рассматривались проблемы с DNS‑сервисом или влияние WireGuard‑туннеля, поэтому интерфейс wg0 был временно отключён, но это не помогло — доменные имена всё так же не переводились в IP‑адреса. При этом простой ping по IP‑адресу 8.8.8.8 успешно проходил с нормальным временем отклика, что показало: интернет‑доступ есть, маршрутизация работает, а вот DNS‑часть сломана.

После этого подозрение закономерно переключилось на настройки резолвера, и взгляд упал на содержимое /etc/resolv.conf. Внутри файла оказались только стандартные комментарии о systemd‑resolved и локальном stub‑резолвере на 127.0.0.53, но никаких реальных записей вида nameserver не было. При активном systemd‑resolved такой конфиг ещё можно было бы ожидать, но так как он был отключён, отсутствие живых DNS‑серверов в resolv.conf означало, что никакого нормального резолвинга просто не происходит. Программы вроде curl, ping по домену и сам certbot банально не знали, куда отправлять DNS‑запросы, поэтому любое имя превращалось в ошибку временного сбоя при разрешении.

Решение оказалось простым, но неочевидным: вручную дописать в /etc/resolv.conf адреса публичных DNS‑серверов. После добавления строк с nameserver 8.8.8.8 и nameserver 1.1.1.1 и повторной проверке содержимого файла стало видно, что резолвер наконец получил реальные точки для обращения. С этого момента поведение системы изменилось: ping ya.ru сразу начал успешно отрабатывать, curl перестал ругаться на Could not resolve host, а поднятие WireGuard‑интерфейса больше не ломало работу DNS. То есть проблема была не в туннеле, не в провайдере и не в магии, а в пустом resolv.conf, который оставлял все сетевые утилиты без валидных DNS‑серверов.

Когда DNS вернулся к жизни, можно было снова вернуться к первоначальной задаче — обновлению SSL‑сертификата. Повторный запуск sudo certbot renew --dry-run на этот раз прошёл штатно: симуляция обновления завершилась без ошибок, и certbot уверенно сообщил об успешной проверке. После этого оставалось убрать флаг dry‑run, выполнить обычное renew и открыть сайт в браузере, чтобы убедиться, что новый сертификат установлен и предупреждения о NET::ERR_CERT_DATE_INVALID больше не появляется.

В итоге выяснилось, что изначальная проблема с просроченным сертификатом была всего лишь следствием слетевших DNS‑настроек в /etc/resolv.conf: как только система снова смогла резолвить домены, автоматическое продление сертификатов вернулось к нормальной работе, а сайт без проблем стал открываться по HTTPS.