Security

SSL Checker

Sprawdź łańcuch certyfikatów, wygaśnięcie i algorytm.

Hostname host or host:port (default 443)
example.com:443
TLSv1.3 expires in 34d
Verdict
  • Certificate is valid for this host and not expired.
Subject?
example.com
Issuer?
Cloudflare TLS Issuing ECC CA 3 — SSL Corporation
Valid from
2026-05-31T21:39:12Z
Valid to?
2026-08-29T21:41:26Z
Signature algorithm?
ecdsa-with-SHA256
Public key?
EC 256 bits
Negotiated cipher?
TLS_AES_256_GCM_SHA384
Chain depth?
4
Hostname matches?
yes
Self-signed?
no
Subject Alternative Names?
  • example.com
  • *.example.com
Raw certificate (PEM)
-----BEGIN CERTIFICATE----- MIID5zCCA42gAwIBAgIQGqc/6iV74zNLmilVLm+HjjAKBggqhkjOPQQDAjBRMQsw CQYDVQQGEwJVUzEYMBYGA1UECgwPU1NMIENvcnBvcmF0aW9uMSgwJgYDVQQDDB9D bG91ZGZsYXJlIFRMUyBJc3N1aW5nIEVDQyBDQSAzMB4XDTI2MDUzMTIxMzkxMloX DTI2MDgyOTIxNDEyNlowFjEUMBIGA1UEAwwLZXhhbXBsZS5jb20wWTATBgcqhkjO PQIBBggqhkjOPQMBBwNCAAR3K9vg9mgByiZluphXApVAUpQtIO9MPLbbdVxu2SDI KEYKZhTqszaA9lNa6oAGtsi++/m+uwI35sAG+zkIpAeOo4ICgDCCAnwwDAYDVR0T AQH/BAIwADAfBgNVHSMEGDAWgBSDA/3n9vVKTRVB9O0iFtMyCj7KZjBsBggrBgEF BQcBAQRgMF4wOQYIKwYBBQUHMAKGLWh0dHA6Ly9pLmNmLWkuc3NsLmNvbS9DbG91 ZGZsYXJlLVRMUy1JLUUzLmNlcjAhBggrBgEFBQcwAYYVaHR0cDovL28uY2YtaS5z c2wuY29tMCUGA1UdEQQeMByCC2V4YW1wbGUuY29tgg0qLmV4YW1wbGUuY29tMCMG A1UdIAQcMBowCAYGZ4EMAQIBMA4GDCsGAQQBgqkwAQMBATATBgNVHSUEDDAKBggr BgEFBQcDATBTBgNVHR8ETDBKMEigRqBEhkJodHRwOi8vYy5jZi1pLnNzbC5jb20v YWU4MDFlZDFjNTViYjU3OWQ3OTIwOGIwZDc3MmFjZmI4Y2MzYTIwOC5jcmwwDgYD VR0PAQH/BAQDAgeAMA8GCSsGAQQBgtpLLAQCBQAwggEEBgorBgEEAdZ5AgQCBIH1 BIHyAPAAdgCUTkOH+uzB74HzGSQmqBhlAcfTXzgCAT9yZ31VNy4Z2AAAAZ6AAzGJ AAAEAwBHMEUCIQCBv0JM0mXaiiQ9efuArkk3O2t/RQ39q7O3oKtYCvOUhQIgdn2u t5rn+AWzBqZ9m1VOlMLpT/jy2M92Is6itMy9rR8AdgDIo8R/x7OtuTVrAT9qehJt 4zpOQ6XGRvmXrTl1mR3PmgAAAZ6AAzGgAAAEAwBHMEUCIQCoc8r0LVigaz6pvG8s v0+uBqzf+LPNPxwYxtgkuVdNMwIgAbK/qRNJIWljIVp30PFWjmM+SnoT80ShaPJM GdbtNLMwCgYIKoZIzj0EAwIDSAAwRQIhALDciGbviRHUIMPez2CVH+Vc0NiaT8Br FrUGD7dej3D4AiAfs90UtVHGYKTXYYPIJlVqUK1amlBBby7M2KI7pSMjxA== -----END CERTIFICATE-----
What does each field mean?

Field reference

Subject

Pole Subject identyfikuje posiadacza certyfikatu. Nowoczesne certyfikaty opierają się na CN (Common Name) plus Subject Alternative Names. Pola Organization (O), Organizational Unit (OU), Locality (L) występują w certyfikatach EV/OV, a w prostych DV (np. Let's Encrypt) są nieobecne.

Issuer (wystawca)

Identyfikuje CA, który poręczył za subject. Przeglądarki dostarczane są z listą zaufanych root CA; certyfikaty podpisane przez niezaufanego wystawcę (lub self-signed) wywołują NET::ERR_CERT_AUTHORITY_INVALID. Popularne publiczne CA: Let's Encrypt, DigiCert, Sectigo, GlobalSign, GoDaddy.

Subject Alt Names (SAN)

Pojedynczy certyfikat może obejmować wiele hostów poprzez rozszerzenie SAN — typowo wildcard (<code>*.example.com</code>) lub multi-domain (SAN). Od 2017 roku przeglądarki ignorują Common Name i porównują wyłącznie wpisy SAN. Jeśli hosta nie ma na liście, certyfikat jest dla niego nieważny.

Głębokość łańcucha

Łańcuch zaufania zaczyna się od leaf-certyfikatu serwera, przechodzi przez jeden lub więcej pośrednich CA i kończy na root CA z magazynu zaufania przeglądarki. Głębokość 2 (leaf + 1 pośredni) jest typowa. Źle skonfigurowane serwery często zapominają wysłać pośrednich — klienci widzą wtedy błąd "incomplete chain".

Algorytm podpisu

Opisuje, jak CA podpisał certyfikat. <code>sha256WithRSAEncryption</code> (RSA + SHA-256) to bezpieczny domyślny standard. <code>ecdsa-with-SHA256</code> używa krzywych eliptycznych — mniejsze klucze, taka sama siła. <code>sha1WithRSAEncryption</code> jest złamane od 2017 roku i odrzucane przez wszystkie główne przeglądarki.

Klucz publiczny

Publiczna połowa pary kluczy. RSA 2048 bitów to dziś praktyczne minimum; 3072+ dla kluczy długoterminowych. EC P-256 jest krótszy (~256-bitowa równoważna siła) i szybszy. Wszystko poniżej RSA 2048 lub starsze niż P-256 należy wymienić.

Wynegocjowany szyfr

Opisuje szyfrowanie faktycznych danych: wymiana kluczy (ECDHE), szyfr (AES_256_GCM, CHACHA20_POLY1305), MAC (SHA384). Pakiety z forward secrecy (ECDHE-*) są wymagane przez większość standardów bezpieczeństwa. Suity oparte na CBC lub RC4 są przestarzałe.

Zgodność nazwy hosta

Nawet w pełni ważny certyfikat zostanie odrzucony, jeśli żądanej nazwy hosta nie ma na liście SAN. Wildcards obejmują dokładnie jedną etykietę DNS: <code>*.example.com</code> pokrywa <code>www.example.com</code>, ale NIE <code>a.b.example.com</code> ani samego <code>example.com</code>.

Self-signed

W certyfikacie self-signed Subject = Issuer. Przeglądarki domyślnie mu nie ufają — zobaczymy "NET::ERR_CERT_AUTHORITY_INVALID". Dopuszczalne w środowiskach wewnętrznych/staging, gdzie kontrolujemy zarówno serwer, jak i klienta. W produkcji warto użyć Let's Encrypt (bezpłatny) lub publicznego CA.

Ważny do (wygaśnięcie)

Przeglądarki natychmiast odrzucają wygasłe certyfikaty. Certyfikaty publicznych CA żyją zwykle 90–397 dni. Warto skonfigurować auto-odnawianie: ACME / Let's Encrypt na 60 dni przed końcem, komercyjne CA — na 30. Spodziewamy się stopniowego przejścia branży na obowiązkowe 90 dni do 2027 roku.

W pełni ważny

Wszystkie podstawowe kontrole przeszły pomyślnie: łańcuch zaufania kotwiczy w root zaufanym przez przeglądarkę, nazwa hosta zgadza się z SAN, certyfikat mieści się w oknie ważności, algorytm podpisu jest akceptowalny. To stan, który przeglądarka pokazuje zieloną kłódką.

O tym narzędziu

SSL Checker otwiera prawdziwe połączenie TLS z Twoim hostem, przechwytuje łańcuch certyfikatów, który serwer prezentuje, i raportuje wszystko, co ma znaczenie: subject, issuer, daty ważności, pełny łańcuch pośrednich aż do trust anchora, algorytm podpisu, rozmiar klucza publicznego, obsługiwane wersje TLS i cipher suites, Subject Alternative Names oraz status OCSP stapling. Sprawdzenie odbywa się po stronie serwera z naszego hosta we Frankfurcie, więc widzisz dokładnie to, co widzi zdalny odwiedzający — a nie to, co zapisała w cache Twoja przeglądarka.

Czysty certyfikat to nie tylko "zielona kłódka". Walidujemy dopasowanie nazwy hosta wobec SAN-ów (legacy pole CN jest wyłącznie informacyjne, zgodnie z RFC 6125), sprawdzamy, czy każde ogniwo łańcucha jest podpisane przez następne, weryfikujemy, czy pośrednie certyfikaty są prezentowane we właściwej kolejności (częsty błąd wdrożeniowy), potwierdzamy, że leaf nie wygasł i nie jest jeszcze nieważny, oraz ostrzegamy, jeśli leaf używa słabego podpisu (SHA-1) lub zbyt małego klucza (RSA < 2048 bitów). Wszystko to w jednym handshake HTTPS.

Kiedy używać tego narzędzia

  • Weryfikacja przed wdrożeniem. Po wystawieniu certyfikatu Let's Encrypt lub zakupie komercyjnego potwierdź, że łańcuch jest kompletny, zanim skierujesz na niego prawdziwych użytkowników.
  • Monitorowanie wygaśnięć. Wykrywaj certyfikaty, które wygasną w ciągu najbliższych 7/14/30 dni, i odnawiaj zanim zaczną dzwonić alerty.
  • Debugowanie mixed-content. Znajdź subdomeny, które prezentują inny (lub self-signed) certyfikat niż główna witryna.
  • Sanity check po migracji. Po przejściu na nowy CDN lub load balancer zweryfikuj, że nowy certyfikat i łańcuch są takie, jakich oczekujesz.

Co właściwie oznacza "chain incomplete"

Przeglądarki i systemowe trust store dostarczają kilkaset głównych CA. Twój leaf jest podpisany przez intermediate, który jest podpisany przez kolejny intermediate lub bezpośrednio przez root. Serwer musi wysłać leaf + każdy intermediate aż do (ale nie wraz z) rootem — Firefox i Chrome spróbują pobrać brakujące intermediate z rozszerzenia AIA, ale iOS, starsze Androidy i większość nie-przeglądarkowych klientów TLS odrzuci handshake. Nasz chain inspector mówi dokładnie, którego ogniwa brakuje, byś mógł wkleić właściwy intermediate do konfiguracji serwera.

Najczęstsze pytania

Moja przeglądarka pokazuje kłódkę, ale Twoje narzędzie mówi "chain incomplete" — kto ma rację?

Oboje. Nowoczesne desktopowe przeglądarki łatają niekompletne łańcuchy, pobierając brakujące intermediate przez rozszerzenie AIA lub z własnego cache — użytkownik widzi działającą kłódkę. Ale iOS Safari, wiele aplikacji Android, curl, klienty OpenSSL i nie-przeglądarkowe biblioteki TLS tego nie robią. Jeśli nasze narzędzie mówi "incomplete", Twoja strona zawiedzie na nietrywialnej części klientów; napraw, serwując pełny łańcuch z serwera.

Co to jest OCSP stapling?

Sposób, w jaki serwer dołącza świeży, podpisany przez CA dowód ważności do certyfikatu podczas handshake TLS — by przeglądarka nie musiała dzwonić do respondera OCSP CA przy każdym połączeniu. Stapling przyspiesza ładowanie stron i chroni prywatność użytkownika (CA nigdy nie dowiaduje się, które strony odwiedza użytkownik). Większość nowoczesnych serwerów (nginx, Apache 2.4, Caddy) obsługuje to; wiele włącza domyślnie.

Jak często powinienem sprawdzać?

Raz na tydzień wystarczy dla produkcji. Certyfikaty Let's Encrypt odnawiają się co 60–90 dni, komercyjne co 12 miesięcy; tak czy inaczej niezauważone wygaśnięcie to najczęstszy tryb awarii SSL. Cache'ujemy wyniki przez 10 minut, więc szybkie sprawdzenie po wdrożeniu daje natychmiastową informację zwrotną. Połącz to z automatycznym monitorem (Uptime Kuma, StatusCake) dla proaktywnych alertów.

Dlaczego narzędzie nie waliduje wobec mojego prywatnego CA?

Używamy standardowego publicznego trust bundle CA (Mozilla, którego używa też większość systemów operacyjnych). Prywatne CA — wewnętrzne firmowe rooty, ACME-CA w homelabie — nie są w żadnym publicznym trust store, więc walidacja łańcucha (poprawnie) oznaczy je jako untrusted. Szczegóły certyfikatu (subject, daty, rozmiar klucza) są nadal raportowane; zawodzi tylko sprawdzenie trust anchora.