Что произойдёт после истечения SSL-сертификата

После истечения SSL/TLS-сертификата сервер может продолжать слушать порт 443 и даже отправлять тот же сертификат, но клиент, который корректно проверяет срок действия, больше не должен считать его действительным. В результате HTTPS-соединение для обычного пользователя, API-клиента или мониторинга может завершиться ошибкой проверки сертификата.

Критичная дата находится в поле notAfter. После неё проблема относится не к HTTP-коду приложения: TLS-проверка происходит раньше нормального HTTP-обмена.

Что именно истекает

X.509-сертификат содержит период действия:

notBefore ───────────── notAfter
     сертификат действителен

После notAfter:

клиент проверяет сертификат
→ срок действия завершён
→ certificate validation fails
→ нормальный HTTPS request может не дойти до приложения

RFC 5280 определяет период validity через notBefore и notAfter.

Что увидит пользователь

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

Нельзя рассчитывать на то, что пользователь нажмёт «продолжить». Для API, мобильных приложений и автоматических клиентов такого интерактивного обхода часто вообще нет.

Что произойдёт с API

API-клиент с нормальной TLS verification может завершить запрос до получения HTTP status.

То есть вместо:

HTTP 500

может быть:

TLS certificate verification error

Это важно для диагностики: application log может не содержать ожидаемый HTTP request.

Что произойдёт с webhook и интеграциями

Внешний сервис, который отправляет webhook на ваш HTTPS endpoint, тоже является TLS-клиентом. Если он проверяет сертификат и отклоняет просроченный, webhook не будет доставлен.

То же относится к payment callbacks, API integrations, background jobs, mobile clients и server-to-server requests.

Фактическое поведение конкретного интегратора нужно смотреть в его документации.

CDN может скрыть проблему origin-сертификата

Архитектура:

пользователь
  ↓ TLS №1
CDN
  ↓ TLS №2
origin

Сертификат на edge и сертификат origin — разные объекты и могут иметь разные даты notAfter.

Возможны два сценария:

1. edge-сертификат истёк — проблема видна пользователям напрямую;
2. origin-сертификат истёк — пользовательский edge-сертификат ещё валиден, но CDN не может установить защищённое соединение с origin.

Во втором случае пользователь может видеть уже HTTP 5xx от CDN, а не прямую browser certificate error.

Шаг 1. Проверьте фактический сертификат endpoint

openssl s_client   -connect example.com:443   -servername example.com   </dev/null

Для вывода дат:

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

Пример:

notBefore=...
notAfter=...

Шаг 2. Не проверяйте только файл на сервере

На диске может лежать новый certificate, а endpoint продолжает отдавать старый из-за:

• не выполненного reload;
• другого proxy;
• другого load balancer;
• нескольких backend;
• CDN;
• неправильного virtual host.

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

Шаг 3. Проверьте hostname и SNI

Один IP может обслуживать несколько доменов. Без правильного SNI сервер может вернуть чужой сертификат.

Поэтому:

openssl s_client -connect 203.0.113.10:443

без -servername не всегда воспроизводит реальный браузерный запрос.

Шаг 4. Проверьте полную цепочку

Даже новый leaf certificate не гарантирует успех, если неверно настроена intermediate chain.

После обновления проверяйте не только дату leaf, но и успешную verification chain для реального endpoint.

Что делать, если сертификат уже истёк

Общий алгоритм:

1. получить или выпустить действительный сертификат;
2. установить его в фактическую точку TLS termination;
3. установить нужную chain;
4. выполнить безопасный reload/redeploy;
5. проверить публичный endpoint;
6. проверить несколько доменов/SNI;
7. проверить CDN и origin отдельно;
8. проверить API и критичные URL.

Не отключайте TLS verification у клиентов как постоянное «исправление».

Автоматическое продление не гарантирует автоматическую установку

ACME-клиент может успешно получить новый certificate, но production endpoint продолжит отдавать старый, если:

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

Поэтому важен внешний контроль фактического endpoint.

Как проверить восстановление

После замены:

certificate chain → valid
hostname          → совпадает
notAfter          → в будущем
TLS handshake     → успешен
HTTP critical URL → ожидаемый код

Повторите проверку несколько раз, если TLS termination распределён между несколькими узлами.

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

Нужны две независимые вещи:

• автоматическое продление;
• автоматический внешний контроль срока сертификата.

Одна только задача renewal не доказывает, что пользователям уже выдаётся новый certificate.

UpWatch можно использовать для контроля SSL-сертификата публичного endpoint и предупреждения до истечения срока.

Типичные ошибки

• проверять только certificate file на сервере;
• забывать SNI;
• обновить leaf без chain;
• считать успешный ACME renewal доказательством production update;
• использовать curl -k как решение;
• проверять только CDN или только origin;
• ждать последнего дня перед renewal.

Практический чек-лист

1. Получить фактический certificate endpoint.
2. Проверить notAfter.
3. Проверить hostname.
4. Проверить chain.
5. Определить TLS termination.
6. Проверить CDN и origin отдельно.
7. Установить новый certificate.
8. Выполнить reload/redeploy.
9. Повторно проверить внешний endpoint.
10. Проверить API и критичные URL.
11. Настроить предупреждение заранее.
12. Контролировать именно публично выдаваемый сертификат.

Источники и спецификации

• RFC 5280: Validity
• OpenSSL s_client
• OpenSSL x509