SSL Checker
Перевіряє ланцюг сертифікатів, термін і алгоритм.
- Certificate is valid for this host and not expired.
- *.badssl.com
- badssl.com
Що означає кожне поле?
Опис полів
Subject (кому видано)
Поле Subject ідентифікує власника сертифіката. Сучасні сертифікати спираються на CN (Common Name) + Subject Alternative Names. Organization (O), Organizational Unit (OU), Locality (L) — присутні у EV/OV-сертифікатах; у DV (Let's Encrypt тощо) їх немає.
Issuer (хто видав)
Ідентифікує CA, що поручився за суб'єкта. У браузерах вшита довірена root-store; сертифікат від нелояльного видавця (або self-signed) дає NET::ERR_CERT_AUTHORITY_INVALID. Поширені публічні CA: Let's Encrypt, DigiCert, Sectigo, GlobalSign, GoDaddy.
Subject Alt Names (SAN)
Один сертифікат може покривати кілька хостів через розширення SAN — типово wildcard (<code>*.example.com</code>) або multi-domain (SAN). З 2017-го браузери ігнорують Common Name і збігають лише SAN. Якщо вашого хоста в списку немає — сертифікат для нього недійсний.
Глибина ланцюжка
Ланцюг довіри: leaf-сертифікат сервера → один або кілька проміжних CA → root CA з браузерного trust-store. Звичайна глибина — 2 (leaf + 1 intermediate). Якщо сервер забув віддати проміжні — клієнт побачить "incomplete chain".
Алгоритм підпису
Описує, як CA підписав сертифікат. <code>sha256WithRSAEncryption</code> (RSA + SHA-256) — стандарт за замовчуванням. <code>ecdsa-with-SHA256</code> — еліптичні криві, коротші ключі, та сама криптостійкість. <code>sha1WithRSAEncryption</code> зламано з 2017 року — браузери відхиляють.
Публічний ключ
Публічна половина криптопари. RSA 2048 бітів — практичний мінімум; 3072+ для довгограючих ключів. EC P-256 коротший (~256-бітна еквівалентна стійкість) та швидший. Усе нижче за RSA 2048 чи старіше за P-256 треба замінити.
Узгоджений шифр
Описує шифрування фактичних даних: key exchange (ECDHE), шифр (AES_256_GCM, CHACHA20_POLY1305), MAC (SHA384). Forward-secret suites (ECDHE-*) — вимога більшості стандартів безпеки. CBC і RC4 — застаріле.
Збіг імені хоста
Навіть валідний сертифікат відхиляється, якщо запитуваного хосту немає у SAN. Wildcards покривають точно один DNS-label: <code>*.example.com</code> покриває <code>www.example.com</code>, але НЕ <code>a.b.example.com</code> чи <code>example.com</code>.
Self-signed
У self-signed Subject = Issuer. Браузери йому не довіряють — буде "NET::ERR_CERT_AUTHORITY_INVALID". Прийнятно для внутрішніх/staging-середовищ, де ви контролюєте і сервер, і клієнт. Для production — Let's Encrypt (безкоштовно) або публічний CA.
Чинний до (expiry)
Браузери відхиляють прострочені сертифікати беззастережно. Сертифікати публічних CA живуть 90–397 днів. Налаштовуйте автоматичне продовження: ACME / Let's Encrypt — за 60 днів до expiry; комерційні CA — за 30. Очікуйте поступовий перехід на обов'язкові 90 днів до 2027 року.
Повністю валідний
Усі базові перевірки пройдені: ланцюг довіри замикається на browser-trusted root, хост у SAN збігається, сертифікат у межах validity window, алгоритм підпису сучасний. Саме цей стан браузер показує зеленим замком.
Про цей інструмент
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» — хто має рацію?
AIA-extension або зі своїх кешів — користувач бачить робочий замочок. Але iOS Safari, багато Android-аплікацій, curl, OpenSSL-клієнти і non-browser TLS-бібліотеки цього не роблять. Якщо наш інструмент каже «incomplete», ваш сайт буде падати на нетривіальній частці клієнтів; фікс — віддавати повний ланцюг з сервера.