GKS

/ Просроченный сертификат из-за DNS

Просроченный сертификат из-за DNS

Теги: #cli #certificates #DNS

Узнавание о проблеме

При попытке залить новый пост на сайт оказалось, что сайт-то не работает. Точнее браузер ругается на сертификат вот такими словами:

net::ERR_CERT_DATE_INVALID

Полный текст сообщения:

Часы спешат
Не удалось установить защищенное соединение с доменом gubaidulin-ks.ru из-за неверных настроек системных часов и календаря (суббота, 10 января 2026 г. в 09:53:14).
NET::ERR_CERT_DATE_INVALID

Быстрый поиск показал, что это одно из двух: либо на сервере/клиенте неверное время, либо просрочены (некорректно установлены) сертификаты.
Время везде было правильным, значит дело в сертификате.

Убеждаемся, что сертификат действительно просрочен

Самый простой способ это выяснить - посмотреть прямо в браузере:

  1. Нажать на замочек около адресной строки
  2. Сертификаты
  3. Найти поле “действителен до”

В моём случае так и оказалось, что сертификат истёк 3 января 2026 года.
Но почему он не обновился автоматически, если настроено автообновление?

Пытаемся обновить сертификат вручную

Захожу на сервер по ssh, и смотрим что с сертификтом:

$ sudo certbot certificates

Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: gubaidulin-ks.ru
    Serial Number: 68*******************************c5
    Key Type: ECDSA
    Domains: gubaidulin-ks.ru
    Expiry Date: 2026-01-03 14:12:44+00:00 (INVALID: EXPIRED)
    Certificate Path: ***************************************fullchain.pem
    Private Key Path: ***************************************privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

certbot подтверждает сообщение в браузере: сертификат просрочен (expired)
Пробуем обновить в режиме dry-run, чтобы посмотреть, сработает ли:

$ sudo certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing ************************/gubaidulin-ks.ru.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Failed to renew certificate gubaidulin-ks.ru with error: HTTPSConnectionPool(host='acme-staging-v02.api.letsencrypt.org', port=443): Max retries exceeded with url: /directory (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f443379e3d0>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution'))

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All simulated renewals failed. The following certificates could not be renewed:
  ***************************************fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

О как. Есть ошибка с обновлением сертификата:

Failed to renew certificate gubaidulin-ks.ru with error: HTTPSConnectionPool(host=’acme-staging-v02.api.letsencrypt.org’, port=443): Max retries exceeded with url: /directory (Caused by NewConnectionError(‘<urllib3.connection.HTTPSConnection object at 0x7f443379e3d0>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution’))

Возможно проблемы с доступом к серверам

Первое что я попробовал сделать, это отправить curl к acme-staging-v02.api.letsencrypt.org

$ curl acme-v02.api.letsencrypt.org
curl: (6) Could not resolve host: acme-v02.api.letsencrypt.org

Не получилось. Может конкретно у них проблемы? Проверю на чём-то попроще:

$ curl ya.ru
curl: (6) Could not resolve host: ya.ru
$ curl https://ya.ru
curl: (6) Could not resolve host: ya.ru

Тоже не получается. Может нет доступа к DNS сервису? Или мешает запущенный клиент wireguard? Я пробую отключить:

$ sudo wg-quick down wg0
[#] ip link delete dev wg0
[#] iptables -D INPUT -p udp --dport 61015 -j ACCEPT
[#] iptables -D FORWARD -i eth0 -o wg0 -j ACCEPT
[#] iptables -D FORWARD -i wg0 -j ACCEPT
[#] iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[#] ip6tables -D FORWARD -i wg0 -j ACCEPT
[#] ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

$ curl https://ya.ru
curl: (6) Could not resolve host: ya.ru

$ ping ya.ru
ping: ya.ru: Temporary failure in name resolution

Проблема в resolv.conf

И что характерно - имена по-прежднему не резольвятся. Таким образом нет доступа к сервисам, возможно нет интернета.
Но я по ssh как-то же подключился. Может дело в самом сервере DNS, и у него проблемы? Или нет доступа до него? Надо проверить:

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=110 time=14.1 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=110 time=14.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=110 time=14.2 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 14.115/14.166/14.238/0.052 ms

А нет, есть доступ, и вроде работает. Подозрение падает на настройки DNS. Проверяю /etc/resolv.conf:

$ sudo cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "resolvectl status" to see details about the actual nameservers.

Да. Почему-то тут пусто, и не указаны DNS адреса. Так как systemd-resolved у меня отключён, /etc/resolv.conf должен содержать реальные адреса DNS‑серверов, а не только заголовок.
Добавим туда записи для DNS сервиса, и проверим заработает ли:

$ sudo bash -c 'printf "nameserver 8.8.8.8\nnameserver 1.1.1.1\n" >> /etc/resolv.conf'

$ sudo cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "resolvectl status" to see details about the actual nameservers.

nameserver 8.8.8.8
nameserver 1.1.1.1

$ ping ya.ru
PING ya.ru (77.88.44.242) 56(84) bytes of data.
64 bytes from ya.ru (77.88.44.242): icmp_seq=1 ttl=59 time=3.25 ms
64 bytes from ya.ru (77.88.44.242): icmp_seq=2 ttl=59 time=3.36 ms
^C
--- ya.ru ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 3.250/3.304/3.358/0.054 ms

$ sudo wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add ************* dev wg0
[#] ip -6 address add *************/64 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] iptables -I INPUT -p udp --dport ***** -j ACCEPT
[#] iptables -I FORWARD -i eth0 -o wg0 -j ACCEPT
[#] iptables -I FORWARD -i wg0 -j ACCEPT
[#] iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
[#] ip6tables -I FORWARD -i wg0 -j ACCEPT
[#] ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

$ ping ya.ru
PING ya.ru (77.88.55.242) 56(84) bytes of data.
64 bytes from ya.ru (77.88.55.242): icmp_seq=1 ttl=58 time=16.4 ms
^C
--- ya.ru ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 16.438/16.438/16.438/0.000 ms

Замечательно! Ping сразу стал проходить, и даже поднятый wg сервер не мешает. Теперь, когда DNS снова работает, возвращаемся к обновлению сертификата:

$ sudo certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing *************************gubaidulin-ks.ru.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Simulating renewal of an existing certificate for gubaidulin-ks.ru

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all simulated renewals succeeded:
  ***************************************fullchain.pem (success)

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

Заключение

В итоге причина просроченного сертификата была не в certbot и не в Let’s Encrypt, а в слетевших настройках DNS в /etc/resolv.conf.
После того как DNS‑серверы были прописаны заново, автообновление снова заработало(надеюсь), а сертификат без проблем обновился.