Как узнать срок действия SSL-сертификата

Срок действия TLS-сертификата задаётся полями notBefore и notAfter. Для контроля истечения в первую очередь важен notAfter: после этого момента сертификат больше не должен считаться действующим по времени.

Проверять лучше фактический сертификат, который получает клиент по сети, а не только PEM-файл на сервере. Файл может быть новым, а Nginx или CDN продолжать отдавать старый сертификат.

Какие даты есть в сертификате

notBefore — с какого момента сертификат действителен
notAfter  — до какого момента сертификат действителен

Текущее время должно попадать внутрь этого интервала.

Но одной даты недостаточно. Сертификат также должен соответствовать имени хоста, иметь корректную цепочку доверия и реально использоваться нужным endpoint.

Быстрая проверка в браузере

Современные браузеры позволяют открыть сведения о защищённом соединении и сертификате. Расположение пунктов меняется между версиями, поэтому ищите сами поля:

• Subject Alternative Name;
• Issuer;
• Valid from / notBefore;
• Valid to / notAfter;
• certificate chain.

Для повторяемой инженерной диагностики удобнее OpenSSL.

Проверка через OpenSSL

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

-servername example.com передаёт SNI. Это критично, если один IP обслуживает несколько HTTPS virtual hosts.

Как вывести даты сертификата

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

В ответе будут notBefore и notAfter.

Как вывести только дату окончания

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

Эта команда удобна после выпуска или установки сертификата.

Почему SNI нельзя опускать

На одном адресе могут работать:

example.com
api.example.com
shop.example.org

Клиент передаёт имя через Server Name Indication, а сервер выбирает соответствующий virtual host.

Если вызвать s_client без нужного -servername, можно получить default certificate и сделать неправильный вывод.

Как проверить конкретный IP с нужным именем

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

203.0.113.10 — пример адреса из документационного диапазона. Подставляйте реальный IP.

Так можно проверить новый origin до переключения DNS.

Как посмотреть SAN

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  </dev/null 2>/dev/null \
| openssl x509 -noout -ext subjectAltName

Убедитесь, что нужное DNS-имя присутствует.

Wildcard-сертификат не означает автоматическое покрытие любого уровня вложенности поддоменов.

Как проверить, скоро ли сертификат истечёт

openssl x509 поддерживает -checkend.

Например, проверить окно 30 дней:

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  </dev/null 2>/dev/null \
| openssl x509 -noout -checkend 2592000

2592000 — 30 × 24 × 60 × 60 секунд.

Для production automation проверяйте поведение именно установленной версии OpenSSL.

Почему проверка файла на диске недостаточна

На сервере могут лежать:

/etc/ssl/old.pem
/etc/ssl/new.pem

Вы проверили new.pem, но активная конфигурация всё ещё указывает на old.pem.

Локальный файл:

openssl x509 \
  -in certificate.pem \
  -noout \
  -dates

отвечает только на вопрос о конкретном файле, а не о сертификате, который видит пользователь.

Как проверить, что новый сертификат действительно используется

После reload/restart web-сервера повторите сетевую проверку:

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

Сравните serial и notAfter с ожидаемыми.

Если за балансировщиком несколько узлов, повторите проверку или проверьте backend отдельно.

CDN создаёт две TLS-точки

При CDN схема часто такая:

клиент → TLS → CDN → TLS → origin

Это два независимых TLS-соединения.

Пользователь видит сертификат CDN edge. CDN отдельно использует сертификат origin.

Возможна ситуация, когда внешний сертификат действителен, а origin certificate уже истёк.

Как посмотреть сертификаты, отправленные сервером

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

Официальная документация OpenSSL указывает, что -showcerts показывает сертификаты в том виде, как их прислал сервер. Сам список не является доказательством успешно построенной доверенной цепочки.

Что произойдёт после истечения

Когда текущее время выходит за notAfter, временная проверка сертификата не проходит.

Браузер обычно показывает предупреждение. Автоматический HTTP/API-клиент чаще завершает TLS-запрос ошибкой, если certificate verification не отключена.

Отключение проверки сертификата ради «исправления» production-проблемы не является корректным решением.

Почему календарного напоминания недостаточно

Сертификат может:

• перевыпуститься, но не установиться;
• обновиться только на одном backend;
• обновиться на origin, но не на edge;
• лежать на диске, но не использоваться;
• быть заменён другим из-за SNI/routing.

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

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

Универсального числа нет. Порог должен оставлять время на диагностику, DNS validation, доступ к CA, deployment и повторную проверку.

Главный принцип — предупреждение приходит до пользовательской ошибки.

Автоматический контроль

host:port
↓
TLS handshake
↓
фактический сертификат
↓
notAfter
↓
оставшееся время

UpWatch можно использовать для автоматического контроля SSL-сертификата. HTTP-monitoring при этом остаётся отдельным уровнем: сайт может работать сегодня, хотя сертификат закончится через несколько дней.

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

Проверять без -servername

Можно получить сертификат другого virtual host.

Смотреть только notAfter

Не проверяются SAN и цепочка.

Проверять только PEM-файл

Он может не использоваться активной конфигурацией.

Проверять только CDN

Origin certificate остаётся вне контроля.

Считать успешный renewal успешной установкой

Web-server может продолжать отдавать старый сертификат.

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

1. Проверить публичный endpoint по сети.
2. Передать правильный SNI.
3. Посмотреть notBefore и notAfter.
4. Проверить SAN.
5. Проверить chain/verify result.
6. При CDN отдельно проверить origin.
7. После renewal проверить serial и enddate по сети.
8. Не отключать certificate verification.
9. Настроить предупреждение заранее.
10. Контролировать фактический сертификат, а не только файл.

Источники

• OpenSSL: s_client
• OpenSSL: x509