SiteGuard4 ноября 202617 мин чтения

Как проверить SSL-сертификат сайта: срок действия, домен и ошибки

Чтобы проверить SSL-сертификат сайта, откройте точный HTTPS-адрес, посмотрите срок действия и список доменных имён в сертификате, затем проверьте доверие к его цепочке. Для быстрой диагностики подойдёт браузер, для независимой внешней проверки — SSL Labs, для разбора конкретного сервера — OpenSSL и curl. Проверяйте сертификат, который сайт действительно отдаёт посетителю: файл в панели хостинга может отличаться от сертификата на работающем узле.

Одна дата окончания не отвечает на вопрос, всё ли в порядке. Сертификат может быть действующим, но выданным для другого имени; новый экземпляр может работать только на части серверов; успешное TLS-соединение может завершаться HTTP 500. Ниже — последовательность проверки, которая помогает отделить эти ситуации и передать администратору конкретную задачу.

Быстрая проверка SSL-сертификата: пять шагов

Запишите адрес. Например, https://www.example.com/. Если есть нестандартный порт, сохраните его: https://example.com:8443/ — отдельная точка проверки.
Откройте сведения о соединении. Найдите сертификат именно этого сайта и проверьте даты начала и окончания действия.
Сверьте имя. В списке Subject Alternative Name должен присутствовать нужный hostname или подходящая wildcard-запись.
Проверьте доверие. Браузер не должен сообщать о недоверенном издателе, несовпадении имени или проблеме цепочки. При спорном результате повторите проверку внешним инструментом.
Проверьте другие точки входа. Отдельно откройте домен с www, без него и важные поддомены, которыми действительно пользуются клиенты.

Фиксируйте проверенный адрес, срок, результат проверки имени и доверия. Статус «SSL установлен» в панели не показывает, какой сертификат получил посетитель.

Сначала определите точный адрес проверки

Сертификат проверяют для имени, к которому подключается клиент. example.com, www.example.com и shop.example.com — разные имена. Даже если все они ведут на один сервер, состав сертификатов и настройки виртуальных хостов могут отличаться. Составьте короткий список реальных точек входа: основной сайт, адрес из рекламы, личный кабинет, API и другие используемые поддомены.

В hostname не входят https://, путь /catalog/ и параметры после знака вопроса. Для обычного HTTPS используется порт 443; если сервис работает на 8443 или другом порту, проверять нужно именно его. Сертификат идентифицирует имя, а выбранный порт определяет, к какому сервису вы подключились.

При переадресации запишите исходный и конечный адреса. Если https://www.example.com/ перенаправляет на https://example.com/, TLS-соединение с первым именем должно состояться до получения HTTP-редиректа. Исправный сертификат конечного домена не исправляет ошибку на исходном адресе. Это особенно важно для старых ссылок и рекламных кампаний.

Как читать список доменов SAN

Ищите расширение Subject Alternative Name, также обозначаемое SAN или «Альтернативное имя субъекта». Именно здесь нужно сопоставлять доменное имя с сертификатом. Не ограничивайтесь строкой Common Name в общих сведениях. Правила сопоставления имени и wildcard описаны в RFC 9525.

Запись в SAN	Проверяемый адрес	Подходит по имени?
`example.com`	`https://example.com/`	Да
`example.com`	`https://www.example.com/`	Нет, если отдельной подходящей записи нет
`*.example.com`	`https://shop.example.com/`	Да, wildcard покрывает один уровень
`*.example.com`	`https://example.com/`	Нет, корневое имя нужно отдельно
`*.example.com`	`https://pay.shop.example.com/`	Нет, это более глубокий уровень

У сертификата может быть несколько SAN: наличие wildcard не исключает отдельной записи корневого домена. Смотрите весь список. Для кириллического домена имя в сертификате может быть представлено ASCII-записью с префиксом xn--; сравнивайте эквивалентные формы, а не объявляйте такую запись чужим доменом только из-за её вида.

Как посмотреть SSL-сертификат в браузере

Проверка сертификата сайта начинается с браузера, в котором воспроизводится проблема. Откройте информацию о сайте или соединении рядом с адресной строкой и перейдите к сведениям о сертификате. Название меню и вид кнопки зависят от браузера и версии: ориентироваться только на привычный значок замка не стоит.

Например, в Firefox путь проходит через панель сведений о сайте, информацию о защищённом соединении и просмотр сертификата. Актуальная последовательность приведена в справке Mozilla о сертификатах. В других браузерах ищите аналогичные разделы «Соединение», «Безопасность» или «Сертификат»; на мобильном устройстве часть полей может быть недоступна в основном интерфейсе.

Проверьте адрес после всех перенаправлений и убедитесь, что смотрите нужный сайт.
Откройте сертификат сервера — конечный сертификат, выданный для сайта, а не только сведения о корневом центре.
Найдите срок действия и SAN, запишите издателя и при необходимости серийный номер или SHA-256-отпечаток.
Посмотрите раздел цепочки или пути сертификации, если он доступен.
Если браузер показал предупреждение, сохраните точный код и текст ошибки. Для диагностики не требуется продолжать вход на сайт вопреки предупреждению.

Поле	Что означает	Практический вопрос
Not Before / «Действителен с»	Начало периода действия	Уже наступило это время? Правильно ли идут часы устройства?
Not After / «Действителен до»	Окончание периода действия	Сколько времени осталось с учётом указанного часового пояса?
Subject Alternative Name	Имена, для которых предназначен сертификат	Есть ли нужный домен, www или подходящий wildcard?
Issuer / «Кем выдан»	Издатель сертификата	Совпадает ли ожидаемая цепочка с наблюдаемой?
Serial Number, SHA-256 Fingerprint	Данные для различения экземпляров сертификата	Один и тот же экземпляр виден на разных узлах?
Цепочка / путь сертификации	Связь сертификата сайта с доверенным корнем через издателей	Удалось ли клиенту построить доверенный путь?

Запись «действителен до 15 ноября» без времени может быть недостаточной при разборе сбоя в день окончания. Если инструмент показывает GMT или UTC, сохраните это обозначение. Если браузер переводит значение в локальное время, учитывайте разницу при сравнении с серверным отчётом. Для рабочего контроля нужен фактический Not After, а не предполагаемая длительность сертификата или срок оплаты услуги.

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

Внешний сервис удобен, когда нужно посмотреть на публичный сайт со стороны. SSL Server Test от Qualys SSL Labs анализирует SSL/TLS-конфигурацию веб-сервера, доступного из интернета. Для запуска нужен hostname. Не передавайте проверочному сервису приватный ключ: для диагностики публично выдаваемого сертификата он не требуется.

Последовательность проверки в SSL Labs

Введите точное имя: например, www.example.com. Не подменяйте его доменом без www, если ошибка возникает на www.
Дождитесь завершения анализа. Отметьте время отчёта: результат прошлой проверки не подтверждает состояние после сегодняшнего изменения.
Посмотрите сведения о сертификате, именах, сроках и доверии к цепочке. Если перечислено несколько адресов сервера, просмотрите результат каждого.
Отдельно прочитайте замечания по протоколам и конфигурации. Они могут требовать работы даже при подходящем и действующем сертификате.
Сохраните ссылку или снимок нужного раздела и повторите проверку другого важного hostname отдельным заданием.

Перед запуском посмотрите настройку видимости результата на публичных досках. Для внутреннего сайта, доступного только через VPN, нужен инструмент внутри соответствующей сети и её согласованная система доверия.

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

Как трактовать ограничения онлайн-проверки

Если сервис не смог подключиться, это ещё не диагноз «сертификат неправильный». Возможны ограничения сети, фильтрация проверочного узла, недоступность порта или ошибка разрешения имени. Сначала прочитайте причину невозможности теста. Если сертификат не получен, его срок и соответствие домену остаются непроверенными.

Открытая проверка домена за CDN обычно видит внешний узел CDN. Она не обязана обращаться к серверу приложения, скрытому за ним. Для нестандартного HTTPS-порта убедитесь, что выбранный инструмент вообще поддерживает такую проверку; при необходимости используйте OpenSSL с явным портом.

При использовании проверки SSL на Рег.ру ориентируйтесь на фактически выданный отчёт. Сравнивайте результаты разных сервисов для одинаковых hostname, порта и близкого времени проверки.

Как проверить SSL-сертификат через OpenSSL

Примеры рассчитаны на установленный OpenSSL и интерактивный терминал Linux/macOS. Замените example.com своим доменом. Если команды нет или версия не понимает параметр, используйте браузер, внешний тест либо помощь администратора.

Проверка имени и доверия

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error

Здесь -connect задаёт адрес и порт, -servername передаёт SNI для выбора виртуального хоста, -verify_hostname проверяет ожидаемое имя, а -verify_return_error останавливает соединение при ошибке верификации. SNI и проверка имени выполняют разные задачи; указание одного SNI не заменяет проверку hostname.

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

Основную проверку запускайте интерактивно, без перенаправления ввода из /dev/null: согласно той же документации, ранний конец ввода может преждевременно закрыть соединение, особенно с TLS 1.3. Дождитесь завершения TLS-рукопожатия и результата верификации, сохраните вывод, затем завершите сеанс клавишами Ctrl+C. Если обмен остановился до результата, сохраните последний этап и прервите ожидание; одна строка CONNECTED не подтверждает успех. Эта команда проверяет TLS-соединение и сертификат; HTTP-ответ и страницу проверяйте отдельно через curl или браузер.

Читайте весь результат, включая сообщения об ошибках. Строка Verify return code: 0 (ok) в корректно выполненной проверке означает отсутствие обнаруженной ошибки верификации с заданными параметрами. Она не доказывает, что проверены все узлы, все браузеры, состояние отзыва во всех системах или работа приложения. При оборванном соединении и неполном выводе сначала выясните причину завершения.

Почему важно хранилище доверенных CA

OpenSSL должен иметь доступ к доверенным корневым сертификатам. Сам проект OpenSSL не поставляет универсальный набор доверенных корней; операционная система или сборка может настраивать свой набор. При необходимости администратор указывает согласованный CA-файл параметром -CAfile. Подробности приведены в описании параметров верификации OpenSSL.

Если браузер открывает сайт, а OpenSSL сообщает о неизвестном издателе, сравните окружения. Причина может быть в недостающей промежуточной цепочке на сервере или в локальном наборе доверенных корней. Не добавляйте полученный с проверяемого сайта сертификат в доверенные ради зелёного результата: тогда вы измените условия проверки, а не установите причину ошибки.

Получение срока действия, SAN и отпечатка

После основной проверки можно вывести ключевые поля полученного сертификата более компактно:

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error </dev/null | openssl x509 -noout -dates -issuer -subject -serial -fingerprint -sha256 -ext subjectAltName

Команда x509 разбирает сертификат и показывает его поля. Параметры -dates, -issuer, -serial и -ext описаны в официальной документации OpenSSL. Такой конвейер удобен для чтения, но успешный разбор полей последней командой не заменяет проверку результата s_client. При автоматизации нужно контролировать ошибки обоих процессов. Если соединение закрылось до получения сертификата или вывод неполон, вернитесь к интерактивной проверке выше: не трактуйте это как доказательство неверного сертификата.

Условный фрагмент вывода:

notBefore=Oct  1 00:00:00 2026 GMT
notAfter=Nov 30 23:59:59 2026 GMT
X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com

В этом учебном примере перечислены два домена и точное время окончания в GMT. Сопоставьте поля со своим hostname и результатом проверки доверия.

Файл можно прочитать командой openssl x509 -in site-certificate.pem -noout -dates -ext subjectAltName. Чтобы связать его с работающим сервером, сравните SHA-256-отпечатки файла и полученного снаружи сертификата.

Как посмотреть передаваемую цепочку

Добавьте к основной команде параметр -showcerts, если администратору нужен список присланных сервером сертификатов. Этот список не равен доказанному доверенному пути: клиент ещё должен построить и проверить цепочку. Сервер обычно передаёт сертификат сайта и промежуточные сертификаты, необходимые для её построения.

Отсутствие корневого сертификата в переданном списке само по себе не означает ошибку. Корень должен быть известен клиенту как доверенный; стандарт допускает не отправлять его в цепочке. Это следует из раздела Certificate в RFC 8446. Ищите конкретную причину отказа, а не требуйте одинакового количества сертификатов у всех сайтов.

Что можно проверить командой curl

curl помогает понять, проходит ли HTTPS-соединение до получения HTTP-ответа. По умолчанию он проверяет доверие сертификату и имя из URL; используемое хранилище CA зависит от сборки и TLS-библиотеки. Это описано в документации curl о сертификатах.

curl -q -I --connect-timeout 10 --max-time 20 https://example.com/

-q в начале команды отключает чтение пользовательского файла настроек curl, -I запрашивает только HTTP-заголовки методом HEAD, а ограничения времени помогают не ждать зависшее соединение бесконечно. В Windows при необходимости вызывайте именно curl.exe, чтобы не попасть на одноимённый псевдоним оболочки. Если исполняемого файла нет, выберите другой доступный способ проверки.

Не добавляйте -k или --insecure: они отключают проверку, ради которой выполняется диагностика. При ошибке запишите полный текст, hostname и окружение. Не заменяйте проверку доверия пробным запросом с отключённой защитой.

Получен HTTP 200. Соединение и HEAD-запрос прошли для этой точки; содержимое страницы и сценарии пользователя ещё не проверены.
Получен HTTP 301 или 302. Посмотрите заголовок Location и отдельно проверьте конечный HTTPS-адрес. Команда выше не следует редиректу автоматически.
Получен HTTP 405. Сервер может не поддерживать HEAD для этого пути. Это не равнозначно ошибке сертификата.
Получен HTTP 500. TLS-соединение состоялось, но сервер сообщил об ошибке обработки запроса. Нужна диагностика приложения.
Нет HTTP-ответа. Разберите причину: DNS, подключение, тайм-аут, TLS или проверка сертификата. Не все сбои происходят на одном этапе.

Параметры описаны в руководстве curl. Дополнительно проверьте нужный сценарий в браузере: код завершения curl без дополнительных условий не равнозначен успешному HTTP-статусу или исправной покупке.

Ошибки SSL-сертификата: как выбрать следующий шаг

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

Наблюдение	Что проверить	Следующее действие
Сертификат просрочен	Not After фактически полученного экземпляра и время клиента	Определить затронутые узлы и передать администратору данные для восстановления действующего сертификата
Сертификат ещё не действителен	Not Before и системные часы	Исключить неверное время; затем проверить, какой экземпляр установлен на узле
Имя не совпадает	Точный hostname, SAN, SNI и адрес подключения	Разобраться, не выдается ли сертификат соседнего сайта или отсутствующего поддомена
Издатель не доверен, цепочка не строится	Промежуточные сертификаты, доверенные CA клиента и полное сообщение ошибки	Сравнить проверку на актуальном клиенте с конфигурацией сервера
Сертификат отозван	Точное сообщение клиента или проверочного сервиса и выданный экземпляр	Передать инцидент администратору и удостоверяющему центру; будущая дата окончания не снимает проблему
Ошибка появляется периодически	IP, семейство адресов, узел балансировщика, время и отпечаток	Найти точку, которая отличается, и повторить адресную проверку после исправления
TLS проходит, сайт отвечает 500	HTTP-ответ, журналы приложения и зависимые сервисы	Перейти к диагностике веб-приложения, сохранив подтверждение успешного TLS
Проверяющий сервис не подключился	Разрешение имени, доступность порта и сетевые ограничения	Восстановить возможность проверки; результат сертификата пока неизвестен

Когда причина находится на устройстве посетителя

Если предупреждение появляется только на одном компьютере, начните с даты, времени и обновлений браузера. Неверные часы могут сделать действующий сертификат «истёкшим» или «ещё не действующим» для конкретного клиента. Mozilla отдельно разбирает такие ситуации в инструкции по ошибкам времени.

Сравните тот же адрес на другом устройстве и в другой сети. Если издатель или отпечаток отличается только в корпоративной сети, передайте наблюдение её администратору: соединение может проходить через локальный HTTPS-прокси. Не меняйте настройки доверия наугад. Цель сравнения — определить, на каком участке появляется отличие.

Несколько IP, балансировщик и CDN: почему проверки расходятся

У одного hostname могут быть несколько адресов и узлов. После изменения один сервер способен отдавать новый сертификат, а другой — старый. Сравнивайте результаты по известным точкам подключения.

Проверьте IPv4 и IPv6

Сопоставьте используемые DNS-записи A и AAAA с фактической инфраструктурой. Если IPv4 ведёт на обновлённый сервер, а IPv6 — на забытый узел, разные посетители могут получать разные результаты. Для отдельной проверки семейств адресов можно выполнить:

curl -q -4 -I --connect-timeout 10 --max-time 20 https://example.com/
curl -q -6 -I --connect-timeout 10 --max-time 20 https://example.com/

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

Подключение к конкретному известному узлу

Если администратор знает IP собственного сервера, можно адресно проверить его, сохранив имя сайта для SNI и проверки сертификата:

openssl s_client -connect 192.0.2.10:443 -servername example.com -verify_hostname example.com -verify_return_error

192.0.2.10 — демонстрационный адрес. Вместо него укажите известный IP своего узла, а вместо example.com — проверяемое имя. В таком тесте IP определяет маршрут подключения, а домен остаётся проверяемой идентичностью. Просто открыть https://IP-адрес/ — другая проверка: она может выбрать иной виртуальный хост и потребовать сертификат для самого IP.

По каждому узлу сохраните результат доверия, Not After и отпечаток. Разные отпечатки не обязательно являются ошибкой: инфраструктура может использовать разные допустимые сертификаты. Важно, чтобы каждый фактически используемый экземпляр подходил имени, действовал и проходил нужную проверку доверия.

Разделите внешний сертификат CDN и сертификат origin

При использовании CDN возможны два участка TLS: от посетителя до CDN и от CDN до исходного сервера, или origin. В документации Cloudflare это отражено в понятиях edge certificate и origin certificate. Браузер посетителя видит внешний сертификат; состояние сертификата origin таким просмотром не определяется.

Сверяйте, какой участок проверяет инструмент: успешный внешний тест не закрывает проблему CDN–origin, а файл на исходном сервере не подтверждает состояние внешнего узла CDN.

У origin может быть отдельная согласованная модель доверия, рассчитанная на соединение с CDN. Проверка обычным браузером напрямую не всегда воспроизводит этот сценарий. Условия такого подключения определяет администратор инфраструктуры; отключать проверку сертификата ради формального успеха не нужно.

Что передать поддержке и как подтвердить исправление

Хорошее обращение сокращает число уточняющих вопросов. Вместо «сайт пишет, что SSL неправильный» соберите данные, позволяющие повторить результат.

Точный URL и порт. Сохраните www, поддомен и исходный адрес перед редиректом.
Дата и время наблюдения. Укажите часовой пояс, устройство, браузер и сеть, в которой проявилась ошибка.
Полный код и текст ошибки. Приложите снимок предупреждения или диагностический вывод без паролей, токенов и других секретов.
Сведения сертификата. SAN, Not Before, Not After, издатель и SHA-256-отпечаток помогут установить конкретный экземпляр.
Адрес узла, если он известен. Отметьте IPv4 или IPv6, обычное подключение через DNS либо адресную проверку.
Сравнение. Где ошибка есть, где её нет, какой внешний сервис использовали и когда завершился его тест.
Недавние изменения. Перенос сайта, смена DNS, включение CDN, замена сертификата или изменение балансировщика — полезные факты для поиска причины.

Пример сообщения: «31 октября в 12:10 UTC на www.example.com:443 браузер сообщает о несовпадении имени. В SAN полученного сертификата есть только example.com. На адресе без www ошибка не воспроизводится. Внешняя проверка www показывает тот же результат». Такая запись сразу определяет проверяемое имя и расхождение.

Чек-лист после исправления

Повторить исходную проверку на том же hostname и порту, где воспроизводилась ошибка.
Убедиться, что снаружи выдается ожидаемый действующий сертификат, а не только обновлён файл в панели.
Проверить доверие и SAN, сохранить новый Not After и отпечаток.
Проверить используемые адреса с www и без него, поддомены и выявленные проблемные узлы.
Обновить внешний отчёт и убедиться, что это результат после изменения.
Открыть страницу и выполнить важное действие: вход, отправку формы или другой согласованный сценарий.
Записать результат и ответственного, чтобы следующий инцидент начинался с понятной истории.

Как организовать регулярный контроль срока действия SSL

Заведите реестр: hostname, порт, назначение, владелец настройки, точка завершения TLS, фактический Not After, дата последней проверки и канал уведомлений. Для нескольких узлов добавьте отметки об отличиях. Реестр должен отражать публичное состояние сервиса и отдельно — внутренние участки, если они есть.

Выберите интервал с учётом важности сайта и срока его сертификатов. Например, ежедневный базовый контроль и повторная проверка сразу после изменения DNS, CDN или конфигурации помогут сделать наблюдения регулярными. Порог предупреждения должен оставлять вашей команде время на диагностику и исправление, а не срабатывать только в момент истечения.

Контролируйте не только количество оставшихся дней, но и невозможность соединения, ошибку имени и доверия. Уведомление должно приходить конкретному ответственному; после изменения контактов проверьте доставку тестового сообщения. Статус «автопродление включено» полезен для эксплуатации, однако фактический сертификат на публичном узле всё равно требует отдельного контроля.

Если хотите упорядочить защиту и сопровождение сайта, познакомьтесь с SiteGuard и обсудите задачи вашего проекта. Начать удобно с перечня доменов и результатов диагностики: так проще сформулировать, какие проверки нужны, кто отвечает за реакцию и что считать восстановлением работы.

Частые вопросы о проверке SSL-сертификата

Можно ли проверить SSL-сертификат без доступа к хостингу?

Да. Публичный сертификат можно посмотреть в браузере и получить при обычном TLS-подключении; внешний тест также не требует входа в панель сайта. Доступ администратора понадобится для исправления конфигурации и проверки недоступных извне участков. Приватный ключ для просмотра открытого сертификата передавать никому не нужно.

Достаточно ли посмотреть срок действия SSL?

Нет. Срок — только один параметр. Дополнительно нужны соответствие имени и доверенная цепочка. После этого отдельно оценивают доступность страницы и сценариев пользователя. Если сайт работает через несколько узлов, успешное наблюдение одного соединения не описывает всю инфраструктуру.

Почему в панели новый сертификат, а браузер показывает старый?

Сравните отпечатки и установите, где завершается TLS. Возможные направления проверки — другой виртуальный хост, не применённая конфигурация, отдельный узел балансировщика или внешний сертификат CDN. Доказательство исправления — ожидаемый результат нового подключения к нужному узлу, а не только наличие нового файла.

Означает ли ошибка «сертификат истёк», что истёк приватный ключ?

Нет. Дата окончания в сертификате относится к сроку его действия. Это не сообщение о самостоятельном «истечении» приватного ключа. Для диагностики фиксируют данные полученного сертификата; решения о выпуске, замене ключа и восстановлении конфигурации принимают после установления причины.