Dekoder CSR

Wklej żądanie podpisania certyfikatu i odczytaj każde pole, które zawiera: podmiot, klucz, każdą alternatywną nazwę i każde rozszerzenie. Strona sprawdza też żądanie pod kątem reguł stosowanych przez publiczny urząd certyfikacji i mówi ci, czy pasuje do niego twój klucz prywatny. Certyfikat SSL też tu zdekodujesz.

Dekodowane w twojej przeglądarce przez Web Crypto · nic nie jest wysyłane, nic nie jest zapisywane · Baseline Requirements CA/Browser Forum v2.3.1

Wszystko na tej stronie dzieje się w twojej przeglądarce. Otwórz panel sieci i patrz: żadne żądanie nie niesie twoich danych na żaden serwer.

Czym jest CSR?

Żądanie podpisania certyfikatu (CSR) to mały podpisany plik, którym prosisz urząd certyfikacji o certyfikat. Niesie twój klucz publiczny, nazwy, które chcesz mieć w certyfikacie, i podpis złożony twoim kluczem prywatnym.

Format to PKCS#10, opisany w RFC 2986. Podpisywana część zawiera tylko cztery rzeczy: numer wersji, nazwa podmiotu, SubjectPublicKeyInfo z twoim kluczem publicznym i zbiór atrybutów. Całość podpisuje klucz prywatny pasujący do klucza publicznego w środku, więc CSR jest podpisane samo przez siebie. Ten podpis to dowód posiadania: klucz publiczny może przeczytać każdy, ale żądanie, które się z nim zweryfikuje, podpisze tylko ten, kto ma klucz prywatny.

Twojego klucza prywatnego w pliku nie ma i nigdy nie powinno być. CSR możesz bezpiecznie wysłać e-mailem, wkleić w formularzu urzędu certyfikacji i zdekodować tutaj, dlatego ta strona może całą pracę wykonać w twojej przeglądarce, nic nigdzie nie wysyłając.

Jedno żądanie, bajt po bajcieRFC 2986 · PKCS#10

Cały plik

  • Opakowanie4 bajty
  • Część, która jest podpisywana469 bajtów
  • Jakim algorytmem podpis15 bajtów
  • Sam podpis261 bajtów

W środku części, która jest podpisywana

  1. Wersja3 bajtyZawsze zero: jedyna wersja, jaką definiuje format
  2. Nazwa podmiotu108 bajtówNazwa wyróżniająca, którą wpisałeś w formularzu
  3. Twój klucz publiczny294 bajtyAlgorytm, rozmiar i klucz: jedyne pole, którego urząd certyfikacji na pewno użyje
  4. Atrybuty60 bajtówTędy podróżują alternatywne nazwy, o które prosisz

Twój klucz prywatnypodpisuje część powyżejDowód, że masz pasujący klucz prywatny · Podpis obejmuje tylko tę część, nie cały plik

Przykładowe żądanie oferowane na tej stronie; rozmiar pliku: 749 bajtów. Do części podpisywanej trafiają cztery rzeczy; klucz prywatny pasujący do klucza publicznego w środku podpisuje dokładnie tę część, a wynik to ostatni fragment, o rozmiarze 261 bajtów.
Dekoder CSR: zdekodowane żądanie podpisania certyfikatu z podmiotem, kluczem, alternatywnymi nazwami i regułami urzęduDekoder CSR: zdekodowane żądanie podpisania certyfikatu z podmiotem, kluczem, alternatywnymi nazwami i regułami urzęduWklej lub upuśćCSR, certyfikat albo klucz publiczny: PEM, base64, zrzut szesnastkowy lub plik. Kilka naraz też może być.WerdyktCo publiczny urząd certyfikacji zrobi z tym żądaniem: wystawi je, zmieni albo odmówi, z powodem w każdym przypadku.NazwyKażda nazwa, którą obejmie certyfikat, z nazwą pospolitą sprawdzoną na ich tle.Klucz i podpisAlgorytm, rozmiar, krzywa i wykładnik oraz to, czy własny podpis żądania jest poprawny.Dopasowanie kluczaDodaj klucz prywatny albo wystawiony certyfikat, aby sprawdzić, czy pasuje do tego żądania. Żadne z nich nie opuszcza twojej przeglądarki.
Żądanie podpisania certyfikatu rozłożone na części: werdykt, nazwy, o które prosi, klucz za nim i miejsce na dopasowanie twojego własnego klucza. Wybierz numer, aby zobaczyć, co pokazuje dana część.

Jak sprawdzić CSR, zanim je wyślesz

Warto sprawdzić trzy rzeczy: czy nazwy są takie, jakie miałeś na myśli, czy podpis się weryfikuje i czy nic w żądaniu nie łamie reguły stosowanej przez twój urząd certyfikacji.

Wklej żądanie powyżej. Strona czyta podmiot atrybut po atrybucie, wylicza każdą alternatywną nazwę podmiotu, pokazuje algorytm i rozmiar klucza, a potem sprawdza własny podpis żądania. Żądanie, którego podpis się nie weryfikuje, zostało po utworzeniu zmienione, ucięte albo uszkodzone. Wygeneruj je jeszcze raz zamiast je wysyłać.

Potem przychodzą reguły. Urząd certyfikacji stosuje Baseline Requirements CA/Browser Forum, a żądanie, które łamie któreś z nich, zostaje odrzucone albo po cichu zmienione. Ustalenia na tej stronie są oznaczone jako odrzucenie, gdy urząd nie może wystawić tego, o co prosisz, jako poprawka, gdy wystawi certyfikat, ale usunie lub zmieni jakieś pole, i jako uwaga, gdy nic nie jest nie tak, ale warto rzucić okiem.

Trzy sprawdzenia, w kolejności, w jakiej działająCA/Browser Forum TLS BR 2.3.1
  1. NazwyKażda nazwa, którą obejmie certyfikat, i czy nazwa pospolita jest wśród nich
  2. PodpisWeryfikowany własną kryptografią twojej przeglądarki
  3. Reguły urzędu certyfikacjiStosowane po kolei, każda z dokumentem, z którego pochodzi
  • WyślijNic w żądaniu nie łamie reguły
  • Zostanie odrzuconePlik jest w porządku, ale to, o co prosi, jest niedozwolone
  • Utwórz jeszcze razPodpis, który się nie weryfikuje, oznacza, że plik został po utworzeniu zmieniony, ucięty albo źle skopiowany
Pierwsze dwa sprawdzenia dotyczą samego pliku, a trzecie tego, na co pozwala urząd certyfikacji. Żądanie może przejść oba pierwsze i mimo to zostać odrzucone.

Co jest w CSR i z czego naprawdę korzysta twój urząd certyfikacji

Ze wszystkiego, co jest w CSR, publiczny urząd certyfikacji niezawodnie używa jednego pola: klucza publicznego. Większość reszty sam waliduje, nadpisuje albo ma zakaz kopiowania.

DigiCert mówi to wprost we własnej dokumentacji: „DigiCert uses the public key embedded in the CSR to create your client certificate. All other fields in the CSR are ignored.” W certyfikacie OV lub EV urząd certyfikacji sam musi zweryfikować organizację, miejscowość i kraj, zanim trafią do certyfikatu; to, co wpisałeś, nie jest przyjmowane na słowo. Dat ważności nigdy nie bierze się z żądania: wynikają z harmonogramu Baseline Requirements.

Dwa pola podmiotu są nie tyle ignorowane, ile zakazane. organizationalUnitName (OU) nie może występować w publicznym certyfikacie TLS (zgodnie z uchwałą SC047 CA/Browser Forum żaden certyfikat wystawiony od 1 września 2022 roku nie może go zawierać), a emailAddress nie jest dozwolony w certyfikacie z walidacją domeny w ogóle. Nazwa pospolita jest dozwolona, ale odradzana, a jeśli jest, musi dokładnie powtarzać jedną z alternatywnych nazw podmiotu. Ta ostatnia reguła to powód, dla którego strona oznacza nazwę pospolitą, której brakuje na liście SAN.

Co urząd certyfikacji robi z każdym polemCA/Browser Forum TLS BR 2.3.1
W twoim żądaniuCo się z nim dziejeDlaczego
Klucz publicznySubjectPublicKeyInfoUżyte tak, jak je wysłałeśJedyna rzecz, którą urząd certyfikacji na pewno od ciebie weźmie
Alternatywne nazwysubjectAltName2.5.29.17Użyte tak, jak je wysłałeśUrząd potwierdza, że kontrolujesz każdą nazwę, zanim którąkolwiek zapisze
Nazwa pospolitaCN2.5.4.3Zwalidowane, potem zapisane przez urządOdradzana; jeśli jest, musi dokładnie powtarzać jedną z alternatywnych nazw
Organizacja, miejscowość, województwoO, L, ST2.5.4.10Zwalidowane, potem zapisane przez urządW certyfikacie z walidacją organizacji pochodzą z własnych zweryfikowanych rejestrów urzędu, a nie z tego, co wpisałeś
KrajC2.5.4.6Zwalidowane, potem zapisane przez urządMoże się pojawić, niezależnie od poziomu walidacji
Jednostka organizacyjnaOU2.5.4.11Zupełnie niedozwoloneZakazane w publicznym certyfikacie od 1 września 2022
Adres e-mailemailAddress1.2.840.113549.1.9.1Zupełnie niedozwoloneNiedozwolony w certyfikacie z walidacją domeny
Ważne od, ważne donotBefore, notAfterNigdy nie pochodzi z żądaniaUstalana przez harmonogram, którego trzyma się urząd certyfikacji, nigdy przez twoje żądanie

„DigiCert uses the public key embedded in the CSR to create your client certificate. All other fields in the CSR are ignored.”

DigiCert, jego własna dokumentacja
Pola, nad którymi ludzie się zamartwiają, i ile każde naprawdę jest warte. Twój klucz i twoje nazwy przeżywają; jednostki organizacyjnej w ogóle nie może być, a adresu e-mail w certyfikacie z walidacją domeny też, cokolwiek wpiszesz; a dat nigdy nie ustalałeś ty.

Dlaczego urząd certyfikacji odrzuca CSR

Prawie każde odrzucenie sprowadza się do nazwy, której urząd nie może poświadczyć, zbyt szerokiego wildcarda, zarezerwowanego adresu IP, za małego klucza, zbyt starego hasha podpisu albo żądania, którego podpis się nie weryfikuje.

Urząd certyfikacji nie może wystawić certyfikatu dla nazwy wewnętrznej, czyli takiej, która „does not end with a Top-Level Domain registered in IANA's Root Zone Database”. To obejmuje server.local, intranet, nazwę jednoczłonową bez kropki i każdy wymyślony sufiks. Człony mogą zawierać litery, cyfry i myślniki, więc podkreślnik w nazwie hosta jest odrzucany, a nazwy nie wolno zapisywać z kropką na końcu. Wildcard może zastąpić tylko cały lewy człon i nigdy publiczny sufiks: *.example.com jest w porządku, *.co.uk nie. Adres IP może się pojawić, ale nie zarezerwowany: żadne 10.0.0.0/8, 192.168.0.0/16, 127.0.0.1 ani fc00::/7.

Przy kluczach Baseline Requirements są precyzyjne: moduł RSA o długości co najmniej 2048 bitów, podzielnej przez 8, albo punkt na krzywej P-256, P-384 lub P-521, a „no other algorithms or key sizes are permitted”. Urząd musi też odrzucić klucz, który potrafi rozłożyć na czynniki, w tym taki, „which can be factored within 100 rounds using Fermat's factorization method”: ta strona wykonuje ten test na kluczu z twojego żądania. A choć hash własnego podpisu CSR to nie hash certyfikatu, Let's Encrypt przestał w 2022 roku przyjmować samopodpisy SHA-1, więc stare narzędzie, które nadal podpisuje SHA-1, zobaczy swoje żądanie odrzucone.

Nazwy, których urząd certyfikacji nie poświadczyCA/Browser Forum TLS BR 2.3.1
  • server.local
    Nazwa wewnętrznaNie kończy się domeną najwyższego poziomu istniejącą w publicznej strefie głównej, więc nikt nie udowodni, że jest twoja
    Odrzucone
  • intranet
    Nazwa jednoczłonowaNazwa bez żadnej kropki podlega tej samej definicji
    Odrzucone
  • my_host.example.com
    PodkreślnikCzłon może zawierać litery, cyfry i myślniki, i nic więcej
    Odrzucone
  • *.co.uk
    Wildcard nad całym rejestremWildcard może zastąpić lewy człon, nigdy publiczny sufiks
    Odrzucone
  • 192.168.1.10
    Adres zarezerwowanyAdres publiczny można poświadczyć; adresu z zakresu prywatnego lub specjalnego nigdy
    Odrzucone
  • example.com.
    Kropka na końcuPustego członu głównego nie wolno zapisywać
    Odrzucone
Sześć nazw, z których każda łamie inną regułę — i każde z tych odrzuceń mogłeś zobaczyć, zanim wysłałeś żądanie.

Skąd wiem, że mój klucz prywatny pasuje do CSR?

Plik klucza prywatnego już niesie własny klucz publiczny, więc dopasowanie to porównanie dwóch kluczy publicznych: żaden sekret nie jest potrzebny i nic nie trzeba nigdzie wysyłać.

Otwórz powyżej Dopasuj klucz lub certyfikat i dodaj klucz obok żądania. Strona czyta z pliku tylko połowę publiczną (klucze PKCS#8, PKCS#1 i SEC1 są rozumiane), porównuje ją z kluczem w żądaniu i odpowiada. Nic nie jest wysyłane, nic nie jest zachowywane, a klucz jest czyszczony, gdy opuścisz pole. To samo sprawdzenie działa między żądaniem a certyfikatem, który wrócił z urzędu, dzięki czemu wychwytuje komunikat „certyfikat i klucz prywatny nie pasują”, zanim serwer odmówi uruchomienia.

Jeśli wolisz nie wklejać klucza w żadną stronę, ta sama odpowiedź to dwa polecenia na twoim komputerze. openssl req -in request.csr -pubkey -noout drukuje klucz publiczny z żądania, a openssl pkey -in private.key -pubout drukuje go z klucza: identyczny wynik oznacza, że pasują. Starsza forma z -modulus działa tylko dla kluczy RSA, a -pubkey działa dla każdego typu klucza.

Dwa pliki, jedno porównanieRFC 2986 · OpenSSL manual
Twoja przeglądarka
  • Plik klucza prywatnegoPlik, którego nigdy nie wolno nigdzie wysyłaćJego część publiczna zostaje odczytana
  • ŻądaniePlik, który wysyłasz do urzędu certyfikacjiJuż niesie klucz publiczny

Czy to ten sam klucz?

  • PasująCertyfikat, który wróci, da się zainstalować z tym kluczem
  • Nie pasująTo niedopasowanie, o którym informuje serwer WWW, gdy odmawia uruchomienia

Nic nie przekracza tej linii · Porównanie działa przy wyłączonej sieciGdziekolwiek indziej

Albo zrób to na własnym komputerzeopenssl req -in request.csr -pubkey -nooutopenssl pkey -in private.key -puboutIdentyczny wynik oznacza, że pasują
Plik klucza prywatnego już niesie własny klucz publiczny, więc sprawę rozstrzyga porównanie dwóch kluczy publicznych. Żaden sekret nie musi się w tym celu przemieszczać i nie przemieszcza się.

CSR, certyfikat, klucz prywatny: jaka jest różnica?

Klucz prywatny jest sekretem. CSR to żądanie, które dowodzi, że go masz. Certyfikat to podpisana odpowiedź urzędu i jedyny z tych trzech, który z założenia jest publiczny.

Te trzy pliki często leżą w tym samym katalogu pod mylnie podobnymi nazwami. Klucz prywatny zaczyna się od -----BEGIN PRIVATE KEY----- lub -----BEGIN RSA PRIVATE KEY----- i nie wolno go nikomu wysyłać, także urzędowi certyfikacji. Żądanie podpisania certyfikatu zaczyna się od -----BEGIN CERTIFICATE REQUEST-----, jest podpisane tym kluczem i można je bezpiecznie wysłać. Certyfikat zaczyna się od -----BEGIN CERTIFICATE-----, jest podpisany przez urząd i i tak trafia do każdego odwiedzającego twoją stronę.

Gdy certyfikat zostanie wystawiony, żądanie przestaje być potrzebne: nie służy do instalacji, odnowienia ani unieważnienia niczego. To klucz musisz zachować i dobrze strzec. Wklej dowolny z tych trzech plików powyżej, a ta strona powie ci, który to.

Trzy pliki, jeden katalog, mylnie podobne nazwyRFC 7468
  • Klucz prywatnySekret

    Jego pierwsza linia-----BEGIN PRIVATE KEY-----Także w szerokim użyciu-----BEGIN RSA PRIVATE KEY-----

    Podpisane przez
    Nic: to on podpisuje
    Kto może to zobaczyć
    Ty i nikt więcej
    Do czego służy
    Dowodzi, że ten serwer jest tym, któremu wystawiono certyfikat
  • Żądanie podpisania certyfikatuPubliczne

    Jego pierwsza linia-----BEGIN CERTIFICATE REQUEST-----Także w szerokim użyciu-----BEGIN NEW CERTIFICATE REQUEST-----

    Podpisane przez
    Samo siebie, kluczem prywatnym
    Kto może to zobaczyć
    Ty i urząd certyfikacji
    Do czego służy
    Prosi o certyfikat i dowodzi, że masz klucz, do którego ma być
  • CertyfikatPubliczne

    Jego pierwsza linia-----BEGIN CERTIFICATE-----

    Podpisane przez
    Urząd certyfikacji
    Kto może to zobaczyć
    Każdy odwiedzający twoją stronę
    Do czego służy
    Mówi przeglądarce, że ten klucz należy do tych nazw

.csr.pem.req.txtŻaden standard nie przypisuje żądaniu rozszerzenia pliku; wszystkie te są w użyciu, a ta strona czyta zawartość, a nie nazwę

Tylko pierwszy z tych trzech jest sekretem. Ostatni i tak trafia do każdego odwiedzającego, a środkowy przestaje być do czegokolwiek potrzebny w chwili, gdy przyjdzie certyfikat.

Czy dekodowanie CSR online jest bezpieczne?

CSR nie zawiera sekretu, więc zdekodowanie go gdziekolwiek jest nieszkodliwe. Klucz prywatny to co innego, a właśnie ten plik ludzie z nim mylą.

Wszystko na tej stronie dzieje się w twojej przeglądarce. Żądanie jest parsowane przez kod pobrany razem ze stroną, podpis sprawdza własny Web Crypto twojej przeglądarki i żadne zapytanie z twoimi danymi nie trafia na żaden serwer: możesz obserwować panel sieci, gdy z niej korzystasz. To cecha budowy strony, a nie obietnica, którą masz przyjąć na wiarę.

Ma to znaczenie z powodu pliku obok CSR. Definicja samego CA/Browser Forum jest bezlitosna: „A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, or an unauthorized person has had access to it.” Nie trzeba żadnego nadużycia: wystarczy, że klucz dotarł na cudzy serwer. W 2020 roku DigiCert znalazł 337 kluczy prywatnych, które klienci wkleili razem z CSR, i unieważnił wszystkie związane z nimi certyfikaty, pisząc, że „by sending the private key to DigiCert along with the CSR, the customer has compromised the private key”. Jeśli ta strona kiedykolwiek odczyta wklejony przez ciebie klucz prywatny, powie o tym, odmówi jego dekodowania i niczego z niego nie zachowa.

Dokąd naprawdę trafia plikCA/Browser Forum TLS BR 2.3.1

Ta strona

Twoja przeglądarka
  1. Plik jest czytany
  2. Rozbiera go kod, który przyszedł ze stroną
  3. Podpis sprawdza sama przeglądarka
  4. Wynik jest rysowany

Żadne zapytanie nie wychodzi z twoimi danymiOtwórz panel sieci i obserwuj, gdy z niej korzystasz

Strona, która go wysyła

Twoja przeglądarka

Plik jest wysyłany…razem z tym, co wklejono obok

Cudzy serwer

Klucz prywatny, który tam trafi, jest przez to samo skompromitowany

„A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, or an unauthorized person has had access to it.”

definicja, którą urzędy certyfikacji napisały dla samych siebie

To już się zdarzyłoW 2020 r. pewien urząd certyfikacji znalazł 337 kluczy prywatnych wklejonych obok żądaniaKażdy związany z tym certyfikat został unieważniony

Nic w żądaniu nie jest sekretem, więc zdekodowanie go gdziekolwiek jest nieszkodliwe. Plik, z którym ludzie je mylą, to co innego, a szkoda nie wymaga żadnego nadużycia: wystarczy, że ktoś go zobaczył.

RSA czy ECDSA: o jaki klucz prosić w CSR?

Klucz ECDSA P-256 jest tak samo mocny jak RSA 3072 bity, a dużo mniejszy, więc to lepszy wybór domyślny. RSA 2048 pozostaje akceptowany wszędzie.

NIST stawia P-256 i RSA-3072 na tym samym poziomie 128 bitów bezpieczeństwa, a jego tabela w ogóle nie ma wiersza dla RSA-4096: następny wiersz to RSA-7680 przy 192 bitach, czyli poziomie, który osiąga P-384. Klucz RSA 4096 bitów kosztuje więc każdego odwiedzającego dodatkową pracę przy handshake, bez udokumentowanego zysku w porównaniu z 3072. Baseline Requirements dopuszczają też P-521, ale Let's Encrypt go odrzuca, więc żądanie z P-521 może być w pełni zgodne z regułami i mimo to nie przejść w urzędzie, którego chciałeś użyć.

Ed25519 nie jest dziś opcją dla publicznego certyfikatu TLS, choć algorytm jest dobry: Baseline Requirements wymieniają RSA i trzy krzywe NIST i dodają „no other algorithms or key sizes are permitted”. Klucz postkwantowy też nie: uchwała, która dopuściłaby ML-DSA w publicznym TLS, została w październiku 2026 zamknięta bez wdrożenia. Ed25519 i ML-DSA nadal przydają się do SSH, do podpisywania i w prywatnym urzędzie certyfikacji, a ta strona czyta żądania, które ich używają.

Ta sama siła, w dwóch bardzo różnych rozmiarachNIST SP 800-57 Part 1 Rev 5, Table 2
SiłaKlucz RSAKrzywa
112 bitów bezpieczeństwa2048 bitówDowolny publiczny urządŻadna krzywa dozwolona przez publiczny urząd certyfikacji nie leży na tym poziomie siły
128 bitów bezpieczeństwa3072 bityDowolny publiczny urządP-256Dowolny publiczny urząd
4096 bitówDowolny publiczny urząd4096 bitów w ogóle nie ma w tabeli
192 bity bezpieczeństwa7680 bitówDowolny publiczny urządP-384Dowolny publiczny urząd
256 bitów bezpieczeństwa15 360 bitówDowolny publiczny urządP-521Dowolny publiczny urząd
  • Klucz RSA
  • Krzywa
  • Stopnie przechodzą prosto od jednego rozmiaru do następnego i pomijają popularny, który leży pomiędzy, więc dodatkowa praca przy handshake, jaką ponosi każdy odwiedzający, nie kupuje niczego, co ktokolwiek by opisał
  • Akceptowane przezLet's Encrypt

Krzywa niesie tę samą siłę w ułamku bajtów

Opublikowane porównanie, z dwiema rzeczami, które decydują, czy naprawdę możesz użyć klucza: na co pozwalają reguły i na co pozwala urząd certyfikacji, którego chciałeś użyć.

Jak utworzyć CSR na dowolnej platformie

Jedno polecenie OpenSSL obejmuje Linuksa, macOS i Windows z zainstalowanym OpenSSL. IIS ma certreq, macOS ma Dostęp do kluczy (Keychain Access), a ta strona ma generator, który nigdy nie wysyła twojego klucza.

W OpenSSL polecenie openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com" tworzy klucz i żądanie jednym krokiem. (-nodes zostawia klucz niezaszyfrowany. OpenSSL 3 zapisuje to też jako -noenc, ale LibreSSL wbudowany w macOS zna tylko -nodes.) Potem openssl req -in example.com.csr -text -verify -noout pokazuje je i weryfikuje. W Windows certreq -new request.inf request.req czyta plik .inf, w którym alternatywne nazwy trafiają pod OID 2.5.29.17 w liniach _continue_: klucza SAN= tam nie ma. Własna strona referencyjna Microsoftu ostrzega, że jej przykład używa SHA-1, który urząd certyfikacji dziś odrzuci, więc ustaw hash samodzielnie.

Na Macu Keychain Access > Certificate Assistant > Request a Certificate From a Certificate Authority zapisuje takie żądanie, a rozmiar klucza kryje się za polem „Let me specify key pair information”. Możesz też użyć naszego generatora CSR, który tworzy klucz przez Web Crypto twojej przeglądarki i oddaje oba pliki bez przechodzenia przez serwer. Żaden standard nie przypisuje CSR rozszerzenia pliku: używa się .csr, .pem, .req i .txt, a ta strona czyta zawartość, a nie ufa nazwie.

Cztery sposoby, by je utworzyćOpenSSL · Microsoft Learn · Apple Support
  1. OpenSSLLinux, macOS, Windows

    Tworzy klucz i żądanie jednym poleceniemopenssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com"Potem odczytaj je i zweryfikuj jego własny podpisopenssl req -in example.com.csr -text -verify -noout
  2. certreqWindows Server i IIS

    Czyta zwykły plik tekstowy; alternatywne nazwy idą w sekcji rozszerzeń, po jednej w liniicertreq -new request.inf request.req[Extensions] 2.5.29.17 = "{text}" _continue_ = "DNS=example.com&" _continue_ = "DNS=www.example.com"Własna strona z przykładem Microsoftu jest nadal napisana wokół hasha, który urząd certyfikacji dziś odrzuca, więc ustaw hash samodzielnie
  3. Keychain AccessmacOS

    Keychain Access › Certificate Assistant › Request a Certificate From a Certificate AuthorityTwój Mac nazywa te menu w swoim własnym językuTyp i rozmiar klucza kryją się za polem, które pozwala określić parę kluczyKlucze RSA od 2048 do 4096 bitów; mniejsze nie są już oferowane
  4. DNS RobotDowolna przeglądarka

    Tworzy klucz własną kryptografią przeglądarki i oddaje oba pliki bez przechodzenia którejkolwiek przez serwerOtwórz generator
Jedno polecenie OpenSSL działa tak samo w Linuksie, macOS-ie i Windowsie. Pozostałe trzy sposoby są dla maszyn, na których nie masz go pod ręką.

Jak długo będzie ważny certyfikat?

Publiczny certyfikat TLS wystawiony dziś nie może przekraczać 200 dni. W marcu 2027 spada to do 100 dni, a w marcu 2029 do 47 dni.

Harmonogram wynika z uchwały SC-081v3 CA/Browser Forum, przyjętej w kwietniu 2025, i CSR nie może na niego wpłynąć: ważność nigdy nie pochodzi z żądania. Każdy stopień ma dwie liczby, wartość „SHOULD NOT” o jeden dzień niższą od „MUST NOT”: dziś 199 i 200, od 2027-03-15 99 i 100, od 2029-03-15 46 i 47. Przy liczeniu „a day is measured as 86,400 seconds”, a każda rozpoczęta część kolejnego dnia liczy się jako cały dzień.

Praktyczny wniosek: odnawianie musi być automatyczne. Jeśli nadal co roku tworzysz CSR ręcznie, to dobry moment, by przejść na ACME, gdzie żądanie tworzy za ciebie klient i gdzie, nawiasem mówiąc, PKCS#10 jest rzeczywiście wymagany, choć same Baseline Requirements wymagają tylko „a certificate request in a form prescribed by the CA”.

Jak długo może być ważny certyfikatCA/Browser Forum TLS BR 2.3.1 §6.3.2
  1. przed 15 marca 2026Gdzie jest dziś397 dni398 dni
  2. od 15 marca 2026199 dni200 dni
  3. od 15 marca 202799 dni100 dni
  4. od 15 marca 202946 dni47 dni
  • Cały harmonogram pochodzi z jednej uchwały, SC-081v3, przyjętej: 11 kwietnia 2025
  • Dzień liczy się jako dokładnie 86 400 sekund a każda rozpoczęta część kolejnego dnia liczy się jako cały dzień
  • Nic w żądaniu niczego z tego nie zmienia
Cztery stopnie, każdy z dwiema liczbami: tą, którą reguły odradzają, i tą, którą zakazują. Daty są już ustalone, co czyni automatyczne odnawianie jedyną sensowną odpowiedzią.

Co pokazuje surowe ASN.1

Pod base64 CSR to drzewo zakodowane w DER. Dekoder rysuje je z przesunięciami w bajtach i nazywa każdy znany identyfikator obiektu, czyli to, co drukuje openssl asn1parse.

To uczciwy sposób na pokazanie pola, dla którego nikt nie ma przyjaznej nazwy. Otwórz Surowa struktura przy dowolnym zdekodowanym elemencie, a zobaczysz CertificationRequestInfo, względne nazwy wyróżniające podmiotu jedna po drugiej, SubjectPublicKeyInfo, zbiór attributes [0] i w nim atrybut extensionRequest, czyli identyfikator obiektu 1.2.840.113549.1.9.14, zdefiniowany nie w RFC 2986, lecz w RFC 2985 §5.4.2, niosący właśnie te rozszerzenia X.509 z RFC 5280.

Drugi atrybut, na który możesz tam trafić, to challengePassword (1.2.840.113549.1.9.7). Miał być wspólnym sekretem do późniejszego unieważnienia certyfikatu, nadal jest używany przy rejestracji SCEP i nie odgrywa roli w zwykłym zamówieniu certyfikatu WWW. Ta strona pokazuje go, gdy jest, bo pola, którego nie widzisz, nie sprawdzisz.

To samo żądanie, jako bajtyRFC 2986 · RFC 2985 · RFC 5280
Od bajtuStrukturaRozmiar
0SEQUENCE749 bajtów
4SEQUENCE469 bajtów
8INTEGER03 bajty
11SEQUENCE108 bajtów
13SET13 bajtów
15SEQUENCE11 bajtów
17OBJECT IDENTIFIERC2.5.4.65 bajtów
22PrintableStringUS4 bajty
26SET21 bajtów
28SEQUENCE19 bajtów
30OBJECT IDENTIFIERST2.5.4.85 bajtów
35UTF8StringCalifornia12 bajtów
47SET24 bajty
49SEQUENCE22 bajty
51OBJECT IDENTIFIERL2.5.4.75 bajtów
56UTF8StringSan Francisco15 bajtów
71SET22 bajty
73SEQUENCE20 bajtów
75OBJECT IDENTIFIERO2.5.4.105 bajtów
80UTF8StringExample Inc13 bajtów
93SET26 bajtów
95SEQUENCE24 bajty
97OBJECT IDENTIFIERCN2.5.4.35 bajtów
102UTF8Stringwww.example.com17 bajtów
119SEQUENCE294 bajty
123SEQUENCE15 bajtów
125OBJECT IDENTIFIERrsaEncryption1.2.840.113549.1.1.111 bajtów
136NULL2 bajty
138BIT STRING2160 bitów30 82 01 0a 02 82 01 01 00 c5 47 47 1d 26 1c bf275 bajtów
413[0]60 bajtów
415SEQUENCE58 bajtów
417OBJECT IDENTIFIERextensionRequest1.2.840.113549.1.9.1411 bajtów
428SET45 bajtów
430SEQUENCE43 bajty
432SEQUENCE41 bajtów
434OBJECT IDENTIFIERSubject Alternative Name2.5.29.175 bajtów
439OCTET STRING32 bajty30 1e 82 0f 77 77 77 2e 65 78 61 6d 70 6c 65 2e34 bajty
473SEQUENCE15 bajtów
475OBJECT IDENTIFIERsha256WithRSAEncryption1.2.840.113549.1.1.1111 bajtów
486NULL2 bajty
488BIT STRING2048 bitów00 57 41 c5 09 98 14 78 8c ee c3 61 d4 c0 e0 2d261 bajtów
  • Zawiera inne rzeczy
  • Zawiera wartość
  • Nazwane przez swoje położenie
  • Atrybut, który niesie rozszerzenia

    1.2.840.113549.1.9.14Jest zdefiniowany w innym dokumencie niż ten, który definiuje samo żądanie, dlatego alternatywne nazwy podróżują wewnątrz atrybutu, a nie leżą obok podmiotu
  • Drugi atrybut, na który możesz trafićNie ma go w tym żądaniu

    1.2.840.113549.1.9.7Wspólny sekret, przeznaczony do późniejszej prośby o unieważnienie certyfikatu, nadal używany, gdy urządzenie rejestruje się w sieci
Każdy bajt przykładowego żądania, z nazwanym każdym identyfikatorem obiektu. To właśnie drukuje dekoder wiersza poleceń, tylko narysowane zamiast wydrukowane, byś widział, gdzie kończy się jedno pole, a zaczyna następne.

Dekoder CSR: pytania i odpowiedzi

Jak zdekodować CSR?

Wklej całe żądanie do pola powyżej, razem z liniami -----BEGIN CERTIFICATE REQUEST----- i -----END CERTIFICATE REQUEST-----, albo upuść plik na stronę. Dekoduje się w trakcie wklejania: podmiot, klucz publiczny, każda alternatywna nazwa podmiotu, każde żądane rozszerzenie i odciski. Możesz też wkleić samą treść base64, zrzut szesnastkowy albo wysłać binarny plik DER.

Czy ten dekoder CSR jest bezpieczny?

Tak, z dwóch powodów. Żądanie podpisania certyfikatu nie zawiera sekretu, bo ma być wysłane do urzędu certyfikacji, więc zdekodowanie go gdziekolwiek jest nieszkodliwe. A ta strona pracuje w twojej przeglądarce: żądanie jest parsowane przez kod pobrany razem ze stroną i nic nie trafia na żaden serwer. Jeśli przez pomyłkę wkleisz klucz prywatny, strona ci o tym powie, odmówi jego dekodowania i niczego z niego nie zachowa.

Jak sprawdzić, czy moje CSR jest poprawne?

Zdekoduj je tutaj i przeczytaj werdykt. Strona sprawdza własny podpis żądania, który dowodzi, że nadawca ma pasujący klucz prywatny, a potem stosuje reguły publicznego urzędu certyfikacji: nazwy, których nie może poświadczyć, zbyt szerokie wildcardy, zarezerwowane adresy IP, za małe lub faktoryzowalne klucze, przestarzałe pola podmiotu i stare hashe podpisu. Każde ustalenie mówi, czy urząd je odrzuci, zmieni, czy tylko odnotuje.

Dlaczego mój urząd certyfikacji odrzuca moje CSR?

Typowe przyczyny to nazwa wewnętrzna, jak server.local, albo jednoczłonowa nazwa hosta, podkreślnik w nazwie hosta, wildcard nad publicznym sufiksem, jak *.co.uk, prywatny adres IP wśród alternatywnych nazw, klucz RSA poniżej 2048 bitów albo żądanie nadal podpisane SHA-1. Zdekoduj żądanie powyżej, a każda z tych rzeczy zostanie nazwana wprost, razem z regułą, którą łamie.

Skąd wiem, że mój klucz prywatny pasuje do CSR?

Użyj powyżej Dopasuj klucz lub certyfikat: dodaj klucz obok żądania, a strona porówna klucz publiczny z pliku klucza z tym w żądaniu, w twojej przeglądarce. Możesz też zrobić to sam: openssl req -in request.csr -pubkey -noout i openssl pkey -in private.key -pubout drukują ten sam klucz publiczny, gdy pasują. To samo porównanie działa między kluczem a wystawionym certyfikatem.

Czy to zdekoduje też certyfikat SSL?

Tak. Wklej certyfikat, a zostanie zdekodowany jako certyfikat: wystawca i podmiot, numer seryjny, daty ważności, każda alternatywna nazwa, użycie klucza i rozszerzone użycie klucza, identyfikatory klucza urzędu i podmiotu, adresy OCSP i CA Issuers, polityki certyfikatu i wbudowane znaczniki czasu Certificate Transparency. Wklej certyfikat razem z jego żądaniem, a strona powie też, czy mają wspólny klucz.

Jakich pól z mojego CSR urząd certyfikacji naprawdę używa?

Niezawodnie jednego: klucza publicznego. Dokumentacja DigiCert mówi, że reszta jest ignorowana. W certyfikacie OV lub EV urząd certyfikacji sam musi zweryfikować organizację i kraj, zanim trafią do certyfikatu, a daty ważności zawsze z harmonogramu Baseline Requirements, nigdy z żądania. Dwa pola są nie tyle ignorowane, ile zakazane w publicznym certyfikacie TLS: OU i, w certyfikatach z walidacją domeny, emailAddress.

Czy nazwa pospolita nadal ma znaczenie?

Tylko jako kopia czegoś innego. Od 2017 roku przeglądarki ignorują nazwę pospolitą przy dopasowaniu hosta i używają samych alternatywnych nazw podmiotu. Baseline Requirements oznaczają nazwę pospolitą jako NOT RECOMMENDED i wymagają, by, jeśli jest, „MUST contain exactly one entry that is one of the values contained in the Certificate's subjectAltName extension”. Nazwa pospolita spoza twoich alternatywnych nazw to odrzucenie, a ta strona to oznacza.

Czy mogę zdekodować kilka plików naraz?

Tak. Wklej żądanie, jego certyfikat i certyfikaty pośrednie razem, a każdy blok zostanie zdekodowany na własnej karcie, w kolejności wklejenia. Jeden uszkodzony blok nie zatrzymuje pozostałych. Jeśli gdzieś we wklejonym tekście jest klucz prywatny, zostaje nazwany i pominięty, nigdy nie jest dekodowany. Dekodowanych jest do czterdziestu bloków, a wszystko ponad to jest policzone i zgłoszone, a nie po cichu pominięte.

Czym jest challenge password w CSR?

To opcjonalny atrybut z RFC 2985, pierwotnie wspólny sekret, który podawało się przy prośbie o unieważnienie certyfikatu. Nadal ma rolę przy rejestracji SCEP, gdzie urządzenie dowodzi, że może o coś prosić. Nie odgrywa roli w zwykłym zamówieniu certyfikatu WWW, a ponieważ mało które narzędzie to pole pokazuje, ta strona wyświetla je zawsze, gdy żądanie je niesie.

Czy mogę użyć klucza Ed25519 w certyfikacie publicznym?

Dziś nie. Baseline Requirements dopuszczają RSA oraz krzywe P-256, P-384 i P-521, a potem stwierdzają, że „no other algorithms or key sizes are permitted”, więc żaden publiczny urząd certyfikacji nie wystawi certyfikatu na żądanie z Ed25519. To dobry klucz do SSH, podpisywania i prywatnego urzędu certyfikacji, a ten dekoder czyta bez problemu żądania z Ed25519 i Ed448 oraz klucze postkwantowe ML-DSA.

Jak długo certyfikat jest dziś ważny?

Publiczny certyfikat TLS wystawiony dziś nie może przekraczać 200 dni, a przed 2026-03-15 było to 398. Spada do 100 dni 2027-03-15 i do 47 dni 2029-03-15, na mocy uchwały SC-081v3 CA/Browser Forum. Nic w CSR na to nie wpływa; ważność ustala urząd. Przy takich długościach odnawianie musi być zautomatyzowane, co w praktyce oznacza ACME.

Czegoś brakuje?Zaproponuj funkcję lub nowe narzędzie