Как проверить, когда истекает SSL-сертификат

2026-09-04 Обновлено: 2026-09-14

Чтобы узнать, когда истекает SSL-сертификат, откройте значок замка в браузере и прочитайте даты действия, либо выполните одну команду openssl против хоста. Проверяйте всю цепочку, а не только сертификат домена, потому что просроченный промежуточный сертификат ломает сайт так же основательно, как просроченный конечный.

Быстрый способ: замок в браузере и онлайн-проверка

В любом браузере кликните на значок замка в адресной строке, откройте детали сертификата и прочитайте "действителен с" и "действителен до". Это занимает десять секунд и показывает то, что видит именно ваш браузер. Ограничение в том, что это охватывает только сертификат, отданный именно вам - с того граничного узла или сервера, до которого вы дотянулись именно в этот момент.

Онлайн-проверка SSL выполняет то же рукопожатие извне вашей сети и показывает дату истечения, издателя, имена, которые покрывает сертификат, и полна ли отданная цепочка. Браузеры скрывают последний пункт, поэтому внешняя проверка сообщает то, чего замок показать не может.

Ручной способ с openssl

Одна команда выводит окно действия сертификата:

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

Флаг -servername отправляет SNI, и это важно, потому что большинство серверов хостят по одному адресу сразу несколько сертификатов и без этого флага отдадут не тот. В выводе будут notBefore и notAfter в UTC, а также для кого выпущен сертификат и кто его выпустил.

Чтобы увидеть всю цепочку, которую отправляет сервер, а не только конечный сертификат:

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

Прочитайте блок "Certificate chain" вверху: там должен быть конечный сертификат, а затем один или несколько промежуточных. Строка "verify error: unable to get local issuer certificate" означает, что сервер не отправляет промежуточный сертификат, что многие браузеры молча сглаживают, а многие API-клиенты, мобильные приложения и более старые системы - нет.

Конечный сертификат, цепочка и что именно истекает

В обычном HTTPS-соединении участвуют три сертификата, и у каждого своя дата истечения:

Конечный сертификат - тот, что выпущен для вашего домена. Он короткоживущий, обычно 90 дней при автоматическом выпуске и до примерно года для купленного, и именно его обычно называют "сертификатом".
Промежуточный сертификат подписывает конечный и должен отправляться сервером вместе с ним. Он живет годами, и именно из-за того, что он меняется так редко, его истечение застает команды врасплох.
Корневой сертификат живет в хранилище доверия клиента, а не на вашем сервере. Когда корневой сертификат истекает или теряет доверие, более старые устройства, так и не получившие обновление, начинают отказывать, а актуальные работают нормально - это создает сбой, который с вашего собственного ноутбука выглядит невозможным.

Поэтому проверяйте цепочку, а не только дату на конечном сертификате. Конечный сертификат, до истечения которого еще два месяца, но со сломанной цепочкой, для части клиентов уже не работает.

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

Истечение сертификата - необычно разрушительный отказ. Он происходит полностью, а не постепенно: браузер прямо отказывает в соединении и показывает предупреждение на весь экран вместо сайта. Момент отказа был предопределен еще в день выпуска сертификата, просто никто не следил за этой датой. К тому же он одновременно кладет все, что использует это имя, не только сайт: API, бэкенды мобильных приложений, вебхуки и интеграции. Сорванные платежные колбэки и сломанные интеграции нередко обходятся дороже, чем сам видимый простой сайта.

При этом он полностью предотвратим - именно поэтому стоит автоматизировать проверку именно на этот случай.

Как автопродление все равно ломается

Автоматический выпуск сертификатов убрал большую часть истечений и добавил набор сбоев, которые сложнее заметить:

Продление прошло, но ничего не перезагрузилось. Новый сертификат лежит на диске, а веб-сервер продолжает отдавать старый из памяти, пока его не перезагрузят.
Проверка для выпуска сломалась. Правило редиректа, изменение файрвола или новый CDN перед источником блокирует путь HTTP-проверки, и продление неделями проваливается без видимых симптомов.
DNS-проверка потеряла учетные данные. API-токен сменили или он истек, и DNS-проверка больше не может создать нужную запись.
Таймер продления не работает. Контейнер пересобрали без cron-задачи или systemd-таймера, либо машину перенесли, а расписание не перенесли вместе с ней.
Продлился только один узел. За балансировщиком нагрузки один сервер получил новый сертификат, а другой все еще отдает старый, из-за чего сбои выглядят прерывистыми.
Письма о продлении ушли тому, кто уже уволился. Тот же вариант проблемы, но для купленного сертификата.
Сертификат продлился, но не для всех имен. Поддомен, добавленный позже, отсутствует в новом сертификате, и именно это имя хоста отказывает.

Каждый из этих случаев невидим изнутри системы продления и очевиден снаружи. Это и есть аргумент в пользу проверки живого рукопожатия, а не доверия к собственным логам автоматизации.

Автоматизация проверки

Чтение даты дает ответ на сегодня, а вся проблема истечения в том, что оно наступает в день, который никто не выбирал проверить. Мониторинг сертификатов по расписанию выполняет настоящее рукопожатие снаружи с заданным интервалом, предупреждает за заданное число дней до notAfter и ловит проблемы с цепочкой и именами хоста, которые напоминание в календаре никогда бы не поймало. HostTracker оповещает по email, SMS, голосовым звонком, в Slack, Telegram и другими способами, так что предупреждение доходит до кого-то раньше, чем истечение. Мониторинг домена и TLS выполняет эту проверку непрерывно, инструмент проверки SSL делает разовую проверку, а руководство как проверить, открыт ли порт разбирает случай, когда рукопожатие отказывает еще до того, как сертификат вообще предложен.