TLS Certificate Checker

Sprawdź certyfikat TLS/SSL strony: podmiot/wystawiający, daty ważności, SAN, kompletność łańcucha i typowe błędne konfiguracje HTTPS. Opcjonalnie podążaj za przekierowaniami, aby zweryfikować, czy ostateczny cel to HTTPS z ważnym certyfikatem. Eksportuj raporty JSON/PDF.

Loading…

O nas Sprawdzarka certyfikatów TLS

Gdy HTTPS się psuje, użytkownicy widzą przerażające ostrzeżenia, a boty przestają ufać Twojej stronie. To narzędzie pobiera adres URL, opcjonalnie podąża za przekierowaniami i sprawdza certyfikat TLS chroniący końcowy punkt HTTPS. Pomaga wykryć wygasające certyfikaty, niekompletne łańcuchy, niezgodności nazwy hosta/SAN i inne problemy, które często powodują błędy w przeglądarce oraz problemy z SEO i dostępnością.

Funkcje

  • Sprawdź podmiot i wystawcę certyfikatu (dla kogo jest, kto go wystawił).
  • Sprawdź daty: notBefore / notAfter i ostrzegaj o zbliżającym się wygaśnięciu.
  • Sprawdź SAN (Subject Alternative Names) i pokrycie nazwy hosta (www vs apex, subdomeny).
  • Wykryj problemy z łańcuchem certyfikatów (brak certyfikatów pośrednich / niekompletny łańcuch).
  • Opcjonalne podążanie za przekierowaniami, aby zweryfikować wymuszenie HTTPS dla końcowego adresu URL.
  • Zidentyfikuj typowe pułapki HTTPS (zła nazwa hosta, zły certyfikat, mieszane przepływy przekierowań).
  • Wyniki i ustalenia przyjazne do kopiowania dla zgłoszeń incydentów.
  • Pobierz raporty JSON i PDF do dokumentacji i testów regresji.

🧭 Jak używać for tls-certificate-checker

1

Wklej adres URL do przetestowania

Wprowadź docelowy adres URL. Możesz wkleić https://example.com lub nawet http://example.com, jeśli chcesz potwierdzić, że ostatecznie przechodzi na HTTPS.

2

Włącz "Podążaj za przekierowaniami" dla realistycznego zachowania

Jeśli chcesz zweryfikować rzeczywisty cel, do którego docierają użytkownicy i crawlerzy (http→https, non-www→www), pozostaw włączone Podążaj za przekierowaniami.

3

Uruchom sprawdzenie i przejrzyj podsumowanie

Sprawdź kluczowe elementy: daty ważności, zgodność nazwy hosta/SAN oraz czy łańcuch jest kompletny.

4

Przeanalizuj ustalenia i napraw przyczynę

Jeśli widzisz ostrzeżenia (wkrótce wygaśnie, niezgodność, niekompletny łańcuch), napraw je na warstwie kończenia TLS (CDN, reverse proxy, load balancer lub serwer WWW).

5

Eksportuj JSON/PDF do śledzenia

Pobierz raport, aby dołączyć go do zgłoszeń ops/SEO lub zachować migawkę przed/po.

Specyfikacje techniczne

Dane wejściowe i działanie

To narzędzie sprawdza adres URL i analizuje certyfikat TLS dla rozwiązanej końcówki HTTPS.

MożliwościSzczegóły
Obsługiwane formy adresów URLAdresy URL HTTP lub HTTPS (można włączyć przekierowania).
Obsługa przekierowańOpcjonalna; po włączeniu, podąża za przekierowaniami do skonfigurowanej maksymalnej liczby.
Skupienie na TLSSprawdza właściwości certyfikatu i typowe błędne konfiguracje.

Domyślne ustawienia i limity

Domyślne ustawienia pobierania i bezpieczeństwa są dostrojone dla przewidywalnego działania.

UstawienieWartość
Podążaj za przekierowaniamiWłączone
Maks. przekierowań10
Limit czasu15000 ms
User-AgentEncode64Bot/1.0 (+https://encode64.com)
Sieci prywatneNiedozwolone

Co jest sprawdzane

Kontrole są zaprojektowane wokół najczęstszych awarii obserwowanych w środowisku produkcyjnym: wygaśnięcie, niezgodność nazwy hosta (pokrycie SAN) i kompletność łańcucha. Podążanie za przekierowaniami pomaga wychwycić przypadki, gdy HTTPS jest ważny tylko na końcowym, kanonicznym hoście.

Ważny certyfikat jest konieczny, ale niewystarczający dla silnego bezpieczeństwa. Połącz to z audytami HSTS i nagłówków bezpieczeństwa dla wzmocnionych wdrożeń.

Wiersz poleceń

Użyj OpenSSL i curl, aby potwierdzić szczegóły certyfikatu z własnego terminala i porównać z tym, co zgłasza narzędzie.

macOS / Linux

Pokaż łańcuch certyfikatów (SNI) dla hosta

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

Przydatne do sprawdzenia przedstawionego certyfikatu liścia i łańcucha pośredniego.

Szybko wyodrębnij datę wygaśnięcia

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

Wypisuje notBefore / notAfter.

Wyświetl SANy

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

Pokazuje, które nazwy hostów obejmuje certyfikat.

Sprawdź przekierowania HTTP na HTTPS

curl -I http://example.com

Sprawdź nagłówek Location i końcowy schemat.

Podążaj za przekierowaniami i pokaż końcowy URL

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

Pomaga wykrywać łańcuchy przekierowań i niekanoniczne punkty końcowe.

Zawsze używaj opcji -servername z openssl s_client na serwerach wirtualnych/CDN-ach. Bez SNI możesz otrzymać niewłaściwy certyfikat.

Przykłady zastosowań

Zapobiegaj awariom z powodu wygaśnięcia certyfikatu

Wykrywaj certyfikaty zbliżające się do wygaśnięcia, aby móc je odnowić, zanim użytkownicy i boty napotkają błędy w przeglądarce.

  • Cotygodniowe kontrole stanu certyfikatów
  • Audyt domen po zmianach DNS lub CDN

Napraw problemy z niekompletnym łańcuchem certyfikatów

Wykrywaj brakujące certyfikaty pośrednie (częste w niestandardowych konfiguracjach serwerów), które powodują problemy ze starszymi klientami i niektórymi crawlerami.

  • Błędnie skonfigurowany pakiet łańcucha w Nginx/Apache
  • Brak certyfikatów pośrednich w load balancerze

Debugowanie niezgodności nazwy hosta/SAN (www vs apex)

Potwierdź, że certyfikat obejmuje dokładny host, pod którym użytkownicy się łączą, w tym wersje www/bez-www i subdomeny.

  • Apex działa, ale www nie
  • Brak subdomeny API na liście SAN

Weryfikacja wymuszenia HTTPS poprzez przekierowania

Upewnij się, że adresy URL http przekierowują do kanonicznego punktu końcowego https z ważnym certyfikatem.

  • http→https z 301
  • kanonizacja non-www→www

❓ Frequently Asked Questions

Dlaczego przeglądarka może mówić "certyfikat niezaufany", nawet jeśli HTTPS jest włączony?

Typowe przyczyny to wygasły certyfikat, niekompletny łańcuch (brak pośredniego), niezgodność nazwy hosta (SAN nie obejmuje hosta) lub serwowanie niewłaściwego certyfikatu z powodu błędnej konfiguracji SNI/hostingu wirtualnego.

Czym są SAN-y i dlaczego są ważne?

SAN-y (Subject Alternative Names) to nazwy hostów, dla których certyfikat jest ważny. Jeśli do Twojej witryny można uzyskać dostęp zarówno przez example.com, jak i www.example.com, certyfikat powinien obejmować obie (lub powinieneś konsekwentnie przekierowywać na objęty host).

Czy to w porządku, jeśli http przekierowuje do https?

Tak — to zalecane. Upewnij się tylko, że ostateczny cel HTTPS prezentuje ważny certyfikat, a łańcuch przekierowań jest krótki i spójny (preferuj 301 dla przekierowań kanonicznych).

Czy to narzędzie sprawdza wersje TLS/szyfry?

To narzędzie skupia się na inspekcji certyfikatów i typowych błędach konfiguracji. Do wzmacniania protokołów/szyfrów (TLS 1.2/1.3, słabe szyfry) użyj dedykowanego skanera konfiguracji TLS.

Jaka jest różnica między certyfikatem liścia, pośrednim a głównym?

Certyfikat liścia to certyfikat Twojej witryny. Certyfikaty pośrednie łączą go z zaufanym głównym urzędem CA. Przeglądarki ufają korzeniom, więc brak pośrednich może uniemożliwić zbudowanie prawidłowego łańcucha zaufania.

Pro Tips

Best Practice

Odnawiaj certyfikaty wcześniej i automatyzuj odnowienia (ACME) gdziekolwiek to możliwe.

Best Practice

Upewnij się, że SAN obejmują każdą publiczną nazwę hosta, którą obsługujesz (www, apex, subdomeny API) lub wymuś pojedynczy kanoniczny host przez przekierowania.

Best Practice

Zawsze podawaj pełny łańcuch (liść + pośrednie). Wiele awarii wynika z niekompletnych pakietów łańcuchów po migracjach.

Best Practice

Jeśli włączysz przekierowania, ogranicz je do minimum: jeden przeskok do kanonicznego adresu URL https jest idealny.

Best Practice

Połącz prawidłowy TLS z HSTS i nagłówkami bezpieczeństwa dla silniejszej ochrony w rzeczywistym świecie.

Additional Resources

Other Tools