Security

SSL Checker

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

Hostname host or host:port (default 443)
github.com:443
TLSv1.3 expires in 66d
Verdict
  • Certificate is valid for this host and not expired.
Subject?
github.com
Issuer?
Sectigo Public Server Authentication CA DV E36 — Sectigo Limited
Valid from
2026-07-03T00:00:00Z
Valid to?
2026-09-30T23:59:59Z
Signature algorithm?
ecdsa-with-SHA256
Public key?
EC 256 bits
Negotiated cipher?
TLS_AES_128_GCM_SHA256
Chain depth?
3
Hostname matches?
yes
Self-signed?
no
Subject Alternative Names?
  • github.com
  • www.github.com
Raw certificate (PEM)
-----BEGIN CERTIFICATE----- MIID7jCCA5SgAwIBAgIQcgEOA/SgZ/5OeWJmQwcY9jAKBggqhkjOPQQDAjBgMQsw CQYDVQQGEwJHQjEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMTcwNQYDVQQDEy5T ZWN0aWdvIFB1YmxpYyBTZXJ2ZXIgQXV0aGVudGljYXRpb24gQ0EgRFYgRTM2MB4X DTI2MDcwMzAwMDAwMFoXDTI2MDkzMDIzNTk1OVowFTETMBEGA1UEAxMKZ2l0aHVi LmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABIWWMDSOi/1sMgquP4I/obBM 735wpzcIZi4fLeiBsToXVVSwjj4OPH+W6azHzxETM0gUP7raehddpJ8uwjqYsTij ggJ5MIICdTAfBgNVHSMEGDAWgBQXmagEwW/kLXCoChA9A9PpGrgmYzAdBgNVHQ4E FgQUEKU6Ytbv1gZWnty4gvzCe2hdPWkwDgYDVR0PAQH/BAQDAgeAMAwGA1UdEwEB /wQCMAAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwSQYDVR0gBEIwQDA0BgsrBgEEAbIx AQICBzAlMCMGCCsGAQUFBwIBFhdodHRwczovL3NlY3RpZ28uY29tL0NQUzAIBgZn gQwBAgEwgYQGCCsGAQUFBwEBBHgwdjBPBggrBgEFBQcwAoZDaHR0cDovL2NydC5z ZWN0aWdvLmNvbS9TZWN0aWdvUHVibGljU2VydmVyQXV0aGVudGljYXRpb25DQURW RTM2LmNydDAjBggrBgEFBQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wggEF BgorBgEEAdZ5AgQCBIH2BIHzAPEAdgDXbX0Q0af1d8LH6V/XAL/5gskzWmXh0LMB cxfAyMVpdwAAAZ8lTHVtAAAEAwBHMEUCIQCkpa0ZYNwsPiMRLHz+kk1QS/W9bg/8 4yNBVGkT289dNQIgMWLgxYp6vGJXJxyD3c1NI1aZsPA7GqyLSXaZLZHgKh0AdwDI o8R/x7OtuTVrAT9qehJt4zpOQ6XGRvmXrTl1mR3PmgAAAZ8lTHVhAAAEAwBIMEYC IQDsO+TR8EVfCiObBPoDLRKzKLQ/uorsebJ2aZDIejA9RgIhAJ6dp7FqCD93tQXX AF24pDIms1fX4dZ+VPzXGuD8u8t1MCUGA1UdEQQeMByCCmdpdGh1Yi5jb22CDnd3 dy5naXRodWIuY29tMAoGCCqGSM49BAMCA0gAMEUCIB0PC2GRSurxu8gCkSNsYxmw kAtCNfCvpXRiif8PhGkmAiEAzBH4AVYAtv1FsMrJabD9FYcAql0EteKafckH2exj Uag= -----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.