Generator CSR

Bo klucz prywatny, który trafia na cudzy serwer, spełnia własną definicję skompromitowanego klucza przyjętą w branży, niezależnie od tego, co ten serwer potem z nim zrobi.

CA/Browser Forum w Baseline Requirements definiuje to bez pola do dyskusji: „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ł.

To nie jest teoria. W 2020 roku DigiCert znalazł 337 kluczy prywatnych, które klienci wkleili razem ze swoimi żądaniami, unieważnił wszystkie związane z nimi certyfikaty i opisał to publicznie: „by sending the private key to DigiCert along with the CSR, the customer has compromised the private key”, dodając, że „the only part of a CSR we use is the public key”. Generator, który tworzy klucz na własnym serwerze i oddaje ci kopię, według tej definicji już go skompromitował. Ta strona nie może tego zrobić: crypto.subtle.generateKey działa w twojej przeglądarce, w ramce w piaskownicy, która nie może się nigdzie połączyć, a strona wokół niej widzi tylko klucz publiczny.

ECDSA P-256 do wszystkiego nowego: jest tak mocny jak 3072-bitowy klucz RSA, znacznie mniejszy i dozwolony przez reguły, których przestrzega każdy publiczny urząd certyfikacji. RSA 2048, gdy klucz musi odczytać starsze urządzenie.

NIST stawia P-256 i RSA-3072 na tym samym poziomie 128 bitów bezpieczeństwa, a RSA-4096 nie daje żadnej własnej siły: następny stopień w jego tabeli to 7680 bitów. Klucz 4096 kosztuje więc każdego odwiedzającego dodatkową pracę przy handshake bez udokumentowanego zysku. P-384 to stopień 192 bitów, a Baseline Requirements dopuszczają też P-521, ale Let's Encrypt odrzuca P-521: żądanie 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 jest tu oferowany, bo świetnie nadaje się do SSH, do podpisywania i do prywatnego urzędu certyfikacji, ale żaden publiczny urząd certyfikacji nie wystawi dla niego certyfikatu TLS. Reguły wymieniają RSA i trzy krzywe NIST, a potem mówią: „no other algorithms or key sizes are permitted”. To samo dotyczy postkwantowego ML-DSA: uchwała, która pozwoliłaby na niego w publicznym TLS, została zamknięta bez scalenia w październiku 2026. Generator mówi o tym przy każdym wyborze, zamiast pozwolić ci dowiedzieć się z maila z odrzuceniem.

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes -keyout example.com.key -out example.com.csr tworzy klucz i żądanie jednym krokiem.

Generator pisze polecenie dla wszystkiego, co wypełnisz, razem z alternatywnymi nazwami i każdym rozszerzeniem, a nasze testy przepuszczają je przez OpenSSL, by sprawdzić, że tworzy ten sam podmiot i te same rozszerzenia co strona. Dodaj -subj "/CN=example.com", by pominąć pytania, -addext "subjectAltName=DNS:example.com,DNS:www.example.com" dla nazw i -utf8, by nazwa z akcentem przetrwała. -nodes zostawia klucz niezaszyfrowany: OpenSSL 3 woli nowszy zapis -noenc, ale nadal przyjmuje -nodes, jedyny zapis, który zna LibreSSL wbudowany w macOS. Ten LibreSSL w ogóle nie potrafi utworzyć klucza Ed25519; do niego użyj OpenSSL 1.1.1 lub nowszego.

Aby sprawdzić, co utworzyłeś: openssl req -in example.com.csr -text -verify -noout drukuje każde pole i weryfikuje samopodpis, a gdy podpis się nie zgadza, kończy przed wydrukowaniem czegokolwiek. Aby potwierdzić, że klucz należy do żądania, porównaj openssl req -in example.com.csr -pubkey -noout z openssl pkey -in example.com.key -pubout. Żaden standard nie przypisuje CSR rozszerzenia pliku, więc .csr, .pem, .req i .txt są jednakowo poprawne.