Как проверить подлинность HTTPS-сертификата сайта без браузера

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

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

Зачем вообще проверять сертификат вручную

Вот типичные ситуации, когда без этого не обойтись:

• Вы настраиваете сервер и хотите убедиться, что сертификат установлен правильно, цепочка полная, и клиенты не получат ошибку.
• Вы отлаживаете сетевое взаимодействие — например, ваше приложение ругается на SSL, а браузер открывает сайт нормально.
• Вы проверяете чужой ресурс: не перехватывает ли кто-то трафик через свой сертификат (атака «человек посередине»).
• У вас нет браузера под рукой — вы работаете на сервере по SSH, в CI/CD-пайплайне или в контейнере.
• Сертификат скоро истекает, и вы хотите проверить точную дату, не открывая десяток вкладок.

Во всех этих случаях браузер — не лучший инструмент. Он даёт ответ «да/нет», но не даёт деталей. А детали — это то, что нужно, когда что-то не работает.

openssl — ваш главный инструмент

Утилита openssl есть практически на любой системе: Linux, macOS, Windows (через WSL или сборку вроде OpenSSL for Windows). Это швейцарский нож для работы с TLS/SSL, и проверка сертификатов — одна из базовых задач.

Базовая команда для получения сертификата

Вот самый простой способ посмотреть сертификат сайта:

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

Эта команда подключится к серверу по TLS и выведет всю цепочку сертификатов. Флаг -servername нужен для SNI (Server Name Indication) — без него сервер может отдать не тот сертификат, если на одном IP висит несколько сайтов.

Вывода будет много. Если вам нужен только сам сертификат в читаемом виде, добавьте -showcerts и перенаправьте вывод:

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

Здесь происходит две вещи: первая команда получает сертификат с сервера, вторая — распаршивает его и показывает в структурированном виде. echo в начале нужно, чтобы закрыть соединение сразу после получения данных — иначе s_client будет ждать ввода.

Что смотреть в выводе

Когда вы увидите структурированный вывод x509 -text, вот на что обращать внимание:

• Subject — кому выдан сертификат. Должен совпадать с доменом, который вы проверяете.
• Issuer — кто выдал. Если это Let’s Encrypt, DigiCert, Sectigo — нормально. Если что-то незнакомое — повод насторожиться.
• Validity — срок действия. Not Before и Not After. Проверьте, не истёк ли сертификат и не выдан ли он на слишком долгий срок (больше 398 дней — это уже нарушение отраслевых правил).
• Subject Alternative Names (SAN) — список доменов, на которые действует сертификат. Именно здесь проверяется, покрывает ли сертификат нужный вам адрес.
• Public Key Algorithm и размер ключа. RSA 2048+ или ECDSA P-256/P-384 — нормально. RSA 1024 — уже слабо.
• Signature Algorithm — SHA-256 и выше приемлемо. SHA-1 — устарел и небезопасен.

Проверить только срок действия

Если вам нужно быстро узнать, когда истекает сертификат:

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

Вывод будет примерно таким:

notAfter=Mar 15 23:59:59 2026 GMT

Это удобно для скриптов мониторинга. Можно написать простую проверку: если дата истечения меньше, чем через 30 дней — алерт.

Проверить конкретный TLS-версию

Иногда нужно убедиться, что сервер поддерживает нужную версию протокола:

openssl s_client -connect example.com:443 -tls1_3

Если сервер не поддерживает TLS 1.3, команда выдаст ошибку рукопожатия. Аналогично можно проверить -tls1_2, -tls1_1 и так далее.

Проверка цепочки сертификатов

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

Посмотреть всю цепочку:

openssl s_client -connect example.com:443 -servername example.com -showcerts

В выводе вы увидите несколько блоков -----BEGIN CERTIFICATE-----. Первый — сертификат сайта, остальные — промежуточные и, возможно, корневой.

Проверить, что цепочка валидна:

openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt <(echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null)

Если ответ OK — цепочка доверия корректна. Если нет — какой-то сертификат не подписан доверенным корнем, или порядок в цепочке нарушен.

На macOS путь к системному хранилищу сертификатов другой. Проще использовать встроенную утилиту security:

openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl verify -

Проверка через curl — если нужно быстро

curl не показывает сертификат так подробно, как openssl, но даёт ключевую информацию:

curl -vI https://example.com 2>&1 | grep -E "(SSL|subject|issuer|expire)"

Или более подробно:

curl -vI https://example.com 2>&1 | grep -A 5 "Server certificate"

Вывод покажет subject, issuer и даты. Это быстрый способ проверки, когда не нужны все детали.

Если вы хотите увидеть полный сертификат через curl, можно использовать опцию -o с выводом в файл, а потом распарсить через openssl:

curl -s --cacert /dev/null --max-time 5 https://example.com -o /dev/null -w "%{ssl_issuer}" 2>&1

Проверка сертификата из файла

Иногда у вас уже есть файл сертификата (например, вы загрузили его с сервера или получили по почте). Проверить его можно без подключения к сети:

openssl x509 -in certificate.crt -noout -text

Проверить, соответствует ли сертификат закрытому ключу:

openssl x509 -noout -modulus -in certificate.crt | openssl md5
openssl rsa -noout -modulus -in private.key | openssl md5

Если хеши совпадают — сертификат и ключ принадлежат друг другу. Если нет — вы пытаетесь использовать непарную пару, и соединение не установится.

Проверка отзыва сертификата (CRL и OCSP)

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

Проверка через OCSP (Online Certificate Status Protocol):

openssl ocsp -issuer issuer.pem -cert cert.pem -url http://ocsp.example.com -resp_text

В выводе будет статус: good, revoked или unknown.

На практике OCSP работает не всегда гладко — многие серверы не отвечают на OCSP-запросы, или ответ приходит с задержкой. Браузеры часто игнорируют недоступность OCSP (soft fail), но для серверной диагностики это полезный инструмент.

Сравнение инструментов

Инструмент	Что умеет	Когда использовать
openssl s_client	Полный доступ к TLS-рукопожатию, цепочке сертификатов, деталям сертификата	Диагностика, отладка, скрипты мониторинга
curl	Быстрая проверка базовых данных сертификата	Экспресс-проверка, отладка API
nmap (ssl-enum-ciphers)	Сканирование поддерживаемых шифров и протоколов	Аудит безопасности сервера
testssl.sh	Комплексная проверка TLS: протоколы, шифры, уязвимости, сертификат	Полный аудит безопасности TLS-конфигурации

Что делать в зависимости от вашей ситуации

Если вы системный администратор и настраиваете сервер: используйте openssl s_client для проверки цепочки и сроков. Добавьте проверку в ваш мониторинг — простой скрипт, который раз в сутки проверяет дату истечения и шлет алерт за 30 дней.

Если вы разработчик и отлаживаете клиент: используйте openssl s_client с указанием конкретной версии TLS. Убедитесь, что ваш клиент использует тот же набор шифров, что и сервер. Часто проблема не в сертификате, а в несовпадении шифров.

Если вы проверяете чужой сайт: посмотрите issuer — это должен быть известный удостоверяющий центр. Проверьте SAN — совпадает ли домен. Проверьте срок действия. Если что-то не так — это не обязательно атака, возможно, администратор просто забыл обновить сертификат.

Если вы пишете скрипт для мониторинга: используйте openssl s_client с -brief (если поддерживается) или парсите вывод -text. Вот минимальный пример для bash:

#!/bin/bash
DOMAIN="example.com"
EXPIRY=(echo | openssl s_client -connect{DOMAIN}:443 -servername ${DOMAIN} 2>/dev/null | openssl x509 -noout -enddate | cut -d= -f2)
EXPIRY_EPOCH=(date -d "{EXPIRY}" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (EXPIRY_EPOCH - NOW_EPOCH) / 86400 ))
echo "Сертификат истекает через ${DAYS_LEFT} дней"
if [ ${DAYS_LEFT} -lt 30 ]; then
    echo "ВНИМАНИЕ: менее 30 дней до истечения!"
fi

Частые ошибки при проверке

• Забывают -servername для SNI. Без этого флага сервер может отдать дефолтный сертификат, а не тот, который вы ожидаете. Результат — ложная тревога.
• Не проверяют цепочку, только сертификат сайта. Сертификат сайта может быть валидным, но если промежуточний сертификат не установлен на сервере — клиенты получат ошибку.
• Смотрят только на даты, не на issuer. Самоподписанный сертификат может быть валидным по сроку, но не будет доверенным для клиентов.
• Используют устаревшие версии OpenSSL. Старые версии могут не поддерживать TLS 1.3 или современные шифры, что приводит к ложным ошибкам подключения.
• Не проверяют соответствие ключа и сертификата. Сертификат может быть правильным, но если на сервере установлен другой закрытый ключ — соединение не установится.
• Игнорируют отзыв сертификата. Сертификат может быть действительным по сроку, но отозванным. Проверка OCSP или CLR решает эту проблему.

Как лучше сделать: практические рекомендации

1. Всегда используйте -servername при проверке через openssl s_client. Это критично для серверов с несколькими сайтами на одном IP.
2. Проверяйте не только срок, но и цепочку доверия. openssl verify с системным хранилищем сертификатов — ваш друг.
3. Автоматизируйте мониторинг сроков истечения. Сертификат, который истёк вчера, — это даунтайм. Лучше знать за месяц.
4. Храните сертификаты и ключи отдельно. Сертификат — публичный, ключ — секретный. Проверяйте их соответствие командой с хешем модуля.
5. Используйте testssl.sh для комплексного аудита. Это обёртка над openssl, которая проверяет всё сразу: протоколы, шифры, уязвимости, сертификат.
6. Проверяйте с разных сетей. Иногда проблема не в сертификате, а в прокси или файрволе, который подменяет сертификат.

Итог

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

Если вы администрируете сервер — добавьте проверку сроков в мониторинг. Если отлаживаете клиент — проверяйте цепочку и версию TLS. Если проверяете чужой сайт — смотрите на issuer и SAN.

Браузер — это хорошо, но терминал — это правда.