openssl s_client: 30 проверенных команд для диагностики TLS

Ниже — 30 команд, выполненных 13 ноября 2026 года на публичных адресах. Это карта диагностики, а не обещание одинакового вывода на любом сервере. Коды и фрагменты взяты из сохранённого запуска; динамические сертификаты и настройки могут измениться.

Что понадобится

OpenSSL с командой s_client, доступ к нужному TCP-порту и имя хоста, которое ожидает клиент. Замер сделан на OpenSSL 3.5.8; опция -no-interactive проверена именно в этой версии. Если ваша сборка её не знает, уберите эту опцию и завершайте ввод через </dev/null.

Шаг 1. Проверьте сертификат, цепочку и имя

Начните со строгой команды из начала статьи. Обычный s_client показывает ошибку проверки, но по умолчанию может продолжить соединение; это прямо описано в руководстве OpenSSL. Флаг -verify_return_error прерывает рукопожатие при ошибке проверки, а -verify_hostname сравнивает сертификат с ожидаемым DNS-именем. -servername отвечает за SNI и сам по себе имя не проверяет.

$ openssl s_client -connect enterno.io:443 -servername enterno.io -verify_hostname wrong.example -verify_return_error -no-interactive
Verification error: hostname mismatch
Verify return code: 62 (hostname mismatch)
# exit 1

-showcerts показывает сертификаты, которые прислал сервер; это не доказательство полной доверенной цепочки. В замере -status дал OCSP response: no response sent: сервер не прислал stapled-ответ на этот запрос, но один этот факт не доказывает отзыв сертификата. Для срока действия конкретного сертификата сохранённый вывод -showcerts можно передать в openssl x509 -noout -dates; прежде убедитесь, что извлекли именно leaf-сертификат.

Подробности: проверка сертификата, типы сертификатов и этапы TLS-рукопожатия.

Шаг 2. Ограничьте версию TLS, ALPN и параметры обмена

Для проблемы совместимости проверьте TLS 1.2 и 1.3 отдельно. В нашем соединении обе версии работают. Попытка TLS 1.1 завершилась ещё в локальной библиотеке строкой no protocols available; из неё нельзя заключить, разрешает ли сервер TLS 1.1. Verify return code: 0 (ok) в таком неуспешном выводе не означает успешное рукопожатие.

$ openssl s_client -connect enterno.io:443 -servername enterno.io -tls1_1 -no-interactive
error:0A0000BF:SSL routines:tls_setup_handshake:no protocols available
# exit 1

С -alpn h2,http/1.1 сервер выбрал h2, а при предложении только http/1.1 — его. Без -alpn вывод был No ALPN negotiated; это поведение клиента в данном тесте, не отсутствие HTTP/2 на сервере. -groups ограничивает предлагаемые группы, -ciphersuites — наборы TLS 1.3. Их успех говорит только о конкретном сочетании клиента и сервера.

Если проблема возникает только в браузере, сопоставьте выбор ALPN с HTTP/2 и HTTP/3. Общую схему протокола даёт руководство по SSL/TLS.

Шаг 3. Отделите выбор виртуального хоста от проверки сертификата

На одном IP могут работать разные TLS-хосты. Мы подключились к 81.163.20.249:443 с SNI enterno.io и получили проверяемый сертификат сайта. Без SNI тот же адрес выдал TRAEFIK DEFAULT CERT, самоподписанный. Команда без строгой проверки при этом завершилась с exit 0 — важный аргумент против проверки по одному коду процесса.

$ openssl s_client -connect enterno.io:443 -noservername -no-interactive
subject=CN=TRAEFIK DEFAULT CERT
Verify return code: 18 (self-signed certificate)
# exit 0

При подключении к IP используйте -servername для выбора виртуального хоста и -verify_hostname для проверки сертификата. -state и -tlsextdebug полезны, когда рукопожатие оборвалось раньше сводки. -reconnect показывает поведение повторных соединений; не считайте его отдельным тестом валидности сертификата.

Шаг 4. Воспроизведите ошибки и STARTTLS

На тестовых доменах badssl.com строгая проверка прервала обмен из-за истёкшего, самоподписанного и не подходящего по имени сертификата. Отдельно проверен SMTP STARTTLS: -starttls smtp сначала выполняет протокольный переход, затем TLS. Это не тот же сценарий, что прямой TLS на порту 465.

Проверка и следующий шаг

Успешный результат для конкретного имени: exit 0, Verification: OK, Verified peername при заданном -verify_hostname, ожидаемая версия TLS и, если важен HTTP/2, согласованный ALPN. Если нужен быстрый взгляд на срок, цепочку и конфигурацию HTTPS без ручного чтения дампа, запустите проверку SSL на enterno; ручной вывод остаётся источником деталей рукопожатия.

Если не получилось

Как сделан материал

13 ноября 2026 года скрипт method.py выполнил 30 команд с OpenSSL 3.5.8 на Linux-сервере. Для каждой сохранены точный argv, stdout, stderr и exit code. Целевые хосты: публичные enterno.io, badssl.com и smtp.gmail.com. Фрагменты таблицы сокращены; полный вывод находится в данных исследования. Текст подготовлен с помощью AI на данных проверок; технические выводы сверены с сохранённым выводом и документацией OpenSSL.

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

Почему s_client вернул exit 0 при ошибке сертификата?

По умолчанию диагностический клиент может продолжить обмен после ошибки проверки. На нашем тесте без SNI это произошло; добавьте -verify_return_error.

Достаточно ли -servername для проверки домена?

Нет. Этот параметр отправляет SNI; ожидаемое имя для проверки задаёт -verify_hostname.

Как увидеть сертификаты сервера?

Добавьте -showcerts. Команда показывает присланную цепочку, а не все локальные доверенные корни.

Почему TLS 1.1 не подключился?

В нашем запуске библиотека OpenSSL отказалась начать такой обмен. По этому тесту нельзя оценить политику сервера.

Источники

• OpenSSL 3.5: s_client manual
• OpenSSL: verification options
• RFC 6066: SNI
• RFC 7301: ALPN