TLS Certificate Checker

Перевірте TLS/SSL сертифікат сайту: суб'єкт/емітент, терміни дії, SANs, повнота ланцюжка та типові помилки конфігурації HTTPS. За бажанням слідуйте редіректам, щоб переконатися, що кінцевий пункт призначення використовує HTTPS з валідним сертифікатом. Експорт звітів у форматі JSON/PDF.

Loading…

Про інструмент Перевірка TLS сертифікатів

Коли HTTPS ламається, користувачі бачать страшні попередження, а боти перестають довіряти вашому сайту. Цей інструмент отримує URL, за бажанням слідує редіректам та інспектує TLS сертифікат, який захищає кінцеву HTTPS точку. Він допомагає виявити сертифікати, що закінчуються, неповні ланцюжки, невідповідності імені хоста/SAN та інші проблеми, які часто викликають помилки в браузерах та проблеми з SEO/доступністю.

Можливості

  • Інспекція суб'єкта та емітента сертифіката (для кого видано, хто видав).
  • Валідація дат: notBefore / notAfter та попередження про близьке закінчення терміну дії.
  • Перевірка SANs (Альтернативних імен суб'єкта) та покриття імені хоста (www vs apex, субдомени).
  • Виявлення проблем ланцюжка сертифікатів (відсутні проміжні ланки / неповний ланцюжок).
  • Додаткова опція слідування редіректам для валідації примусового HTTPS на кінцевому URL.
  • Ідентифікація типових пасток HTTPS (невірний хост, невірний сертифікат, змішані потоки редіректів).
  • Зручні для копіювання результати та висновки для інцидентних заявок.
  • Завантаження звітів JSON та PDF для документації та регресійних перевірок.

🧭 Як використовувати for tls-certificate-checker

1

Вставте URL для тестування

Введіть цільовий URL. Ви можете вставити https://example.com або навіть http://example.com, якщо хочете підтвердити, що він врешті-решт переходить на HTTPS.

2

Увімкніть "Слідувати редіректам" для реальної поведінки

Якщо ви хочете перевірити фактичне місце призначення, до якого потрапляють користувачі та краулери (http→https, non-www→www), залиште опцію "Слідувати редіректам" увімкненою.

3

Запустіть перевірку та перегляньте підсумок

Перевірте ключові пункти: терміни дії, відповідність імені хоста/SAN та чи є ланцюжок повним.

4

Перегляньте висновки та виправте основну причину

Якщо ви бачите попередження (термін дії скоро закінчується, невідповідність, неповний ланцюжок), виправте їх на рівні термінації TLS (CDN, зворотний проксі, балансувальник навантаження або веб-сервер).

5

Експортуйте JSON/PDF для відстеження

Завантажте звіт, щоб додати його до заявок Ops/SEO або зберегти знімок "до/після".

Технічні характеристики

Введення та робота

Цей інструмент перевіряє URL та інспектує TLS сертифікат для вирішеної HTTPS кінцевої точки.

МожливістьДеталі
Підтримувані форми URLURL-адреси HTTP або HTTPS (можна увімкнути переадресацію).
Обробка переадресаційОпціонально; якщо увімкнено, слідує до налаштованої максимальної кількості переадресацій.
Фокус на TLSПеревіряє властивості сертифіката та поширені помилки в налаштуваннях.

Типові значення та обмеження

Типові налаштування отримання та безпеки налаштовані для передбачуваної поведінки.

НалаштуванняЗначення
Слідувати переадресаціямУвімкнено
Макс. переадресацій10
Таймаут15000 мс
User-AgentEncode64Bot/1.0 (+https://encode64.com)
Приватні мережіНе дозволено

Що перевіряється

Перевірки розроблені навколо найпоширеніших проблем у роботі: закінчення терміну дії, невідповідність імені хоста (покриття SAN) та повнота ланцюжка. Слідування переадресаціям допомагає виявити випадки, коли HTTPS дійсний лише на кінцевому канонічному хості.

Дійсний сертифікат є необхідним, але недостатнім для сильної безпеки. Поєднуйте це з аудитами HSTS та заголовків безпеки для захищених розгортань.

Командний рядок

Використовуйте OpenSSL та curl, щоб підтвердити деталі сертифіката зі свого терміналу та порівняти з тим, що повідомляє інструмент.

macOS / Linux

Показати ланцюжок сертифікатів (SNI) для хоста

echo | openssl s_client -servername example.com -connect example.com:443 -showcerts 2>/dev/null

Корисно для перевірки представленого кінцевого сертифіката та проміжного ланцюжка.

Швидко отримати дату закінчення

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

Виводить notBefore / notAfter.

Список SAN

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

Показує, які імена хостів покриває сертифікат.

Перевірити HTTP переадресації на HTTPS

curl -I http://example.com

Перевірити заголовок Location та кінцеву схему.

Слідувати переадресаціям та показати кінцевий URL

curl -IL http://example.com | sed -n '1,120p'

Допомагає виявляти ланцюжки перенаправлень та неканонічні кінцеві точки.

Завжди використовуйте -servername з openssl s_client на серверах з віртуальним хостингом/CDN. Без SNI ви можете отримати неправильний сертифікат.

Сценарії використання

Запобігання простоям через закінчення терміну дії сертифікатів

Визначайте сертифікати, що наближаються до закінчення терміну дії, щоб поновити їх до того, як користувачі та боти зіткнуться з помилками в браузері.

  • Щотижневі перевірки стану сертифікатів
  • Аудит доменів після змін DNS або CDN

Виправлення проблем з неповним ланцюжком сертифікатів

Виявляйте відсутні проміжні сертифікати (поширено в кастомних налаштуваннях серверів), які ламають старі клієнти та деякі краулери.

  • Неправильно налаштований ланцюжок Nginx/Apache
  • Балансувальник навантаження без проміжних сертифікатів

Налагодження невідповідності імені хоста/SAN (www vs apex)

Підтвердьте, що сертифікат покриває точне ім'я хоста, яке використовують користувачі, включаючи www/без www та піддомени.

  • Apex працює, але www ламається
  • API піддомен відсутній у списку SAN

Перевірка примусового HTTPS через перенаправлення

Переконайтеся, що HTTP URL перенаправляють на канонічну HTTPS кінцеву точку з дійсним сертифікатом.

  • http→https з 301
  • канонізація non-www→www

❓ Frequently Asked Questions

Чому браузер може казати "сертифікат не довірений", навіть якщо HTTPS увімкнено?

Поширені причини: закінчився термін дії сертифіката, неповний ланцюжок (відсутній проміжний сертифікат), невідповідність імені хоста (SAN не включає хост) або видача неправильного сертифіката через помилку в налаштуванні SNI/віртуального хостингу.

Що таке SAN і чому вони важливі?

SAN (Subject Alternative Names) — це імена хостів, для яких дійсний сертифікат. Якщо до вашого сайту звертаються через example.com та www.example.com, сертифікат має покривати обидва (або ви маєте послідовно перенаправляти на покритий хост).

Чи це нормально, якщо http перенаправляє на https?

Так — це рекомендується. Просто переконайтеся, що кінцева HTTPS точка надає дійсний сертифікат, а ланцюжок перенаправлень короткий і послідовний (краще 301 для канонічних перенаправлень).

Чи перевіряє цей інструмент версії TLS/шифри?

Цей інструмент зосереджений на перевірці сертифікатів та поширених помилках налаштування. Для посилення протоколу/шифрів (TLS 1.2/1.3, слабкі шифри) використовуйте спеціалізований сканер налаштувань TLS.

Яка різниця між листковим, проміжним та кореневим сертифікатами?

Листковий сертифікат — це сертифікат вашого сайту. Проміжні сертифікати з'єднують його з довіреним кореневим CA. Браузери довіряють кореневим сертифікатам, тому відсутність проміжних може завадити побудові дійсного ланцюжка довіри.

Pro Tips

Best Practice

Оновлюйте сертифікати заздалегідь та автоматизуйте поновлення (ACME) де це можливо.

Best Practice

Переконайтеся, що SAN охоплюють кожне публічне ім'я хоста, яке ви обслуговуєте (www, apex, API субдомени), або забезпечте єдиний канонічний хост через перенаправлення.

Best Practice

Завжди подавайте повний ланцюжок (листок + проміжні). Багато збоїв виникають через неповні зв'язки ланцюжків після міграцій.

Best Practice

Якщо ви вмикаєте перенаправлення, зберігайте їх мінімальними: один перехід на канонічну https URL-адресу є ідеальним.

Best Practice

Поєднуйте дійсний TLS з HSTS та заголовками безпеки для сильнішого захисту в реальних умовах.

Additional Resources

Other Tools