Certyfikat, CSR lub klucz
Wklej certyfikat X.509, żądanie podpisania certyfikatu (CSR), klucz lub pełny łańcuch w formacie PEM albo wczytaj plik .crt, .cer, .der, .p7b, .pfx lub .p12. Zobaczysz podmiot, SAN, okres ważności, rozszerzenia i odciski palców, dowiesz się, czy łańcuch jest poprawnie uporządkowany i podpisany oraz czy klucz prywatny pasuje do certyfikatu. Nic nie opuszcza Twojej przeglądarki.
Możesz wkleić kilka bloków naraz (certyfikat, certyfikaty pośrednie i klucz) lub przeciągnąć tutaj plik

Jak to działa

Certyfikat X.509 to podpisany dokument, który wiąże klucz publiczny z nazwą: domeną, osobą lub organizacją. Między serwerami i w plikach przesyłana jest jego postać binarna (DER), a to, co się kopiuje i wkleja, to ta sama struktura zakodowana w Base64 między wierszami BEGIN CERTIFICATE i END CERTIFICATE, czyli format PEM. W środku znajdują się podmiot, wystawca, okres ważności, klucz publiczny oraz rozszerzenia określające, do czego służy certyfikat i gdzie sprawdzić, czy został unieważniony.

Narzędzie rozpoznaje certyfikaty, żądania podpisania PKCS#10 (CSR), klucze prywatne PKCS#8, PKCS#1 i SEC1, klucze publiczne, pakiety PKCS#7 (.p7b) i pliki PKCS#12 (.pfx, .p12). Jeśli wkleisz kilka bloków naraz, uporządkuje łańcuch od certyfikatu końcowego do głównego, zweryfikuje każdy podpis kluczem wystawcy i porówna klucz prywatny z każdym certyfikatem i każdym CSR, aby wskazać, co do czego pasuje.

Konwertuje też między formatami, tworzy z certyfikatu i klucza plik .pfx wymagany przez IIS i Azure oraz generuje nowy CSR wraz z kluczem prywatnym lub certyfikat z podpisem własnym do testów. Wszystko odbywa się za pomocą kryptograficznego API Twojej przeglądarki: ani certyfikaty, ani klucze nie są wysyłane na serwer.

Przykłady

ISRG Root X1 · SHA-25696:BC:EC:06:26:49:76:F3:74:60:77:9A:CF:28:C5:A7:CF:E8:A3:C0:AA:E1:1A:8F:FC:EE:05:C0:BD:DF:08:C6Odcisk SHA-256 certyfikatu głównego Let's Encrypt. Właśnie ten odcisk publikują urząd certyfikacji i magazyny zaufanych certyfikatów: jeśli odcisk Twojego pliku jest z nim zgodny, to dokładnie ten certyfikat.
ISRG Root X1 · pin SPKIC5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=SHA-256 klucza publicznego w Base64. To wartość, którą wpisuje się w pin-sha256 w konfiguracji bezpieczeństwa sieci Androida lub w certificate pinning aplikacji; nie zmienia się przy odnowieniu certyfikatu, jeśli klucz zostanie użyty ponownie.
root.crt + intermediate.crt + server.crtserver.crt + intermediate.crt + root.crtnginx i HAProxy traktują pierwszy certyfikat w pliku jako certyfikat serwera. Jeśli łańcuch jest odwrócony, nginx zgłasza błąd key values mismatch, ponieważ porównuje klucz prywatny z certyfikatem głównym.
openssl pkcs12 -in viejo.pfx -legacy -nodes | openssl pkcs12 -export -out nuevo.pfxPBES2 · AES-256-CBC · MAC SHA-256Pliki .pfx eksportowane przez starsze wersje Windows lub OpenSSL 1.x są szyfrowane algorytmami RC2 i 3DES, których przeglądarki nie obsługują. To polecenie szyfruje je ponownie algorytmem AES, domyślnym formatem OpenSSL 3.

Przypadki użycia

  • Sprawdzenie przed instalacją, czy certyfikat przesłany przez urząd certyfikacji obejmuje wszystkie domeny (SAN) i czy data wygaśnięcia jest zgodna z oczekiwaniami.
  • Ustalenie, który z kluczy prywatnych pozostawionych na serwerze pasuje do którego certyfikatu, bez porównywania modułów w OpenSSL.
  • Znalezienie przyczyny, dla której klient nie ufa Twojej witrynie: brakujący certyfikat pośredni, nieuporządkowany łańcuch lub certyfikat podpisany SHA-1.
  • Wygenerowanie CSR do zakupu lub odnowienia certyfikatu, z kluczem utworzonym na Twoim komputerze i odpowiednim poleceniem OpenSSL, jeśli wolisz zrobić to na serwerze.
  • Konwersja pliku .crt i jego klucza .key do .pfx dla IIS, Azure App Service lub magazynu kluczy Java albo wyodrębnienie certyfikatu i klucza z .pfx dla nginx.
  • Uzyskanie odcisku lub pinu SPKI certyfikatu, aby skonfigurować certificate pinning w aplikacji mobilnej lub zweryfikować certyfikat klienta.

Najczęstsze pytania

Czy wklejanie tutaj klucza prywatnego jest bezpieczne?

Klucz jest przetwarzany przez Web Crypto API w Twojej przeglądarce i nie jest wysyłany na żaden serwer; możesz to sprawdzić na karcie Sieć w narzędziach deweloperskich. Mimo to dobrą praktyką jest traktowanie każdego klucza produkcyjnego jak sekretu: wklejaj go tylko w narzędziach, którym ufasz, i zamknij kartę po zakończeniu pracy.

Czym różnią się PEM, DER, CRT, CER, P7B i PFX?

DER to certyfikat w postaci binarnej, a PEM to te same dane binarne w Base64 między wierszami BEGIN i END. Rozszerzenia .crt i .cer nie określają formatu: plik może być w każdym z nich. Plik .p7b to pakiet PKCS#7 z kilkoma certyfikatami i bez klucza. Plik .pfx lub .p12 to PKCS#12: przechowuje razem certyfikat, certyfikaty pośrednie i klucz prywatny, zaszyfrowane hasłem.

Jak sprawdzić, czy na moim serwerze brakuje certyfikatu pośredniego?

Wklej to, co masz skonfigurowane na serwerze. Jeśli łańcuch kończy się certyfikatem, który nie ma podpisu własnego, brakuje ogniwa: jego rozszerzenie Authority Information Access zwykle zawiera w polu CA Issuers adres, pod którym można pobrać wystawcę. Przeglądarki na komputerach czasem pobierają go same, ale Android, curl i większość bibliotek już nie, dlatego błąd pojawia się tylko u niektórych klientów.

Jak długo może być ważny publiczny certyfikat TLS?

Od września 2020 roku przeglądarki odrzucają certyfikaty ważne dłużej niż 398 dni. W 2025 roku CA/Browser Forum zatwierdziło stopniowe skracanie maksymalnego okresu: 200 dni dla certyfikatów wystawionych od 15 marca 2026 roku, 100 dni od marca 2027 i 47 dni od marca 2029. Dlatego warto zautomatyzować odnawianie za pomocą ACME. Wewnętrzne CA firm nie podlegają temu limitowi.

RSA czy ECDSA dla CSR?

ECDSA P-256 zapewnia bezpieczeństwo porównywalne z 3072-bitowym RSA przy znacznie mniejszych kluczach i podpisach, a serwer szybciej wykonuje handshake. Obsługują go wszystkie współczesne przeglądarki i systemy. RSA 2048 pozostaje bezpiecznym wyborem, jeśli masz bardzo stare klienty, urządzenia wbudowane lub system akceptujący wyłącznie RSA.

Czy wystarczy wpisać domenę w nazwie pospolitej (CN)?

Nie. Od Chrome 58, czyli od 2017 roku, przeglądarki biorą pod uwagę wyłącznie nazwy alternatywne (SAN), a CN jest ignorowane. Każda domena, dla której ma działać certyfikat, łącznie z tą z CN, musi znaleźć się na liście SAN. Symbol wieloznaczny, taki jak *.example.com, obejmuje tylko jeden poziom: działa dla www.example.com, ale nie dla example.com ani a.b.example.com.