Parser certyfikatów

Certyfikaty X.509 to standardowy format certyfikatów klucza publicznego używanych w TLS/SSL. To narzędzie parsuje certyfikaty zakodowane w PEM, aby wyświetlić podmiot, wystawcę, okres ważności, szczegóły klucza publicznego i rozszerzenia. Niezbędne do debugowania problemów z połączeniami HTTPS.

Specyfikacje

Typowe zastosowania

Debugowanie błędów połączenia SSL/TLS ("certyfikat wygasł")
Weryfikacja, czy certyfikat obejmuje prawidłowe nazwy domen
Sprawdzanie dat wygaśnięcia certyfikatów w celu planowania odnowienia
Inspekcja certyfikatów pośrednich i głównych w łańcuchu
Weryfikacja, czy atrybuty certyfikatu spełniają wymagania zgodności

Funkcje

Parsowanie certyfikatów zakodowanych w PEM (-----BEGIN CERTIFICATE-----)
Wyświetlanie nazw wyróżniających podmiotu i wystawcy
Pokazywanie okresu ważności (Nie wcześniej / Nie później)
Wyodrębnianie algorytmu i rozmiaru klucza publicznego
Wyświetlanie alternatywnych nazw podmiotu (SAN)
Pokazywanie rozszerzeń certyfikatu (Użycie klucza, Rozszerzone użycie klucza, Podstawowe ograniczenia)
Wyświetlanie identyfikatorów klucza urzędu/podmiotu
Punkty dystrybucji CRL i adresy URL dostępu do informacji o urzędzie

Przyklady

Certyfikat samopodpisany

Wypróbuj →

Certyfikat X.509 dla example.com z alternatywnymi nazwami podmiotu.

Klucz prywatny

Wypróbuj →

Odpowiadający klucz prywatny RSA w formacie PKCS#8.

Wskazowki

Eksportuj certyfikat z przeglądarki: kliknij kłódkę > Certyfikat > Szczegóły > Eksportuj.
Pobierz certyfikat strony za pomocą: openssl s_client -connect example.com:443
SAN (Subject Alternative Names) zawierają listę wszystkich prawidłowych nazw domen.
Certyfikaty główne są samopodpisane (wystawca = podmiot).
Sprawdź łańcuch certyfikatów za pomocą: openssl verify -CAfile ca.pem cert.pem

Zrozumienie Parser certyfikatów

Certyfikaty X.509 stanowią fundament zaufania w internecie, umożliwiając szyfrowanie TLS/SSL dla połączeń HTTPS, podpisywanie kodu, bezpieczeństwo poczty elektronicznej (S/MIME) i uwierzytelnianie VPN. Certyfikat wiąże klucz publiczny z tożsamością (nazwą domeny, organizacją lub osobą), a urząd certyfikacji (CA) potwierdza to powiązanie, podpisując cyfrowo certyfikat.

Certyfikaty są zazwyczaj przechowywane w formacie PEM — dane DER zakodowane w Base64 ujęte między znacznikami -----BEGIN CERTIFICATE----- i -----END CERTIFICATE-----. Certyfikat zawiera podmiot (kogo certyfikat identyfikuje), wystawcę (kto go podpisał), okres ważności (daty Nie wcześniej i Nie później), klucz publiczny podmiotu oraz rozszerzenia kontrolujące użycie. Rozszerzenie Subject Alternative Name (SAN) zawiera listę wszystkich nazw domen, które certyfikat obejmuje.

Łańcuchy certyfikatów ustanawiają zaufanie, łącząc certyfikat końcowy z zaufanym głównym CA przez jeden lub więcej pośrednich CA. Gdy przeglądarka łączy się ze stroną internetową, weryfikuje łańcuch: certyfikat serwera został podpisany przez pośredni CA, który został podpisany przez główny CA, któremu przeglądarka ufa. Przerwany łańcuch — brakujące certyfikaty pośrednie lub nieznany certyfikat główny — powoduje znany błąd "Twoje połączenie nie jest prywatne".

Zarządzanie certyfikatami jest częstą przyczyną awarii. Wygasłe certyfikaty powodują natychmiastowe przerwanie usługi. Niezgodne nazwy domen wywołują ostrzeżenia przeglądarki. Brakujące certyfikaty pośrednie działają w niektórych przeglądarkach (które mogą je buforować lub pobierać), ale zawodzą w innych oraz w klientach API. Monitorowanie wygaśnięcia certyfikatów i automatyzacja odnowienia za pomocą narzędzi takich jak Let's Encrypt i certbot jest niezbędna dla niezawodnego działania.

Aby sprawdzić, kiedy certyfikat wygasa, wklej zawartość PEM do tego narzędzia i sprawdź datę Nie później. Z wiersza poleceń uruchom openssl x509 -enddate -noout -in cert.pem dla pliku lokalnego lub openssl s_client -connect example.com:443 przekierowane do openssl x509 -noout -enddate dla zdalnego serwera. Automatyczne monitorowanie za pomocą certbot, cert-manager lub dedykowanych usług monitorujących może ostrzegać z dużym wyprzedzeniem przed wygaśnięciem, aby zapobiec awariom.

Certyfikaty główne są samopodpisane (wystawca jest równy podmiotowi) i są preinstalowane w przeglądarkach i systemach operacyjnych jako kotwice zaufania. Certyfikaty pośrednie są podpisane przez główny CA i służą do podpisywania certyfikatów końcowych. Ten łańcuch zaufania chroni klucz główny — jeśli certyfikat pośredni zostanie skompromitowany, unieważniany jest tylko ten certyfikat pośredni, a nie główny. Serwery muszą wysyłać pełny łańcuch (certyfikat końcowy plus wszystkie pośrednie), ale nie powinny dołączać samego certyfikatu głównego.

Alternatywne nazwy podmiotu (SAN) zawierają listę wszystkich nazw domen i adresów IP, dla których certyfikat jest ważny. Pojedynczy certyfikat może chronić wiele domen, takich jak example.com, www.example.com i api.example.com, używając SAN. Nowoczesne przeglądarki używają SAN zamiast pola Common Name (CN) do walidacji domeny. Certyfikaty wieloznaczne (*.example.com) obejmują jeden poziom subdomen, ale nie samą domenę nadrzędną.

Certyfikat, który działa w przeglądarkach, ale zawodzi w klientach API, to częsty problem spowodowany niekompletnymi łańcuchami certyfikatów. Przeglądarki są bardziej wyrozumiałe — niektóre automatycznie pobierają brakujące certyfikaty pośrednie przez AIA (Authority Information Access) lub używają wcześniej zbuforowanych certyfikatów pośrednich. Klienci API, tacy jak curl, Node.js i biblioteka requests w Pythonie, zazwyczaj wymagają, aby serwer wysłał kompletny łańcuch. Upewnij się, że Twój serwer jest skonfigurowany do wysyłania certyfikatu końcowego plus wszystkich certyfikatów pośrednich, i przetestuj za pomocą curl -v lub openssl s_client, aby zweryfikować kompletność łańcucha.

← Powrot do wszystkich narzedzi