В 2026-м «проверить TLS» — это не только убедиться, что сертификат не протух. Обычно нужно быстро ответить на вопросы: какие версии TLS реально доступны, какие cipher suites договорятся с клиентами, включён ли TLS 1.3, как работает OCSP stapling, не забыли ли HSTS, и почему внешний сканер вдруг ругается на то, что «вроде бы работало».
Для этого чаще всего берут один из трёх CLI-инструментов: testssl.sh, sslscan и sslyze. Они пересекаются по задачам, но у каждого свой характер: первый — «комбайн-аудитор», второй — «быстрый сканер шифров», третий — «автоматизируемый» вариант, который удобно встраивать в пайплайны.
Ниже — практичное сравнение: что именно проверяет каждый инструмент, где он полезен, какие есть ловушки, и как собрать из них рабочую схему контроля TLS-конфига.
Что важно проверять в TLS в 2026 (чтобы потом не было сюрпризов)
Инструменты отличаются глубиной, но набор типовых проблем у админов примерно одинаковый. Прежде чем сравнивать утилиты, полезно зафиксировать чек-лист — что именно вы хотите контролировать регулярно.
Версии протокола и реальный TLS 1.3
Важно не «включён ли TLS 1.3 в конфиге», а договаривается ли он на практике с типичными клиентами. На прокси/балансировщиках и при цепочке вида CDN → LB → ingress → backend легко получить ситуацию, когда снаружи TLS 1.3 есть, а до апстрима внутри уходит TLS 1.2 с устаревшим набором параметров.
Cipher suites: что доступно, что реально выбирается и кто управляет выбором
Даже сейчас встречаются ошибки, которые потом «вылезают» в оценках и совместимости:
- разрешены лишние наборы шифров «на всякий случай», из-за чего расширяется поверхность атаки и падают внешние оценки;
- перепутан приоритет сервера/клиента (актуально для TLS 1.2 и ниже);
- для RSA/ECDSA сертификатов наборы выглядят «правильно», но часть клиентов договаривается на неожиданном варианте из-за нюансов библиотеки и приоритета.
OCSP stapling: включён ли он и работает ли стабильно
Включить stapling — полдела. Важнее, чтобы сервер действительно прикладывал OCSP-ответ в рукопожатии, обновлял его вовремя, и не «ломал» выдачу на коротких таймаутах к OCSP-респонденту. На нагруженных фронтах проблемы со stapling часто проявляются как плавающие ошибки у части клиентов.
HSTS и смежные заголовки
HSTS — часть устойчивой HTTPS-стратегии. Ошибки обычно две: заголовок не выдаётся на всех ответах (редиректы/ошибки), либо включён слишком агрессивно без понимания отката. TLS-сканеры могут подсветить наличие заголовка, но корректность политики всегда остаётся на совести администратора.
Цепочка сертификатов и нюансы совместимости
Даже при корректном сертификате можно получить предупреждения из-за неполной цепочки, лишних промежуточных, неверного порядка, несовпадения SNI и сертификата на multi-tenant фронте. Классика: «в браузере открывается, а у части клиентов нет».
Хорошая практика: рассматривать TLS как интерфейс вашего сервиса. Любое «лишнее» в протоколах и cipher suites — это поддержка того, что вы не планировали поддерживать.
testssl.sh: «швейцарский нож» для ручного аудита
testssl.sh чаще всего запускают руками, когда нужно понять картину целиком: версии TLS, поддержка шифров, особенности рукопожатия, часть уязвимостей/мисконфигов, плюс вывод в формате, удобном для отчёта.
Сильные стороны
- Широкий охват: много проверок «из коробки» по типовым проблемам настройки.
- Читаемый отчёт: удобно, когда нужно объяснить изменения коллегам или приложить результат к тикету.
- Хорош в расследованиях: когда «у пользователя не открывается», а вы подозреваете пересечение TLS-версий, SNI и цепочек.
Слабые стороны и нюансы
- Скорость: глубокие проверки могут занимать заметное время, особенно на нескольких хостах/портах.
- Шум: обилие секций иногда мешает, если вам нужно всего два-три параметра.
- Детерминированность для CI: для «падать пайплайну» лучше заранее решить, какие проверки критичны, иначе можно утонуть в меняющихся предупреждениях при обновлениях инструмента.
Когда выбирать testssl.sh
Когда вы делаете первичный аудит, готовите миграцию на новые политики TLS, меняете балансировщик/ingress, или вам нужно максимально «толстое» заключение по узлу перед тем, как ориентироваться на внешний уровень «A+».
Если вы видите проблемы не в конфиге, а в цепочке или сроках (или хотите стандартизировать выпуск на разных проектах), проще заранее выстроить процесс с понятными сертификатами и обновлением. В таких случаях удобнее не «чинить по месту», а централизованно управлять выпуском и заменой через SSL-сертификаты.
sslscan: быстрый профиль протоколов и cipher suites
sslscan — утилита из разряда «быстро посмотреть, что сервер вообще предлагает». Её любят за простоту: запустил — получил список протоколов и cipher suites, без лишних слоёв отчётности.
Сильные стороны
- Скорость и предсказуемость: удобно для регулярных проверок и быстрого диффа после изменений конфигурации.
- Фокус на cipher suites: если задача — убрать «лишнее» и убедиться, что осталось «как задумано», sslscan часто достаточно.
- Легко скриптуется: минимализм помогает автоматизации, если вы аккуратно парсите вывод.
Ограничения
- Меньше контекста: sslscan не пытается быть полноценным аудит-репортом и может не подсветить «политические» вещи вроде HSTS или поведение OCSP stapling в форме, удобной для отчёта.
- Риск неправильных ожиданий: видеть список cipher suites — не то же самое, что понимать, какие из них реально будут использоваться при разных клиентах и настройках приоритета.
Когда выбирать sslscan
Когда нужен быстрый контроль «не отросло ли лишнего» в cipher suites после деплоя, обновления пакетов, смены образа контейнера или добавления нового виртуального хоста на фронте.
sslyze: автоматизация и проверка TLS «как код»
sslyze выбирают, когда важны машиночитаемые результаты и интеграция в процессы. Он хорошо подходит для регулярных проверок на флоте хостов и для «policy as code», где вы фиксируете требования и валидируете их на каждом релизе.
Сильные стороны
- Удобство для автоматизации: типичный кейс — прогнать десятки доменов/эндпоинтов и собрать структурированный результат.
- Хорошая детализация по TLS: версии, наборы, параметры сертификата, SNI и связанные вещи в рамках рукопожатия.
- Подходит для регрессионных тестов: меняете конфиг — хотите знать, что не включили обратно TLS 1.0/1.1 и не раскрыли слабые наборы.
Слабые стороны и нюансы
- Порог входа: чтобы получить максимум, нужно продумать набор проверок и формат хранения результата.
- Не заменяет внешний взгляд: даже при отличных локальных проверках полезно периодически сверяться с внешним тестом, потому что там всплывают поведенческие особенности браузеров и библиотек.
Когда выбирать sslyze
Когда у вас много доменов/серверов, когда вы хотите превратить требования по TLS в проверяемую политику, и когда результат должен удобно «складываться» в отчёты, мониторинг или CI.
Практическое сравнение: что проверять и чем удобнее
На практике редко выбирают «одну утилиту навсегда». Обычно есть базовый инструмент для автоматизации и один «комбайн» для разовых глубоких разборов.
TLS 1.3 и согласование параметров
- sslscan: быстро покажет, доступен ли TLS 1.3 и какие suites объявлены.
- sslyze: удобен, если нужно прогнать много хостов и убедиться, что TLS 1.3 включён везде.
- testssl.sh: полезен, когда нужно понять, почему TLS 1.3 «вроде есть», но клиенты периодически уходят в TLS 1.2.
Cipher suites и «чистота» набора
- sslscan: самый быстрый способ увидеть текущий набор и сравнить с эталоном.
- sslyze: хорош, если вы хотите формализовать требования и валидировать их на регулярной основе.
- testssl.sh: сильнее как аудит, но избыточен, если нужно просто «выпилить лишнее» и зафиксировать регрессию.
OCSP stapling
- testssl.sh: часто удобнее как диагностический инструмент «почему stapling не прикладывается» (или прикладывается нестабильно).
- sslyze: подходит для регулярной проверки наличия stapling на множестве эндпоинтов.
- sslscan: как основной инструмент по stapling обычно менее удобен: сильная сторона sslscan — именно список шифров.
HSTS: где кончается TLS и начинается HTTP
Важный момент: HSTS — это HTTP-заголовок. Поэтому любой TLS-сканер видит его только если умеет делать HTTP-запрос и анализировать ответ. testssl.sh может частично помочь, но для полноценной проверки политики (включая редиректы и коды ошибок) разумно подключать отдельные HTTP-проверки.
Если вы хотите пройтись по практике настройки HTTPS-политик (включая HSTS и типовые ловушки редиректов), держите отдельный материал: как настроить HTTPS и HSTS без неприятных сюрпризов.
Рекомендуемые сценарии использования (чтобы не спорить «что лучше», а закрывать задачу)
Сценарий 1: «быстро после деплоя»
Цель: убедиться, что TLS 1.3 на месте, лишние протоколы не включились, набор cipher suites не изменился неожиданно. Здесь обычно выигрывает sslscan как быстрый smoke-test, а sslyze — как основа для регулярных проверок по списку хостов.
Сценарий 2: «аудит перед публичным запуском и стремление к A+»
Цель: собрать максимум проблем до того, как их найдут снаружи. Здесь логично начать с testssl.sh (как обзор), затем зафиксировать требования и регрессионные проверки через sslyze.
Сценарий 3: «разбор инцидента: у части клиентов не открывается»
Цель: воспроизвести и понять расхождение в согласовании протокола, шифра, SNI и цепочки. В этом сценарии testssl.sh обычно даёт больше подсказок, а sslyze помогает быстро сравнить несколько точек входа (CDN, LB, origin).
Если у вас десятки эндпоинтов (прод, стейдж, внутренние панели, API, почтовые домены), удобнее держать проверки рядом с инфраструктурой и запускать их по расписанию или из CI. На практике это часто живёт на отдельной машине/джобе в виде планировщика. Для таких задач подойдёт VDS: один узел с набором утилит, списками целей и отчётами.
Мини-памятка по интерпретации результатов (частые ловушки)
- «Список cipher suites есть» не значит «так будет у клиента». Разные библиотеки TLS выбирают по-разному; важно смотреть приоритет и контекст (TLS 1.2 vs TLS 1.3).
- TLS 1.3 suites не настраиваются так же, как TLS 1.2. Не переносите логику «один-в-один», особенно если меняете стек (OpenSSL, BoringSSL, NSS) или слой терминации.
- OCSP stapling может быть «включён, но пустой»: конфиг есть, а ответ не прикладывается из-за проблем получения, кэша или таймаутов.
- HSTS проверяйте как HTTP-политику: наличие заголовка на главной странице не гарантирует, что он есть на редиректе или на 4xx/5xx.
Итог: кто выигрывает в 2026 и что выбрать на практике
Если вам нужен один инструмент «на все случаи», чаще всего выбирают testssl.sh за глубину и удобство аудита. Но в реальной эксплуатации обычно эффективнее связка:
- sslscan — быстрый контроль протоколов и cipher suites после изменений;
- sslyze — регулярные проверки и автоматизация на флоте хостов;
- testssl.sh — глубокая диагностика и разовый аудит перед ужесточением политики TLS.
Так вы закрываете и скорость (оперативный smoke-test), и управляемость (policy/CI), и глубину (разбор сложных случаев с TLS 1.3, OCSP stapling и цепочками).
Команды для быстрого старта (шаблоны)
Ниже — минимальные примеры, которые удобно адаптировать под домен и порт. В командах используйте ваш FQDN. Если у вас несколько виртуальных хостов на одном IP, проверяйте именно имя, чтобы корректно отрабатывал SNI.
testssl.sh
testssl.sh example.com
testssl.sh --fast example.com:443
testssl.sh --warnings batch example.com:443sslscan
sslscan example.com:443
sslscan --no-failed example.com:443sslyze
sslyze example.com
sslyze --regular example.com:443Что делать дальше: закрепить TLS как часть рутины
Следующий шаг — формализовать требования: допустимые версии TLS, ожидаемые cipher suites, обязательность OCSP stapling (если он вам нужен), и правила для HSTS. Тогда любой результат сканера становится не «мнением», а проверкой контракта.
Если ваша инфраструктура смешанная (Nginx/Apache, ingress-контроллеры, прокси, почтовые сервисы), полезно закрепить одну «эталонную» политику и проверять её на всех точках терминации. А для внешнего KPI в духе «A+» — периодически сверять расхождения: какие пункты относятся к TLS (их ловят наши инструменты), а какие — к HTTP-политикам и заголовкам (их нужно тестировать отдельно).
