Проверка SSL-сертификата: сравнение лучших онлайн-сервисов

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

В 2026 году проверка SSL-сертификата — это уже не вопрос «действителен ли сертификат». Онлайн-сервисы анализируют цепочку доверия, протоколы, шифры, алгоритм подписи, настройки веб-сервера, заголовки безопасности и даже признаки готовности TLS-стека к постквантовой криптографии. Один инструмент показывает проблему за пять секунд, другой раскладывает конфигурацию на десятки параметров, третий смотрит на сервер глазами атакующего аудитора.

Мы с вами живём в момент, когда HTTPS перестал быть финальной галочкой в настройках домена. Это живой слой инфраструктуры — и его приходится тестировать так же регулярно, как резервные копии, контейнеры и правила WAF.

Эволюция критериев: почему HTTPS уже недостаточно

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

Поэтому современный тест SSL-сертификата отвечает сразу на несколько разных вопросов:

• действительно ли сертификат выдан нужному домену и не истёк;
• отправляет ли сервер полную цепочку доверия вместе с промежуточными сертификатами;
• поддерживаются ли современные версии TLS;
• отключены ли устаревшие протоколы и небезопасные шифры;
• корректно ли работает перенаправление с HTTP на HTTPS;
• включён ли HSTS и не содержит ли он конфликтующих параметров;
• совпадает ли конфигурация IPv4 и IPv6;
• не отличается ли поведение основного домена от поддоменов;
• не маскируется ли проблема CDN или балансировщиком.

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

В 2025 году критерии Qualys SSL Labs стали заметно жёстче. Отсутствие TLS 1.3 теперь ограничивает максимальную оценку уровнем A-. Некорректный или отключённый HSTS приводит к тому же потолку. А если сервер всё ещё разрешает TLS 1.0 или TLS 1.1, итоговая оценка может быть ограничена уровнем B.

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

HTTPS — это дверь с замком. SSL Labs проверяет не только замок, но и качество двери, стены, сигнализацию и то, не оставили ли вы запасной вход открытым.

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

Qualys SSL Labs: эталонный рентген веб-сервера

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

Отчёт полезен именно тем, что заставляет мыслить не в стиле «замочек есть — всё хорошо», а в стиле «какие клиенты подключатся, какие алгоритмы им предложат и какой путь доверия они построят».

В 2026 году для высоких оценок особенно значимы три слоя:

1. TLS 1.3. Его отсутствие ограничивает максимальный результат уровнем A-. По глобальной статистике Qualys SSL Pulse, в июне 2025 года TLS 1.3 поддерживали 75,3% топ-150 000 сайтов из списка Tranco. Это уже не эксперимент для технологических гигантов, а массовая норма, к которой постепенно подтягивается инфраструктура.

2. HSTS. Заголовок Strict-Transport-Security сообщает браузеру, что домен нужно открывать только по HTTPS. Но произвольное добавление заголовка не превращает сайт в защищённый космолёт: срок действия, область применения и параметры поддоменов должны соответствовать реальной архитектуре проекта. Невалидный HSTS или его отсутствие снижает потолок оценки до A-.

3. Удаление устаревших протоколов. TLS 1.0 и TLS 1.1 официально признаны устаревшими ещё в 2021 году, а современные браузеры их блокируют. Сохранение этих протоколов ради гипотетической совместимости с древним клиентом может стоить серверу оценки B — и создавать дополнительную поверхность атаки.

У SSL Labs есть и обратная сторона: отчёт очень подробный. Для владельца небольшого сайта первые минуты могут напоминать чтение приборной панели космического корабля без подготовки. Но именно здесь инструмент превращается в учебник — особенно если вы администрируете Nginx, Apache, балансировщик или CDN и хотите понять, какой параметр реально изменил результат.

Что смотреть в отчёте SSL Labs

Не нужно бросаться на первую красную строку. Двигайтесь по слоям:

• Сертификат: доменные имена, срок действия, алгоритм подписи, издатель.
• Цепочка: присутствуют ли промежуточные сертификаты, не отправляется ли лишний или устаревший элемент.
• Протоколы: включены ли TLS 1.2 и TLS 1.3, отключены ли TLS 1.0 и TLS 1.1.
• Обмен ключами и шифры: не поддерживаются ли слабые или устаревшие наборы.
• HSTS: присутствует ли заголовок и корректно ли сервер выдаёт его на HTTPS-ответах.
• Совместимость: как ведут себя разные версии клиентов, включая IPv6-точки входа.
• Уязвимости: нет ли известных проблем, связанных с конкретными режимами и настройками.

После изменения конфигурации не стоит считать задачу закрытой по одному удачному запуску. Кэширование на CDN, разные upstream-серверы и несколько балансировщиков способны выдавать неодинаковые ответы. Иногда один узел уже обновлён, а второй продолжает отправлять старую цепочку или разрешать нежелательный протокол.

SSL Shopper, DigiCert и быстрый диагноз без тяжёлой артиллерии

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

SSL Shopper: цепочка за несколько секунд

SSL Shopper SSL Checker — это быстрый диагностический инструмент. Базовая проверка занимает примерно 5–10 секунд и наглядно показывает структуру цепочки: серверный сертификат, промежуточный сертификат и корневой центр сертификации.

Его сильная сторона — не масштаб анализа, а скорость и визуальная ясность. Если после переезда сайта на новый хостинг часть пользователей видит ошибку доверия, первым делом можно проверить, не забыли ли вы передать intermediate certificate. Особенно часто это случается, когда администратор указывает в настройке веб-сервера только файл сертификата домена, хотя серверу требуется полный bundle.

SSL Shopper хорош в роли «дымового датчика»:

• быстро показывает, отвечает ли домен по HTTPS;
• помогает увидеть разрыв в цепочке;
• подходит для первичной проверки после выпуска или замены сертификата;
• экономит время, когда пока не требуется полный аудит TLS-политики.

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

DigiCert SSL Certificate Checker: технический паспорт соединения

Инструмент DigiCert даёт другой ракурс. Он определяет IP-адрес сервера, тип веб-сервера, поддерживаемые шифры, алгоритм подписи и предупреждает о приближении срока действия сертификата.

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

DigiCert стоит использовать:

• перед переносом домена между провайдерами;
• после смены веб-сервера или reverse proxy;
• при расследовании неожиданных различий между регионами;
• в рамках контроля срока действия;
• для первичного понимания поддерживаемых шифров и алгоритмов.

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

ImmuniWeb и Wormly: когда простого «сертификат действителен» мало

Если сайт связан с платежами, личными кабинетами, API или корпоративными данными, одного теста цепочки недостаточно. Здесь нужны инструменты, которые смотрят на TLS как на часть общей модели безопасности.

ImmuniWeb SSL Security Test в сентябре 2025 года запустил бесплатную проверку готовности TLS-стеков к постквантовому шифрованию в соответствии со стандартами NIST. Это не означает, что завтра обычный сайт взломают квантовым компьютером. Но направление уже стало инженерной реальностью: инфраструктура, которая сегодня строится без учёта миграции криптографии, завтра может оказаться в неудобной точке — особенно если сертификаты, библиотеки, прокси и внутренние сервисы обновляются медленно.

По данным ImmuniWeb, во втором квартале 2025 года только 10,63% протестированных систем соответствовали требованиям, связанным с такой готовностью. Цифра впечатляет именно контрастом: разговоры о постквантовой криптографии уже звучат на конференциях, но большая часть публичных систем ещё не приблизилась к соответствующим стандартам.

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

Wormly SSL Tester, в свою очередь, проверяет более 65 метрик безопасности. Такой подход полезен, когда вы хотите получить широкую панораму и увидеть параметры, которые не попали в короткий отчёт. Но точные алгоритмы и веса итоговой оценки сторонних сервисов раскрыты не так подробно, как у Qualys SSL Labs. Поэтому букву или балл Wormly не стоит механически сравнивать с оценкой SSL Labs: разные инструменты могут по-разному расставлять приоритеты.

Это принципиальная вещь. Сравнение сервисов — не конкурс, где нужно выбрать один «самый правильный» сканер. Их результаты отвечают на разные вопросы.

Один сервис показывает, работает ли цепочка доверия. Другой — насколько современна TLS-политика. Третий пытается заглянуть в криптографическое будущее. Вместе они дают объёмную картину, по отдельности — только её грань.

Проверка цепочки SSL-сертификатов: где чаще всего ломается доверие

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

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

Так появляются странные симптомы:

• в Chrome на рабочем компьютере всё выглядит нормально;
• старое мобильное устройство сообщает о недоверенном сертификате;
• API-клиент на сервере партнёра не может установить соединение;
• корпоративный прокси показывает ошибку, хотя публичный браузер молчит;
• после обновления сертификата проблема возникает только у пользователей из определённой сети.

Для диагностики цепочки полезно проверять не только основной домен, но и все публичные точки входа:

1. example.ru и www.example.ru, если они обслуживаются разными virtual host.

2. Поддомены API, панели администратора и CDN.

3. IPv4 и IPv6 — при наличии AAAA-записи.

4. Основной endpoint и резервный сервер.

5. Внешний адрес балансировщика и origin, если origin доступен напрямую.

6. Домены, которые используются мобильными приложениями или интеграциями.

Сертификат может быть корректным на одном hostname и отсутствовать на другом. А wildcard-сертификат покрывает не любую глубину поддоменов: сертификат для *.example.ru не равен разрешению на api.dev.example.ru. Это уже не вопрос рейтинга, а вопрос соответствия имён, которое клиент проверяет при TLS-соединении.

Ещё один слой — срок действия. Автоматическая выдача и продление сертификатов сильно снизили количество ручной работы, но не убрали операционные сбои. Не обновился DNS, не перезапустился reverse proxy, не перезагрузился один узел кластера — и публичный сервер продолжает отдавать старый сертификат. Поэтому контроль срока действия должен смотреть на внешний ответ домена, а не только на статус задачи в панели хостинга.

Что тянет оценку вниз до B — и почему это не косметика

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

TLS 1.0 и TLS 1.1 признаны устаревшими стандартом IETF RFC 8996, а основные браузеры их заблокировали. Если они всё ещё включены, серверная политика допускает переговоры на условиях, которые современная веб-инфраструктура старается исключать. Qualys SSL Labs ограничивает максимальную оценку такого сервера уровнем B.

Обычно причина не в сознательном желании использовать старый протокол. Она прячется в наследии:

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

Работа с такой проблемой начинается не с охоты за буквой A+, а с инвентаризации клиентов. Если действительно существует легаси-система, которой нужен старый TLS, её лучше изолировать на отдельном endpoint с понятным контролем доступа, а не оставлять старые протоколы включёнными для всего публичного домена.

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

Похожая история с HSTS. Заголовок способен принудительно переводить браузер на HTTPS, однако ошибка в его параметрах может сделать недоступными поддомены, которые ещё не готовы к TLS. Поэтому HSTS нужно вводить поэтапно: сначала убедиться, что все нужные hostname действительно обслуживаются по HTTPS, затем выбрать подходящий срок действия и только после этого расширять область применения.

TLS 1.3 и постквантовый горизонт

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

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

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

Практичный подход здесь выглядит так:

• собрать перечень всех публичных и внутренних TLS-endpoint;
• зафиксировать версии библиотек и терминационных прокси;
• отделить сертификаты для веб-сайтов от сертификатов API и внутренних сервисов;
• определить, где TLS завершается — на CDN, балансировщике, ingress или самом приложении;
• включить регулярное сканирование и сравнение результатов;
• заранее проверить, как инфраструктура будет принимать новые криптографические алгоритмы.

Это не повод срочно переписывать весь стек. Это повод перестать считать сертификат статичным файлом, который однажды загрузили на сервер и забыли.

Какой сервис выбрать для конкретной задачи

Выбор зависит от того, какую проблему вы пытаетесь решить, а не от громкости названия инструмента.

Для быстрой проверки после выпуска сертификата подойдёт SSL Shopper: он быстро показывает цепочку и помогает поймать самый распространённый дефект — отсутствие промежуточного сертификата.

Для анализа серверной политики выбирайте Qualys SSL Labs. Он лучше всего подходит, когда нужно понять, почему нет A+, какие протоколы разрешены, как сервер ведёт себя с разными клиентами и какую роль сыграли TLS 1.3 и HSTS.

Для проверки инфраструктурного контекста полезен DigiCert: IP-адрес, тип сервера, шифры и срок действия дают быстрый ответ на вопрос, что именно сейчас торчит в интернет.

Для расширенного аудита и оценки будущих криптографических рисков можно подключить ImmuniWeb. Если нужно большое количество метрик в одном отчёте, пригодится Wormly, но его баллы лучше воспринимать как отдельную систему координат.

Оптимальная связка после изменения TLS-конфигурации может выглядеть так:

1. Быстро проверить домен и цепочку через SSL Shopper.

2. Запустить глубокий аудит в Qualys SSL Labs.

3. Сверить IP, тип сервера и срок действия через DigiCert.

4. Проверить дополнительные endpoint и поддомены.

5. Для критичных систем провести расширенный аудит ImmuniWeb или Wormly.

6. Сохранить результаты и сравнить их после следующего деплоя.

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

Финал: проверяйте не сертификат, а весь TLS-слой

Хорошая проверка SSL-сертификата начинается с простого вопроса «действителен ли он?», но заканчивается гораздо шире: «как именно мой сервер устанавливает доверенное соединение для разных клиентов и разных точек входа?»

В 2026 году минимальная здоровая конфигурация — это не просто HTTPS. Это TLS 1.2 и TLS 1.3 вместо устаревших протоколов, корректная цепочка, осмысленный HSTS, актуальные библиотеки, контроль срока действия и понимание того, где именно завершается шифрование. SSL Labs задаёт строгую планку, быстрые checker-сервисы ловят очевидные сбои, а инструменты вроде ImmuniWeb помогают смотреть дальше сегодняшнего отчёта — в сторону криптографической миграции.

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