KernelHost Tools SSL Checker

Проверка SSL-сертификата

Введите домен (или host:port) и сразу увидите: кто выдал сертификат, когда он истекает, покрывает ли он ваш hostname и как устроена цепочка. Узел во Франкфурте, бесплатно, без регистрации.

Проверить домен
Быстрый тест: kernelhost.com cloudflare.com github.com:443 expired.badssl.com

Что проверяет этот тест?

KernelHost SSL Checker берёт сертификат сервера через TLS-handshake из нашего узла во Франкфурте и показывает важнейшие поля без обращения к сторонним сервисам. Что именно проверяется и отображается:

  • Кому и кем выдан: Common Name (Subject CN), полный Subject DN и Issuer (какая CA подписала сертификат).
  • Период действия: Дата начала и конца в UTC плюс оставшиеся дни. Цветовая индикация: зелёный (>30 дней), оранжевый (7 до 30 дней), красный (менее 7 дней или уже истёк).
  • Subject Alternative Names (SANs): Полный список hostname, которые покрывает сертификат, включая wildcard-записи.
  • Совпадение hostname: Проверка того, что введённый домен действительно покрыт Common Name или SAN-wildcard (RFC 6125).
  • Ключ и подпись: Алгоритм public key (RSA, ECDSA), размер ключа в битах либо имя кривой, и алгоритм подписи.
  • Fingerprint и серийный номер: Fingerprint SHA-256 и SHA-1 от DER-кодированного сертификата плюс шестнадцатеричный серийный номер.
  • Полная цепочка: Все сертификаты, которые сервер передал во время handshake, с subject, issuer и ролью (leaf, intermediate, root).

Частые ошибки SSL и что они означают

Браузеры часто показывают загадочные ошибки вроде NET::ERR_CERT_DATE_INVALID или SSL_ERROR_BAD_CERT_DOMAIN. Самые частые причины и как их исправить:

  • Сертификат истёк: Дата notAfter в прошлом. Браузеры полностью блокируют страницу. Решение: обновить сертификат, у Let's Encrypt автоматически каждые 60 дней через certbot или acme.sh.
  • Hostname не совпадает: Введённый hostname отсутствует и в Common Name, и в SANs. Решение: при перевыпуске добавить все нужные домены и поддомены как SAN.
  • Self-signed или неизвестная CA: Issuer не является доверенной root-CA. Браузеры показывают NET::ERR_CERT_AUTHORITY_INVALID. Решение: получить сертификат у признанной CA вроде Let's Encrypt, ZeroSSL, Sectigo или DigiCert.
  • Неполная цепочка: Сервер отдаёт только leaf-сертификат, без intermediates. Мобильные браузеры и старые устройства падают. Решение: настроить full chain (fullchain.pem) в веб-сервере.
  • Слабый ключ или слабая подпись: RSA менее 2048 бит или подписи SHA-1 больше не принимаются. Решение: перевыпустить с RSA 2048+ или ECDSA P-256.
  • Mixed Content и ловушка HSTS: Если ранее был установлен валидный заголовок HSTS, а сертификат потом истёк, посетители не смогут пройти через предупреждение. Срочная мера: обновить сертификат, в крайнем случае уменьшить HSTS max-age.

Let's Encrypt против коммерческих сертификатов

Let's Encrypt, это бесплатная автоматизированная CA, управляемая ISRG. Сертификаты технически идентичны коммерческим DV-сертификатам и принимаются как доверенные всеми современными браузерами.

Когда платный сертификат имеет смысл? На самом деле только в особых случаях:

  • Extended Validation (EV): Раньше отображался зелёной адресной строкой, сегодня визуально почти не отличим. Имеет смысл только для банков или биржевых платформ при законодательных требованиях.
  • Wildcard без DNS-challenge: Let's Encrypt поддерживает wildcard только через DNS-01 challenge. Если нет API-доступа к DNS, ZeroSSL Premium или Sectigo, это альтернатива.
  • Гарантия и страховка: Коммерческие CA предлагают страховые суммы при mis-issuance. На практике редко актуально, но некоторые compliance-фреймворки этого требуют.

В KernelHost Webhosting и cPanel интеграция с Let's Encrypt бесплатно включена и автоматизирована. Сертификаты обновляются через AutoSSL каждые 60 дней без вашего участия. Wildcard-сертификаты через DNS-challenge также возможны, как только домен размещён на KernelHost DNS.

TLS 1.2 против TLS 1.3

TLS 1.2 является стандартом с 2008 года, TLS 1.3 был опубликован как RFC 8446 в 2018 году и широко применяется с 2020 года. Старые версии (SSL 3.0, TLS 1.0, TLS 1.1) небезопасны и должны быть отключены в конфигурации сервера.

Что TLS 1.3 делает лучше:

  • Более быстрый handshake: 1-RTT вместо 2-RTT, плюс опциональный 0-RTT при возобновлении. Заметно быстрее на TLS-тяжёлых страницах.
  • Чистый набор cipher: Всего 5 разрешённых AEAD-cipher suites. Никакого RSA-key-exchange, всегда forward secrecy.
  • Зашифрованный handshake: Сертификат сервера сам передаётся в зашифрованном виде. С ESNI/ECH даже SNI остаётся приватным.
  • Обратно совместимый: Серверы могут предлагать TLS 1.2 и 1.3 параллельно. Браузеры автоматически согласуют наивысшую общую версию.

Что означает истёкший сертификат?

Истёкший SSL-сертификат означает конкретно: браузеры показывают полноэкранное предупреждение и блокируют сайт. Посетители в большинстве случаев не могут пройти дальше, особенно при активном заголовке HSTS.

Последствия для оператора:

  • Потеря ранжирования в Google (HTTPS, это фактор ранжирования, и сигналы доверия учитываются).
  • Mail-серверы (MX/SMTP с STARTTLS) отказываются принимать входящие подключения, письма bouncятся или доставляются с задержкой.
  • API-клиенты и мобильные приложения с certificate pinning ломаются и могут потребовать обновления.

HSTS, CAA и OCSP-stapling

Валидный сертификат, это только начало. Три дополнительных механизма поднимают TLS-безопасность до уровня best practice:

  • HSTS (HTTP Strict Transport Security): Заголовок, заставляющий браузеры использовать только HTTPS. Рекомендация: max-age=63072000; includeSubDomains; preload (два года, все поддомены, preload-список). Будьте осторожны при включении: ошибка не откатывается, пока не истечёт max-age.
  • CAA (Certification Authority Authorization): DNS-запись, определяющая, какие CA могут выпускать сертификаты для вашего домена. Пример: 'kernelhost.com. CAA 0 issue "letsencrypt.org"' предотвращает mis-issuing другими CA.
  • OCSP-stapling: Веб-сервер сам отдаёт ответ о статусе отзыва от CA, вместо того чтобы каждый браузер обращался к CA отдельно. Быстрее для посетителей и щадит инфраструктуру CA. В Apache: SSLUseStapling On, в nginx: ssl_stapling on.

Конфиденциальность

KernelHost SSL Checker работает целиком в нашем узле во Франкфурте без обращений к сторонним сервисам:

  • Никакой передачи ввода во внешние API (никакого SSL Labs, Hardenize, Cryptomon).
  • Никакого сохранения проверенного домена сверх стандартного логирования запросов (стандартный лог веб-сервера, хранение 14 дней).
  • Anti-SSRF фильтр блокирует запросы к приватным диапазонам IP, loopback и link-local.
  • Rate-limit по IP против злоупотреблений. Опционально hCaptcha при отправке.

FAQ по SSL-сертификатам

Поддерживаете ли вы нестандартные порты?

Да. Введите как host:port, например mail.example.com:993 для IMAPS или vpn.example.com:8443. Порт по умолчанию 443.

Почему тест показывает истёкший сертификат, хотя браузер не предупреждает?

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

Почему тест проваливается на моём внутреннем домене?

Checker работает во Франкфурте и может проверять только публично доступные хосты. Приватные IP (10.x, 192.168.x, 172.16-31.x), loopback и link-local намеренно блокируются (защита от SSRF).

Как часто стоит проверять?

При автоматическом обновлении (Let's Encrypt + cronjob) достаточно одной проверки после настройки плюс мониторинга через uptime-инструмент. Без автоматизации, минимум каждые 30 дней вручную.

Можно ли проверять поддомены и mail-серверы?

Да, любой hostname поддерживается. Для mail-серверов: smtp.example.com:25 или imap.example.com:993. Тест выполняет чистый TLS-handshake с правильным SNI.

Что значит уведомление 'self-signed certificate'?

Сервер сам подписал собственный сертификат вместо использования доверенной CA. Браузеры это не принимают, если только пользователь вручную не добавит сертификат в trust store. В production всегда используйте настоящую CA.

Какие размеры ключей рекомендует KernelHost?

RSA 2048 бит как минимум, RSA 3072 или 4096 бит для долгоживущих сертификатов или ECDSA P-256, когда важна производительность (значительно меньшие подписи, более быстрый handshake). RSA 1024 и меньше уже годами запрещены и отвергаются браузерами.

В чём разница между DV, OV и EV?

DV (Domain Validation) подтверждает только то, что заявитель контролирует домен (стандарт у Let's Encrypt). OV (Organization Validation) дополнительно проверяет компанию (выписка из реестра). EV (Extended Validation), это самая строгая проверка с подтверждением физического адреса. С 2019 года браузеры визуально не отличают эти типы, поэтому в 99% случаев достаточно DV.

Все продукты KernelHost

Нужно больше, чем просто инструменты? Посмотрите наш ассортимент коммерческого хостинга.