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. Nic nie jest wysyłane, nic nie jest zapisywane.
Upuść plik w dowolnym miejscu tej strony PEM, DER, .csr, .cer, .crt, .pem, .req, .txt
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.
- Opakowanie4 bajty
- Część, która jest podpisywana469 bajtów
- Jakim algorytmem podpis15 bajtów
- Sam podpis261 bajtów
- Wersja3 bajtyZawsze zero: jedyna wersja, jaką definiuje format
- Nazwa podmiotu108 bajtówNazwa wyróżniająca, którą wpisałeś w formularzu
- Twój klucz publiczny294 bajtyAlgorytm, rozmiar i klucz: jedyne pole, którego urząd certyfikacji na pewno użyje
- 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

Wklej 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.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.
- NazwyKażda nazwa, którą obejmie certyfikat, i czy nazwa pospolita jest wśród nich
- PodpisWeryfikowany własną kryptografią twojej przeglądarki
- 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
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.
| W twoim żądaniu | Co się z nim dzieje | Dlaczego |
|---|---|---|
| Klucz publicznySubjectPublicKeyInfo | Użyte tak, jak je wysłałeś | Jedyna rzecz, którą urząd certyfikacji na pewno od ciebie weźmie |
| Alternatywne nazwysubjectAltName2.5.29.17 | Użyte tak, jak je wysłałeś | Urząd potwierdza, że kontrolujesz każdą nazwę, zanim którąkolwiek zapisze |
| Nazwa pospolitaCN2.5.4.3 | Zwalidowane, potem zapisane przez urząd | Odradzana; jeśli jest, musi dokładnie powtarzać jedną z alternatywnych nazw |
| Organizacja, miejscowość, województwoO, L, ST2.5.4.10 | Zwalidowane, potem zapisane przez urząd | W certyfikacie z walidacją organizacji pochodzą z własnych zweryfikowanych rejestrów urzędu, a nie z tego, co wpisałeś |
| KrajC2.5.4.6 | Zwalidowane, potem zapisane przez urząd | Może się pojawić, niezależnie od poziomu walidacji |
| Jednostka organizacyjnaOU2.5.4.11 | Zupełnie niedozwolone | Zakazane w publicznym certyfikacie od 1 września 2022 |
| Adres e-mailemailAddress1.2.840.113549.1.9.1 | Zupełnie niedozwolone | Niedozwolony w certyfikacie z walidacją domeny |
| Ważne od, ważne donotBefore, notAfter | Nigdy nie pochodzi z żądania | Ustalana 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.”
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.
server.localNazwa wewnętrznaNie kończy się domeną najwyższego poziomu istniejącą w publicznej strefie głównej, więc nikt nie udowodni, że jest twojaOdrzuconeintranetNazwa jednoczłonowaNazwa bez żadnej kropki podlega tej samej definicjiOdrzuconemy_host.example.comPodkreślnikCzłon może zawierać litery, cyfry i myślniki, i nic więcejOdrzucone*.co.ukWildcard nad całym rejestremWildcard może zastąpić lewy człon, nigdy publiczny sufiksOdrzucone192.168.1.10Adres zarezerwowanyAdres publiczny można poświadczyć; adresu z zakresu prywatnego lub specjalnego nigdyOdrzuconeexample.com.Kropka na końcuPustego członu głównego nie wolno zapisywaćOdrzucone
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.
- 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
openssl req -in request.csr -pubkey -nooutopenssl pkey -in private.key -puboutIdentyczny wynik oznacza, że pasują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.
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ę
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.
Ta strona
- Plik jest czytany
- Rozbiera go kod, który przyszedł ze stroną
- Podpis sprawdza sama przeglądarka
- 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
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.”
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
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ą.
| Siła | Klucz RSA | Krzywa |
|---|---|---|
| 112 bitów bezpieczeństwa | 2048 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ństwa | 3072 bityDowolny publiczny urząd | P-256Dowolny publiczny urząd |
| 4096 bitówDowolny publiczny urząd4096 bitów w ogóle nie ma w tabeli | ||
| 192 bity bezpieczeństwa | 7680 bitówDowolny publiczny urząd | P-384Dowolny publiczny urząd |
| 256 bitów bezpieczeństwa | 15 360 bitówDowolny publiczny urząd | P-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
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.
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 -nooutcertreqWindows 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 samodzielnieKeychain 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ż oferowaneDNS RobotDowolna przeglądarka
Tworzy klucz własną kryptografią przeglądarki i oddaje oba pliki bez przechodzenia którejkolwiek przez serwerOtwórz generator
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”.
- przed 15 marca 2026Gdzie jest dziś397 dni398 dni
- od 15 marca 2026199 dni200 dni
- od 15 marca 202799 dni100 dni
- 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
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.
| Od bajtu | Struktura | Rozmiar |
|---|---|---|
| 0 | SEQUENCE | 749 bajtów |
| 4 | SEQUENCE | 469 bajtów |
| 8 | INTEGER0 | 3 bajty |
| 11 | SEQUENCE | 108 bajtów |
| 13 | SET | 13 bajtów |
| 15 | SEQUENCE | 11 bajtów |
| 17 | OBJECT IDENTIFIERC2.5.4.6 | 5 bajtów |
| 22 | PrintableStringUS | 4 bajty |
| 26 | SET | 21 bajtów |
| 28 | SEQUENCE | 19 bajtów |
| 30 | OBJECT IDENTIFIERST2.5.4.8 | 5 bajtów |
| 35 | UTF8StringCalifornia | 12 bajtów |
| 47 | SET | 24 bajty |
| 49 | SEQUENCE | 22 bajty |
| 51 | OBJECT IDENTIFIERL2.5.4.7 | 5 bajtów |
| 56 | UTF8StringSan Francisco | 15 bajtów |
| 71 | SET | 22 bajty |
| 73 | SEQUENCE | 20 bajtów |
| 75 | OBJECT IDENTIFIERO2.5.4.10 | 5 bajtów |
| 80 | UTF8StringExample Inc | 13 bajtów |
| 93 | SET | 26 bajtów |
| 95 | SEQUENCE | 24 bajty |
| 97 | OBJECT IDENTIFIERCN2.5.4.3 | 5 bajtów |
| 102 | UTF8Stringwww.example.com | 17 bajtów |
| 119 | SEQUENCE | 294 bajty |
| 123 | SEQUENCE | 15 bajtów |
| 125 | OBJECT IDENTIFIERrsaEncryption1.2.840.113549.1.1.1 | 11 bajtów |
| 136 | NULL | 2 bajty |
| 138 | BIT STRING2160 bitów30 82 01 0a 02 82 01 01 00 c5 47 47 1d 26 1c bf | 275 bajtów |
| 413 | [0] | 60 bajtów |
| 415 | SEQUENCE | 58 bajtów |
| 417 | OBJECT IDENTIFIERextensionRequest1.2.840.113549.1.9.14 | 11 bajtów |
| 428 | SET | 45 bajtów |
| 430 | SEQUENCE | 43 bajty |
| 432 | SEQUENCE | 41 bajtów |
| 434 | OBJECT IDENTIFIERSubject Alternative Name2.5.29.17 | 5 bajtów |
| 439 | OCTET STRING32 bajty30 1e 82 0f 77 77 77 2e 65 78 61 6d 70 6c 65 2e | 34 bajty |
| 473 | SEQUENCE | 15 bajtów |
| 475 | OBJECT IDENTIFIERsha256WithRSAEncryption1.2.840.113549.1.1.11 | 11 bajtów |
| 486 | NULL | 2 bajty |
| 488 | BIT STRING2048 bitów00 57 41 c5 09 98 14 78 8c ee c3 61 d4 c0 e0 2d | 261 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 podmiotuDrugi 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
Dekoder CSR: pytania i odpowiedzi
Jak zdekodować CSR?
-----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?
Jak sprawdzić, czy moje CSR jest poprawne?
Dlaczego mój urząd certyfikacji odrzuca moje CSR?
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?
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?
Jakich pól z mojego CSR urząd certyfikacji naprawdę używa?
OU i, w certyfikatach z walidacją domeny, emailAddress.Czy nazwa pospolita nadal ma znaczenie?
Czy mogę zdekodować kilka plików naraz?
Czym jest challenge password w CSR?
Czy mogę użyć klucza Ed25519 w certyfikacie publicznym?
Jak długo certyfikat jest dziś ważny?
Czegoś brakuje?Zaproponuj funkcję lub nowe narzędzie
Powiązane narzędzia
Generator CSR
Utwórz w przeglądarce żądanie podpisania certyfikatu i klucz prywatny: RSA lub ECDSA, z SAN i odpowiadającym im poleceniem OpenSSL
Sprawdzanie Certyfikatu SSL
Weryfikuj ważność certyfikatu SSL i szczegóły bezpieczeństwa
Kontrola kondycji DNS
Oceń DNS domeny: delegacja, serwery nazw, SOA, DNSSEC i poczta w 40 testach
Sprawdzanie DMARC
Sprawdź politykę DMARC i ustawienia wyrównania dla dowolnej domeny
Wyszukiwanie DNS
Wszystkie rekordy DNS prosto z serwerów nazw domeny, obok pamięci podręcznej Google i Cloudflare
Wyszukiwanie WHOIS
Wyszukaj rejestrację domeny, rejestratora i dane właściciela przez RDAP
