Weryfikacja CSR (PEM) — pokazuje pola Subject, SAN, długość klucza, algorytm.
Certum — wydanie 10 minut, od 189 zł/rok. Używamy tego samego CSR do wniosku.
Zobacz certyfikatyCSR (Certificate Signing Request) to plik z prośbą o wystawienie certyfikatu SSL, który generujesz na swoim serwerze. Wysyłasz go do urzędu certyfikacji (Certum, DigiCert), a ten na jego podstawie wydaje właściwy certyfikat. Zanim wyślesz CSR do CA — koniecznie go zweryfikuj. Źle przygotowany plik skutkuje odrzuceniem zamówienia lub, co gorsza, wydaniem certyfikatu na złą domenę.
Upewnij się, że CN (domena) i SAN są poprawne. Literówka = certyfikat nie zadziała.
Współczesne standardy wymagają co najmniej RSA 2048 bit lub EC P-256. Słabszy klucz = odrzucenie CSR.
Administrator lub dostawca wygenerował CSR za Ciebie — sprawdź, czy dane się zgadzają z Twoją firmą.
Nasze narzędzie sprawdza też, czy CSR jest prawidłowo podpisany kluczem prywatnym (integralność).
Cała analiza zajmuje dosłownie sekundy. Nie musisz niczego instalować.
Otwórz plik .csr lub .req w dowolnym edytorze tekstu.
Skopiuj całość razem z nagłówkami -----BEGIN CERTIFICATE REQUEST----- i END.
Wklej skopiowany tekst w pole powyżej i kliknij "Sprawdź CSR". Analiza odbywa się na szyfrowanym HTTPS, nic nie zapisujemy ani nie logujemy.
Sprawdź czy Common Name (CN) to Twoja domena, czy SAN-y obejmują wszystkie subdomeny, i czy klucz ma min. 2048 bit (RSA) lub P-256 (EC).
Nasze narzędzie wyciąga wszystkie istotne informacje z pliku CSR. Oto co oznaczają poszczególne pola.
Główna domena, dla której wystawiasz certyfikat. Np. sklep.example.com.
Dla certyfikatu Wildcard wpisujesz *.example.com.
Uwaga: nowoczesne przeglądarki (Chrome, Firefox, Safari) ignorują pole CN i patrzą tylko na SAN. Jeśli Twoja domena nie znajdzie się w SAN, certyfikat nie zadziała, nawet jeśli CN jest poprawne.
Pełna lista domen, dla których certyfikat będzie ważny. Może zawierać wiele wartości: example.com, www.example.com, api.example.com itp.
Jeśli potrzebujesz certyfikatu dla kilku domen (Multi-Domain SAN), wszystkie muszą być tutaj wymienione. Dodanie subdomeny po wystawieniu certyfikatu wymaga re-issue.
Informacja, jakim algorytmem został wygenerowany klucz prywatny. Najpopularniejsze opcje to RSA 2048 bit (standard) lub RSA 4096 bit (większe bezpieczeństwo, wolniejsze handshake). Coraz częściej używa się też EC (Elliptic Curve) na krzywej P-256 lub P-384 — zapewnia ten sam poziom bezpieczeństwa przy krótszych kluczach.
Minimalne wymagania: RSA 2048 bit lub EC P-256. Klucze RSA 1024 bit są nieakceptowane przez CA od 2014 roku.
CSR jest podpisany Twoim kluczem prywatnym, co udowadnia, że posiadasz odpowiedni klucz do wystawianego certyfikatu. Nasze narzędzie weryfikuje ten podpis — jeśli "prawidłowy", CSR jest integralny i nie był modyfikowany. Używany algorytm hash to najczęściej SHA-256.
Nieprawidłowy podpis = CSR jest uszkodzony lub został edytowany. W takim przypadku wygeneruj nowy CSR.
Odpowiedzi na typowe wątpliwości dotyczące przygotowania Certificate Signing Request.
Najczęściej używa się komendy openssl, dostępnej na wszystkich systemach Linux i macOS:
$ openssl req -new -newkey rsa:2048 -nodes \
-keyout domena.key -out domena.csrPo wykonaniu zostaniesz zapytany o dane firmy (Country, State, Organization, Common Name itp.). Pliki domena.key (klucz prywatny — trzymaj w tajemnicy!) i domena.csr (CSR — prześlesz do CA) zostaną utworzone w bieżącym katalogu.
RSA 2048 bit to aktualny standard — zapewnia wystarczające bezpieczeństwo do 2030 roku według wytycznych NIST i CAB Forum. RSA 3072 bit i 4096 bit są bezpieczniejsze, ale powodują wolniejsze handshake TLS (szczególnie na urządzeniach mobilnych). Jeśli potrzebujesz najwyższego bezpieczeństwa przy zachowaniu wydajności — rozważ EC P-256, który jest szybszy i krótszy niż RSA, przy porównywalnej odporności kryptograficznej.
Nie — CSR zawiera tylko klucz publiczny. Klucz prywatny nigdy nie powinien opuścić Twojego serwera. CSR można bezpiecznie wysyłać emailem, przez formularz CA lub publicznie, bo nie zawiera żadnych poufnych danych. Jeśli jednak zgubisz klucz prywatny — certyfikat, który dostaniesz, będzie bezużyteczny, bo nie masz klucza do jego użycia. Pamiętaj o zabezpieczeniu .key (backup, uprawnienia 600, nie commituj do gita).
SAN (Subject Alternative Name) to rozszerzenie X.509 pozwalające wpisać wiele nazw DNS w jednym certyfikacie. Tak, musisz go mieć. Od 2017 roku nowoczesne przeglądarki (Chrome, Firefox, Safari) ignorują pole CN i sprawdzają wyłącznie SAN. Jeśli w SAN nie ma Twojej domeny — w przeglądarce użytkownika pojawi się błąd "Your connection is not private", nawet jeśli CN jest poprawny. Minimum to dwie wartości: example.com i www.example.com.
Oznacza to, że CSR jest uszkodzony — np. był ręcznie edytowany, został ucięty podczas kopiowania, lub plik zawiera literówki. CA odrzuci taki CSR. Rozwiązanie: wygeneruj nowy CSR od zera (openssl req -new ...). Nie próbuj naprawiać CSR ręcznie — zawsze generuj na nowo, używając tego samego klucza prywatnego (jeśli chcesz zachować tożsamość).
Tak, mamy takie narzędzie: Generuj CSR online. Co ważne — generator działa wyłącznie w Twojej przeglądarce (JavaScript, biblioteka node-forge). Klucz prywatny nigdy nie trafia na nasz serwer. To bezpieczniejsza alternatywa niż wiele innych generatorów online, które działają po stronie serwera.
Nie — CSR nie ma daty ważności. Możesz go przechowywać latami i wykorzystywać wielokrotnie do re-issue certyfikatu (pod warunkiem że zachowałeś klucz prywatny). Jednak w praktyce dla każdego nowego certyfikatu warto generować świeży CSR — to zmniejsza ryzyko ujawnienia klucza prywatnego i pozwala na aktualizację algorytmu (np. migrację z RSA 2048 na RSA 3072 albo EC).
CSR nie zawiera klucza prywatnego, więc wklejenie go nam w pole tekstowe nie grozi utratą bezpieczeństwa. Mimo to traktujemy każdy plik z należytą uwagą:
openssl req -in csr.pem -text -noout pokazuje te same informacje lokalnie.
Niezbędne cookies są zawsze włączone. Dodatkowo używamy cookies analitycznych (Google Analytics) i marketingowych — ale tylko za Twoją zgodą. Szczegóły w Polityce cookies.