Security

SSL Checker

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

Hostname host or host:port (default 443)
badssl.com:443
TLSv1.2 expires in 29d
Verdict
  • Certificate is valid for this host and not expired.
Subject?
*.badssl.com
Issuer?
R13 — Let's Encrypt
Valid from
2026-05-26T20:02:50Z
Valid to?
2026-08-24T20:02:49Z
Signature algorithm?
RSA-SHA256
Public key?
RSA 2048 bits
Negotiated cipher?
ECDHE-RSA-AES128-GCM-SHA256
Chain depth?
2
Hostname matches?
yes
Self-signed?
no
Subject Alternative Names?
  • *.badssl.com
  • badssl.com
Raw certificate (PEM)
-----BEGIN CERTIFICATE----- MIIE/jCCA+agAwIBAgISBTPcKLMYoeERiY35MJr77TYzMA0GCSqGSIb3DQEBCwUA MDMxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQwwCgYDVQQD EwNSMTMwHhcNMjYwNTI2MjAwMjUwWhcNMjYwODI0MjAwMjQ5WjAXMRUwEwYDVQQD DAwqLmJhZHNzbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC0 6KANZcLJSK/zv5hCw7U+8Q9+cPdhyiP5XSOZrctjsIu3s2M9abZ9zY3dhi9H9KXt +be2V93qjxAAGWkAbfGXT+6S/xRCuwtTmWOD/4PsX2Near6jBz0g6c3ttItPGHy2 l2FUy0Hl5epWK836wSw58p9jeskm8zCuek/LJ/nXGhfnXMvW6rvxMjW72AEofZpA rGzlCjb2b2EY5B6zL1CxB77Yu8pzP4gEbBH4Sp7iT6rVr2ZVipVEdwh0o2cg61MF /ofMDKjZ7wHx+l/vU6lJlzXYY98LtS4+hw5kBsoulqRGyeIJks7M1+mrdl0xSwtg xPiR1T/weGyuwJ0YE9G3AgMBAAGjggImMIICIjAOBgNVHQ8BAf8EBAMCBaAwEwYD VR0lBAwwCgYIKwYBBQUHAwEwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUZfXhFxQb 7MDrEQ6ois5LEsv4t2swHwYDVR0jBBgwFoAU56ufDywzoFPTXk94yLKEDjvWkjMw MwYIKwYBBQUHAQEEJzAlMCMGCCsGAQUFBzAChhdodHRwOi8vcjEzLmkubGVuY3Iu b3JnLzAjBgNVHREEHDAaggwqLmJhZHNzbC5jb22CCmJhZHNzbC5jb20wEwYDVR0g BAwwCjAIBgZngQwBAgEwLgYDVR0fBCcwJTAjoCGgH4YdaHR0cDovL3IxMy5jLmxl bmNyLm9yZy81Mi5jcmwwggEMBgorBgEEAdZ5AgQCBIH9BIH6APgAdgDYCVU7lE96 /8gWGW+UT4WrsPj8XodVJg8V0S5yu0VLFAAAAZ5mF468AAAEAwBHMEUCID7FfrBs 57qfYRHjk9PXh4H8gI+2878ExKWwXR2+pj7iAiEArHIWJ6KuWeub9BkKEcI64K87 DwKPjgby0zhTZjsOEa0AfgAai51rD/6/gbR5OcbSMQqG1tEC1PBG4hgsneNfXiYl 7wAAAZ5mF4+8AAgAAAUAFztGcAQDAEcwRQIgJqlkzRV9qZZ8pRgtKIr4XHOMZsQt QKthekK0LnFvSN0CIQDW3BRjOXRcjWLvhVRuhMknknygj5ok2kab4Hfrq6EHvzAN BgkqhkiG9w0BAQsFAAOCAQEANIsCNUpmK3HyXz6TcaXx/G1H0n8so0JXm2ZaWSa9 RJMK/H4NsAcsftAMYF2SqaK3X7nayHT7wpL1/O9D+YMHLzUoLawlZe2dqvKWsm6S vdV6cMTGmtQkz2EQjRy1u1trzt06YnUL83P4ATUYKh0VI6xT4WIhap0ZtJTaTNCi AV2mF2UlDkSVNwemNDIhPjxPOpsCfe1vybwHLfE800WdlL0eMA6jMdrG26BcsvZy TwvrjAg21ixi8rcgwj4d7/fVA3yE7/5S3c98ZNBimfeyEb1PMApMAYbOCQEICgyK ftka8gzQRX3Hn906O3dXZkaDdo067k82BnIos22TmiTg7w== -----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.