Security

SSL Checker

Перевіряє ланцюг сертифікатів, термін і алгоритм.

Про цей інструмент

SSL Checker відкриває справжнє TLS-з'єднання до вашого хоста, захоплює ланцюг сертифікатів, який сервер пред'являє, і повідомляє все важливе: subject, issuer, дати чинності, повний intermediate-ланцюг до trust-anchor, signature algorithm, розмір публічного ключа, підтримувані TLS-версії та cipher suites, Subject Alternative Names і статус OCSP stapling. Перевірка йде server-side з нашого франкфуртського хоста, тож ви бачите саме те, що бачить віддалений відвідувач — а не те, що закешував ваш браузер.

Чистий сертифікат — це не просто «зелений замочок». Ми валідуємо відповідність hostname проти SANs (legacy-поле CN — лише інформативне, згідно з RFC 6125), перевіряємо, що кожна ланка ланцюга підписана наступною, що intermediates показані в правильному порядку (часта помилка деплою), що leaf не прострочений і ще чинний, і попереджаємо, якщо leaf використовує слабкий підпис (SHA-1) або недостатній ключ (RSA < 2048 біт). Все це в одному HTTPS-handshake.

Коли використовувати цей інструмент

  • Перевірка перед деплоєм. Після провіжина Let's Encrypt або купівлі комерційного серта переконайтесь, що ланцюг повний, перш ніж направити на нього реальних користувачів.
  • Моніторинг прострочки. Виявляйте серти, що спливуть найближчі 7/14/30 днів, і поновлюйте до того, як спрацюють алярми.
  • Дебаг mixed-content. Знайдіть субдомени, які пред'являють інший (або self-signed) серт, ніж основний сайт.
  • Sanity-перевірки міграції. Після переїзду на новий CDN або балансер переконайтесь, що новий серт і ланцюг — саме ті, які ви очікуєте.

Що насправді означає «chain incomplete»

Браузери та OS trust stores містять кілька сотень root CA. Ваш leaf-сертифікат підписаний intermediate, який підписаний наступним intermediate або напряму root. Web-сервер мусить надсилати leaf + усі intermediates до (але не включно з) root — Firefox і Chrome спробують дотягнути відсутні intermediates через AIA-extension, але iOS, старий Android і більшість non-browser TLS-клієнтів відхилять handshake. Наш chain-інспектор каже точно, якої ланки бракує, щоб ви вставили правильний intermediate у конфіг сервера.

Часті запитання

Браузер показує замочок, а ваш інструмент каже «chain incomplete» — хто має рацію?

Обидва. Сучасні desktop-браузери латають неповні ланцюги, підтягуючи intermediates через AIA-extension або зі своїх кешів — користувач бачить робочий замочок. Але iOS Safari, багато Android-аплікацій, curl, OpenSSL-клієнти і non-browser TLS-бібліотеки цього не роблять. Якщо наш інструмент каже «incomplete», ваш сайт буде падати на нетривіальній частці клієнтів; фікс — віддавати повний ланцюг з сервера.

Що таке OCSP stapling?

Спосіб для сервера прикріпити нещодавнє CA-підписане підтвердження чинності серта під час TLS-handshake — щоб браузер не мусив дзвонити в OCSP-responder CA на кожному коннекті. Stapling прискорює завантаження сторінок і захищає приватність користувача (CA ніколи не дізнається, які сайти користувач відвідує). Більшість сучасних web-серверів (nginx, Apache 2.4, Caddy) це підтримують; багато вмикають за замовчуванням.

Як часто перевіряти?

Раз на тиждень — достатньо для продакшну. Let's Encrypt-серти поновлюються кожні 60–90 днів, комерційні — щороку; так чи інакше непомічений expiry — найпоширеніший SSL-фейл. Ми кешуємо результати на 10 хвилин, тож швидка повторна перевірка після деплою дає миттєвий зворотний зв'язок. Парте з автоматизованим монітором (Uptime Kuma, StatusCake) для проактивних алертів.

Чому інструмент не валідує проти мого приватного CA?

Ми використовуємо стандартний публічний CA trust bundle (Mozilla's, який також використовує більшість ОС). Приватні CA — внутрішні корпоративні root, ACME-CA в homelab — не в жодному публічному trust store, тож валідація ланцюга (правильно) маркуватиме їх як untrusted. Деталі сертифіката (subject, дати, розмір ключа) усе одно повідомляються; лише перевірка trust-anchor падає.