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

За неделю до акции браузер у части клиентов пишет "Подключение не защищено" или NET::ERR_CERT_DATE_INVALID, а у вас в офисе замок ещё зелёный. За 2–5 минут достанете notAfter, issuer и SAN: отличите просрочку от ошибки цепочки и решите – алерт или хостинг. Результат: дата, дни до истечения и понятный следующий шаг без паники.

Проверить срок действия SSL-сертификата – это не "что такое HTTPS", а три поля: notAfter (когда кончится), issuer (кто выдал) и SAN (на какие имена выдан). Сначала браузер или онлайн SSL checker, затем при необходимости одна команда OpenSSL. С 2026 публичные сертификаты живут короче (до 200 дней), поэтому разовая проверка раз в год уже не спасает – нужен алерт за 30/14/7 дней.

Речь про сайт на своём хостинге, в том числе на CMS "1С-Битрикс: Управление сайтом". Это не Bitrix24 CRM – там другая модель сертификатов и доступа к домену.

Типичная ловушка: панель хостинга "зелёная", а клиенты уже видят красный замок. Другая – смотреть Whois домена вместо SSL: срок имени и сертификата живут отдельно (срок регистрации домена). Triage "сайт открывается?" – в проверке работоспособности. Здесь только срок SSL и сценарий "срок жив, а браузер орёт".

Разберите, что смотреть: notAfter, issuer и SAN

SSL/TLS-сертификат – "паспорт" сайта для браузера: вы на нужном сервере и канал шифрован. Без DevOps хватит четырёх полей.

С 15 марта 2026 по правилам CA/Browser Forum максимум для публичных TLS – 200 дней (дальше короче по SC-081). Let's Encrypt по умолчанию даёт 90 дней и советует обновлять примерно за треть жизни. "Проверил год назад" больше не работает.

Сделайте: запишите notAfter и дни до неё в заметку вместе с доменом. Не делайте: путать срок SSL со сроком домена и со "зелёным" статусом в панели хостинга.

Проверьте срок в браузере за минуту

Локальный срез удобен, если сайт открывается у вас. На практике он не заменяет внешний SSL checker: ПК может видеть другой хост или кэш.

1. Откройте сайт строго по https://ваш-домен.ru (не http и не IP).
2. Нажмите на замок (или значок "не защищено") слева от адреса.
3. Откройте сведения о сертификате / "Connection is secure" → Certificate.
4. Найдите дату окончания (Valid to / notAfter) и список имён (Subject Alternative Name).
5. Сверьте, что в списке есть тот хост, который реально открывают клиенты (с www или без).
6. Если браузер сразу показывает ERR_CERT_DATE_INVALID – почти наверняка проблема дат (истёк сертификат или сбиты часы на устройстве).

Сделайте: зафиксируйте дату окончания скрином. Не делайте: считать "у меня зелёный замок" доказательством для всех клиентов – кэш и разные хосты врут.

Сделайте онлайн-проверку SSL checker снаружи

Онлайн SSL checker с чужого сервера показывает срок, issuer и часто предупреждения по цепочке. Это основной способ "проверка ssl сертификата" без ПО.

1. Откройте проверку SSL на bx-monitor.ru или нейтральный checker из выдачи (2whois, Reg.ru, SSL Shopper).
2. Введите домен без лишнего пути (лучше и apex, и www, если оба в продаже).
3. Запишите Valid to / days left, issuer и совпадение имени.
4. Если "меньше 30 дней" – продление в календарь сегодня, не "после акции".
5. Для глубокого аудита – Qualys SSL Labs.
6. Сохраните ссылку на отчёт checker – пригодится в тикете хостингу.

Схема за 2 минуты:
Браузер (замок → дата) → внешний SSL checker (notAfter + issuer + SAN) → если срок OK, а ошибка осталась → смотреть цепочку/имя

Сделайте: одну внешнюю проверку с записью даты. Не делайте: ограничиваться панелью хостинга – она показывает "свой" взгляд, не взгляд клиента.

Снимите notAfter через OpenSSL (если есть терминал)

Есть SSH или терминал с OpenSSL – ту же дату одной командой. Флаг -servername включает SNI: без него сервер может отдать чужой дефолтный cert с виртуального хоста.

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

Печатает notAfter=.... Для cron удобен -checkend: ненулевой exit, если истечёт раньше N секунд. Пример на 30 дней (2592000):

echo | openssl s_client -servername example.ru -connect example.ru:443 2>/dev/null | openssl x509 -noout -checkend 2592000

Сделайте: всегда указывайте -servername равным тому хосту, что в браузере. Не делайте: проверять только IP без имени – легко получить чужой cert с shared-хостинга.

Отличите живой срок от ошибки цепочки

Бывает: notAfter ещё через месяц, а Chrome уже пугает. Продление "на всякий случай" не лечит причину. Например, incomplete chain даёт красный замок при живой дате. Короткая развилка:

• ERR_CERT_DATE_INVALID – смотрите даты сертификата и часы на устройстве клиента.
• ERR_CERT_AUTHORITY_INVALID / incomplete chain – не хватает промежуточного сертификата (цепочка УЦ). Срок leaf может быть жив.
• Имя не совпадает – в SAN нет того хоста, куда заходят (www vs без www, поддомен).
• После смены DNS/хостинга иногда видят старый IP – сначала сверьте записи: как проверить DNS-записи домена.

Глубокий разбор цепочки – отдельная тема. Если дата жива, а ошибка осталась, зовите хостинг с формулировкой "проверьте intermediate / fullchain", а не только "продлите SSL". Этот материал – про проверку срока, не про полное продление.

Сделайте: сначала запишите notAfter, потом читайте код ошибки браузера. Не делайте: лечить AUTHORITY_INVALID одним "кнопочным" renew без проверки цепочки.

Сверьте чек-лист перед продлением и поставьте алерт

Перед кнопкой "продлить" зафиксируйте факты – это экономит час переписок с поддержкой.

1. Дни до notAfter: больше 30 / 14–30 / меньше 7.
2. SAN покрывает все боевые хосты витрины и оплаты.
3. Issuer понятен: Let's Encrypt на хостинге, платный УЦ или свой ACME.
4. После обновления – повторный SSL checker снаружи, не только "в панели стало ОК".
5. Отдельно от календаря SSL держите дату домена (Whois) и общий мониторинг доступности.

Ручной чек раз в год при сроках 90–200 дней почти всегда промажет. Рабочий паттерн: алерт 30/14/7 + ACME auto-renew, где есть. На Битрикс свяжите SSL с мониторингом витрины – мониторинг сайта на Битрикс. Постоянные алерты – через demo BX Pulse.

Схема контроля:
notAfter зафиксирован → SAN сверен → внешний checker → алерт 30/14/7 → после renew повторный checker

Сделайте: алерт вне почты на том же домене (мессенджер / второй email). Не делайте: единственное напоминание "письмо от хостинга" – оно часто уходит в спам.

Что дальше: закрепите результат проверки

1. Запишите: домен, notAfter, дни до истечения, issuer, дата проверки.
2. Если меньше 30 дней – запланируйте продление сегодня и подтвердите auto-renew.
3. Добавьте напоминания 30/14/7 и повторный внешний SSL checker после обновления.
4. Разведите в календаре даты SSL, домена и лицензии CMS.
5. Если срок жив, а браузер ругается – передайте хостеру скрин ошибки + вывод checker по цепочке.

Итог: за несколько минут – дата окончания, issuer и SAN, без путаницы просрочки с битой цепочкой. Дальше – алерт, а не героизм перед распродажей.

Материал проверен. Автор: Максим Мольков, основатель BX Pulse, разработчик 1С-Битрикс.
Источники: CA/Browser Forum Baseline Requirements / SC-081 (cabforum.org), DigiCert alert о 199-day validity (knowledge.digicert.com), OpenSSL x509 man (docs.openssl.org), Let's Encrypt FAQ и roadmap 90→45 (letsencrypt.org/faq, letsencrypt.org/2025/12/02), Qualys SSL Labs Server Test (ssllabs.com).