SSL-сертифікат закінчився - що робити

Що бачить відвідувач

Прострочений сертифікат викликає в браузері повноекранне попередження:

• Chrome / Edge: "Your connection is not private" (NET::ERR_CERT_DATE_INVALID)
• Firefox: "Warning: Potential Security Risk Ahead" (SEC_ERROR_EXPIRED_CERTIFICATE)
• Safari: "This Connection Is Not Private"

Звичайний відвідувач натискає «Назад». Переважна більшість відвідувачів при такому попередженні залишає сторінку. Краулери пошуковиків (Googlebot, Bingbot) перестають індексувати, і через кілька днів ви почнете втрачати позиції в пошуку.

Алгоритм, якщо закінчився прямо зараз

1. Визначте, хто видав сертифікат. У терміналі: openssl s_client -connect mywebsite.com:443 -servername mywebsite.com < /dev/null 2>/dev/null | openssl x509 -noout -issuer -dates
2. Let's Encrypt (безкоштовно, термін дії 90 днів): зазвичай через certbot renew або через панель хостингу (One-click renewal).
3. Комерційний сертифікат (DigiCert, Sectigo, GlobalSign): увійдіть до адмін-панелі видавця, згенеруйте новий CSR і пройдіть валідацію домену (DNS TXT-запис або email).
4. Встановіть новий сертифікат у reverse proxy (nginx, Caddy, Traefik) і перезапустіть або перезавантажте процес.
5. Перевірте через SSL Labs або через наш SSL check інструмент, що сертифікат правильно віддається і ланцюг сертифікатів повний.

Увага: Не забувайте про intermediate cert - без нього сучасні браузери можуть підтягнути chain через AIA, але старіші клієнти та деякі API-бібліотеки впадуть.

Автоматичне продовження: Let's Encrypt + certbot

Найпростіша профілактика - повністю автоматизувати оновлення. Сертифікат Let's Encrypt оновлюється кожні 90 днів через certbot:

# /etc/cron.d/certbot-renew
0 3 * * * root certbot renew --quiet --deploy-hook "systemctl reload nginx"

Цей cron працює щодня о 3:00 ранку. Certbot внутрішньо перевіряє, чи наближається сертифікат до закінчення (коли залишається менше третини його терміну життя, що для 90-денного сертифіката Let's Encrypt становить приблизно 30 днів до кінця). Якщо так, він продовжує сертифікат і при успіху перезавантажує nginx. Інакше нічого не робить.

Caddy і Traefik: повністю автоматично

Якщо використовуєте Caddy або Traefik як reverse proxy, ACME challenge вбудований прямо в бінарь. Достатньо позначити домен у конфігу, і сервер сам запросить і оновить сертифікат:

# Caddyfile
mywebsite.com {
  reverse_proxy localhost:3000
}

Жодного certbot, жодного cron. Caddy у фоні викликає API Let's Encrypt і керує всім циклом оновлення.

Комерційні сертифікати: термін 1-3 роки

З вересня 2020 всі публічно довірені сертифікати мають максимальний термін життя 398 днів (CA/B Forum baseline). Деякі компанії все ж віддають перевагу комерційним CA, і ось з яких причин:

• Extended Validation (EV) показує організацію в адресному рядку (Chrome з 2019 року вже не відображає її prominent).
• Wildcard для багатьох субдоменів хоча Let's Encrypt вже підтримує wildcards через DNS-01.
• Гарантія фінансова відповідальність CA при компрометації.
• Compliance / аудит деякі галузі мають зовнішні вимоги.

Для більшості сайтів достатньо Let's Encrypt або іншої безкоштовної CA (ZeroSSL, Buypass).

Моніторинг закінчення як страховка

Навіть з автоматичним оновленням моніторинг закінчення працює як страховка. Renewal адже може впасти з різних причин:

• rate limit з боку CA (Let's Encrypt: 5 дублікатів / 7 днів)
• зміна DNS, що ламає ACME challenge
• правило firewall, що блокує порт 80 (HTTP-01 challenge)
• падіння процесу certbot або cron, яке ніхто не помітив

ePulz.io відстежує закінчення кожного контрольованого endpoint і надсилає alert за 30, 14, 7, 3 і 1 день до кінця терміну дії. Достатньо одного зеленого сигналу, що сертифікат встиг оновитися - і ви впевнені, що автоматика працює.

Активуйте SSL-моніторинг

Сповіщення за 30/14/7/3/1 день до закінчення. Без конфігурації, без змін DNS. 7 днів безкоштовно.

Запустити моніторинг →