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

Термин «SSL-сертификат» широко используют для сертификата, с которым сайт устанавливает защищённое HTTPS-соединение. На практике актуальные соединения используют TLS, а старые версии SSL считаются устаревшими. Сертификат связывает открытый ключ с идентификаторами, прежде всего DNS-именами, и участвует в проверке подлинности сервера. Он не подтверждает добросовестность владельца сайта и не делает содержимое страницы автоматически безопасным.

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

Что проверять в сертификате

Полезная проверка состоит минимум из пяти частей.

Имя сайта. Запрошенное DNS-имя должно соответствовать идентификатору в расширении Subject Alternative Name, обычно сокращаемом до SAN. Сертификат для example.com не обязательно подходит www.example.com, если второе имя не включено отдельно или не покрывается допустимым шаблоном. Шаблон *.example.com не следует трактовать как разрешение для любого количества уровней.

Период действия. Поля Not Before и Not After задают временной интервал. Проверяющий клиент сравнивает его со своими часами, поэтому сильно неверное время на устройстве может вызвать ошибку. Дата должна оцениваться вместе с часовым поясом и точным временем, а не только по календарному дню.

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

Подпись и ограничения. Клиент проверяет криптографическую подпись, назначение ключа, базовые ограничения и другие правила профиля X.509. Вручную смотреть только поле Issuer недостаточно: текстовое имя издателя не заменяет криптографическую проверку.

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

Проверка в браузере

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

1. адрес страницы и имена в SAN;
2. начало и окончание периода действия;
3. конечный сертификат и промежуточные элементы цепочки;
4. текст ошибки, если браузер не доверяет соединению.

Значок защищённого соединения означает, что канал до выбранного узла прошёл проверки браузера. Он не гарантирует честность магазина, отсутствие вредоносного JavaScript или качество обработки данных после получения сервером.

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

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

Команда ниже устанавливает TLS-соединение и выводит присланные сервером сертификаты и параметры рукопожатия:

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

-connect задаёт адрес и порт, а -servername передаёт SNI. SNI особенно важен на общем IP с несколькими сайтами: без него сервер может показать сертификат другого виртуального хоста. Перенаправление из /dev/null завершает ввод после рукопожатия. Команда не меняет сервер, но создаёт обычное сетевое подключение; проверяйте только допустимые для вас узлы.

В выводе обратите внимание на цепочку Certificate chain, итог верификации, выбранную версию TLS и сертификат первого элемента. Однако строку Verify return code: 0 (ok) нельзя переносить между машинами как абсолютную гарантию: результат зависит от локального хранилища и параметров клиента.

Сохранённый локальный сертификат в PEM-формате можно изучить без сетевого обращения:

openssl x509 -in certificate.pem -noout -subject -issuer -dates -ext subjectAltName

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

Практический пример: сертификат подходит корневому домену, но не www

Предположим, https://example.com открывается нормально, а https://www.example.com выдаёт ошибку имени.

1. Получите сертификат отдельно для каждого имени, обязательно передавая соответствующий SNI.
2. Сравните SAN. Если там есть только example.com, сертификат не покрывает www.example.com автоматически.
3. Проверьте DNS обоих имён. Они могут вести к разным платформам, и одна из них использует старую конфигурацию.
4. Выпустите или настройте сертификат с нужными именами на том сервере, который фактически отвечает за www.
5. После установки снова проверьте внешний узел, цепочку и HTTPS-перенаправления.

Простое добавление www в DNS не добавляет его в ранее выпущенный сертификат. И наоборот, наличие имени в SAN не создаёт DNS-запись. Это независимые части конфигурации.

Почему цепочка бывает неполной

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

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

Частые ошибки

• Смотреть только на Not After и не проверять SAN.
• Запускать openssl s_client без SNI для сайта на общем IP.
• Считать самоподписанный сертификат обязательно вредоносным. Он может быть уместен в контролируемой закрытой системе, но публичные клиенты не будут доверять ему без отдельной настройки.
• Добавлять неизвестный корень в доверенные вместо устранения причины.
• Путать сертификат сайта с регистрацией домена или правом на бренд.
• Проверять файл на диске, но не сертификат, который реально отдаёт балансировщик.
• Забывать о промежуточных узлах: CDN, reverse proxy и ingress могут завершать TLS раньше приложения.
• Отключать проверку сертификата в клиенте как постоянное решение. Это устраняет важную защиту от подмены.

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

Частые вопросы

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

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

Почему браузер и OpenSSL могут оценивать сертификат по-разному?

Они могут использовать разные хранилища доверенных корней, правила построения цепочки и версии TLS. Кроме того, без параметра SNI команда OpenSSL способна получить сертификат другого виртуального хоста.

Можно ли безопасно игнорировать предупреждение HTTPS?

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