Срок действия SSL-сертификата

Что происходит ровно в момент истечения

Почему автопродление иногда не срабатывает

У 80% сайтов на 2026 год стоит Let's Encrypt с 90-дневным сертификатом и автопродление через certbot/acme.sh. Тем не менее сертификаты регулярно истекают. Реальные причины из инцидентов:

• HTTP-01 challenge не проходит -- редирект всего трафика на HTTPS, теперь Let's Encrypt не может верифицировать домен через /.well-known/acme-challenge/. Решение: либо исключить путь из редиректа, либо переключиться на DNS-01.
• Сменился IP сервера -- DNS ещё не пропагировался, Let's Encrypt видит старый IP без нужного веб-сервера. Challenge fail.
• Cron не запущен или systemd-timer выключен -- проверьте systemctl status certbot.timer и cat /var/log/letsencrypt/letsencrypt.log.
• Превышен Let's Encrypt rate limit -- 50 сертификатов в неделю на основной домен, 5 дубликатов за 7 дней. Бьются shared-хостинги с одного IP.
• Cloudflare/CDN перехватывает challenge -- если в Cloudflare включен Always Use HTTPS + Origin Cert, прямой Let's Encrypt на origin не пройдёт. Используйте Cloudflare API + DNS-01 или отключите перехват для /.well-known/.
• Поменялась структура webroot -- developer перенёс nginx-config, certbot пишет в старый webroot, web-сервер читает из нового. Challenge "не находится".

Recovery: что делать прямо сейчас, если уже истёк

Время каждой минуты на счету -- пользователи уже видят красные экраны. Быстрая последовательность:

1. 1. Выпустите новый сертификат немедленно.

   sudo certbot certonly --standalone -d example.com --force-renewal

   Если 80 порт занят nginx -- остановите его на 30 секунд или используйте --webroot. Один сертификат выписывается за 30-60 секунд.
2. 2. Перезапустите веб-сервер.

   sudo nginx -s reload  # или  sudo systemctl reload nginx

   Без reload nginx продолжит отдавать старый сертификат из памяти. Проверьте через echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates.
3. 3. Очистите DNS-кэш CDN. Если перед сервером стоит Cloudflare/AWS CloudFront -- они кэшируют TLS-сессии. Зайдите в панель CDN, сделайте Purge Everything или включите Development Mode на 3 часа.
4. 4. Сообщите пользователям. Если у вас есть статус-страница -- разместите инцидент. Если нет -- хотя бы напишите в Telegram-канал и в твиттер. Пользователи прощают сбой если видят что вы реагируете.
5. 5. Сразу настройте мониторинг. Чтобы это не повторилось через 90 дней -- подключите автоматические напоминания за 30/14/7 дней до следующего истечения.

Альтернативные способы проверить срок через CLI

Если нужна автоматизация или вы предпочитаете командную строку -- три рабочих способа:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate

curl -s "https://crt.sh/?q=example.com&output=json" \
  | jq '.[0].not_after'

python -c "import ssl, socket; from datetime import datetime; \
ctx = ssl.create_default_context(); s = ctx.wrap_socket(socket.socket(), server_hostname='example.com'); \
s.connect(('example.com', 443)); print(s.getpeercert()['notAfter'])"

Какие пороги уведомлений действительно работают

Из практики реагирования на SSL-инциденты вывели три порога. Меньше -- пропускаешь, больше -- становится шумом и теряет ценность:

Похожие инструменты