Co to jest plik CSR i jak go wygenerować dla certyfikatu SSL?

Plik CSR (Certificate Signing Request) to wygenerowany na serwerze blok zaszyfrowanego tekstu, który zawiera dane identyfikacyjne domeny i firmy, wymagany do wydania certyfikatu SSL. Generuje się go za pomocą narzędzi takich jak OpenSSL lub z poziomu panelu hostingowego, tworząc jednocześnie powiązany z nim klucz prywatny. Zwykły ciąg znaków z pozoru. A jednak bez niego żadna strona nie ruszy po protokole HTTPS.

Prawda jest zresztą absolutnie taka, że większość początkujących administratorów traktuje generowanie CSR jako zło konieczne. Wpisują przypadkowe dane, kopiują komendy ze Stack Overflow i liczą na zieloną kłódkę w przeglądarce. Potem następuje odrzucenie wniosku przez urząd certyfikacji (CA). Tracisz czas. Tracisz nerwy. Piszę to jako człowiek, który wczoraj o trzeciej nad ranem diagnozował awarię na produkcji, bo ktoś w zespole zgubił klucz prywatny wygenerowany tydzień wcześniej razem z żądaniem CSR. Serwer po prostu odrzucił nowy certyfikat. Zwykła literówka kosztowała nas dwie godziny przestoju.

Co dokładnie kryje w sobie plik CSR?

Żądanie podpisania certyfikatu to nie jest magiczny plik z kosmosu. To ustrukturyzowana informacja zapisana w formacie Base64. Kiedy otworzysz wygenerowany plik w notatniku, zobaczysz blok tekstu zaczynający się od „—–BEGIN CERTIFICATE REQUEST—–„. Wewnątrz tego bloku zakodowane są dane, które urząd certyfikacji musi zweryfikować przed wystawieniem dokumentu tożsamości dla twojego serwera WWW.

Kiedy rozkodujemy ten ciąg znaków, naszym oczom ukażą się konkretne pola. Urzędy certyfikacji wymagają ich do potwierdzenia, że masz prawo ubiegać się o szyfrowanie dla danego adresu. Dobrym pomysłem jest przygotowanie sobie tych danych na kartce, zanim usiądziesz do terminala.

Jak wygenerować plik CSR w konsoli Linux (OpenSSL)?

W zdecydowanej większości przypadków na serwerach opartych o systemy Linux (Ubuntu, Debian, CentOS) używamy biblioteki OpenSSL. To absolutny standard branżowy. Masz przed sobą czarny ekran terminala. Musisz wpisać jedną komendę, która stworzy dwa pliki jednocześnie.

Wpisujesz to:

openssl req -new -newkey rsa:2048 -nodes -keyout nazwadomeny.key -out nazwadomeny.csr

System zada ci serię pytań. Zacznie od nazwy kraju, potem zapyta o województwo, miasto i tak dalej. Musisz wpisywać te dane ręcznie i zatwierdzać enterem. Kiedy dojdziesz do pola „Common Name”, wpisz dokładny adres swojej strony. Zawsze, ale to ZAWSZE sprawdzaj to pole dwa razy. Błąd tutaj oznacza, że cały proces trzeba zaczynać od nowa.

Parametr rsa:2048 oznacza, że tworzymy klucz o długości 2048 bitów. To obecnie minimum bezpieczeństwa. Możesz użyć 4096, ale to obciąży procesor serwera przy nawiązywaniu połączeń. Flaga -nodes sprawia, że klucz prywatny nie jest chroniony dodatkowym hasłem. Hasło na kluczu brzmi jak świetny pomysł pod kątem bezpieczeństwa. Niestety przy każdym restarcie serwera Apache lub Nginx, usługa zatrzyma się i będzie czekać, aż wpiszesz to hasło z klawiatury. W środku nocy to dramat.

Dlaczego klucz prywatny to najsłabsze ogniwo?

Zatrzymamy się tutaj na chwilę. Wygenerowałeś CSR i wysłałeś go do dostawcy certyfikatu. Na twoim dysku został drugi plik z rozszerzeniem .key. Ten plik to klucz prywatny.

To jest matematyka. Jeden klucz zamyka dane, drugi otwiera. CSR zawiera twój klucz publiczny, który jest częścią certyfikatu SSL. Klucz prywatny zostaje u ciebie. Nikomu go nie wysyłasz. Nigdy. Czasami na forach widzę, jak początkujący webmasterzy wklejają zawartość klucza prywatnego w tickety do supportu hostingu. To tak, jakbyś wysłał komuś pocztą odlew kluczy do własnego mieszkania razem z dokładnym adresem.

Jeżeli zgubisz klucz prywatny, plik CSR staje się bezużyteczny. Nawet jeśli urząd wystawi ci certyfikat SSL na podstawie przesłanego żądania, nie zainstalujesz go na serwerze. Serwer WWW wyświetli błąd o braku zgodności modułów (modulus mismatch). Będziesz musiał generować nowy CSR, nowy klucz i prosić o ponowne wystawienie certyfikatu (reissue).

Generowanie żądania w środowisku Windows Server (IIS)

Środowisko Microsoftu rządzi się własnymi prawami. Tutaj rzadko używamy wiersza poleceń do tych zadań. Zamiast tego przeklikujemy się przez graficzny interfejs menedżera usług internetowych (IIS Manager). Narzędzie to ukrywa przed administratorem całą matematykę i tworzenie klucza prywatnego, co ma swoje plusy, ale uczy złych nawyków.

• Otwierasz Menedżer usług informacyjnych (IIS). W głównym oknie serwera, w sekcji z zabezpieczeniami, klikasz ikonę Certyfikaty serwera.
• Z menu po prawej stronie wybierasz akcję Utwórz żądanie certyfikatu.
• Wyskakuje kreator. Wypełniasz te same dane co w OpenSSL. Nazwa pospolita to oczywiście twoja domena. Dostawca usług kryptograficznych zazwyczaj zostaje domyślny (Microsoft RSA SChannel Cryptographic Provider), a długość bitowa to 2048.
• Wskazujesz ścieżkę do zapisu pliku tekstowego na dysku C.

Gdzie jest klucz prywatny? Windows schował go w swoim wewnętrznym magazynie certyfikatów. Kiedy wrócisz z gotowym certyfikatem SSL od dostawcy, użyjesz opcji „Zakończ żądanie certyfikatu”. System sam połączy nowy certyfikat z ukrytym kluczem prywatnym. To wygodne, dopóki nie musisz przenieść tego certyfikatu na inny fizyczny serwer. Wtedy zaczyna się eksportowanie do formatu PFX z hasłem, co potrafi przyprawić o ból głowy.

Panele hostingowe cPanel i DirectAdmin

Wielu użytkowników nie zarządza własnymi serwerami dedykowanymi. Korzystają z hostingów współdzielonych. Zleciliśmy kiedyś audyt infrastruktury dla małej agencji marketingowej na krakowskim Kazimierzu. Mieli kilkadziesiąt stron klientów rozsianych po różnych tanich hostingach. Próbowali generować CSRy ręcznie przez zewnętrzne generatory online. To proszenie się o kłopoty z bezpieczeństwem.

W cPanelu proces jest banalny. Wchodzisz w sekcję Zabezpieczenia, klikasz SSL/TLS. Tam masz link do zarządzania żądaniami podpisania certyfikatu (CSR). Wypełniasz formularz na stronie WWW. Klikasz generuj. System sam tworzy klucz prywatny, sam zapisuje go w bezpiecznym folderze na twoim koncie hostingowym i wypluwa na ekran gotowy tekst CSR, który po prostu kopiujesz do schowka.

DirectAdmin działa niemal identycznie. W zakładce Certyfikaty SSL wybierasz opcję tworzenia nowego żądania, wpisujesz dane domeny i gotowe. Zdejmuje to z głowy całą zabawę w terminalu.

Certyfikaty Wildcard i SAN a struktura żądania

Zwykły certyfikat chroni jeden adres. Na przykład sklep.pl. Ale co jeśli masz panel klienta pod adresem panel.sklep.pl i bloga pod blog.sklep.pl? Kupowanie osobnych certyfikatów mija się z celem.

Tu wchodzi koncepcja Wildcard. Generując CSR dla takiego certyfikatu, w polu Common Name wpisujesz gwiazdkę. Dokładnie tak: *.sklep.pl. Urząd certyfikacji zrozumie, że chcesz chronić wszystkie subdomeny pierwszego poziomu. Pamiętaj jednak, że gwiazdka chroni tylko jeden poziom. Adres nowy.blog.sklep.pl nie będzie objęty szyfrowaniem przez certyfikat wystawiony na *.sklep.pl.

Inaczej sprawa wygląda z certyfikatami Multi-Domain (SAN – Subject Alternative Names). Tutaj z poziomu jednej komendy OpenSSL musimy dorzucić plik konfiguracyjny, w którym wymieniamy wszystkie dodatkowe domeny. To wyższa szkoła jazdy i najczęściej wymaga modyfikacji pliku openssl.cnf przed puszczeniem komendy generującej. W dużych organizacjach używamy takich certyfikatów dla serwerów Exchange, gdzie jedna maszyna odpowiada na adresy poczta.firma.pl, autodiscover.firma.pl i webmail.firma.pl.

Algorytmy kryptograficzne: RSA czy ECC?

Od lat standardem jest RSA. Wspomniałem wcześniej o długości 2048 bitów. To działa i jest wspierane przez każdy antyczny telefon komórkowy czy starą przeglądarkę. Rynek powoli przesuwa się w stronę kryptografii opartej na krzywych eliptycznych (ECC – Elliptic Curve Cryptography).

Klucz ECC o długości zaledwie 256 bitów oferuje poziom bezpieczeństwa porównywalny z kluczem RSA o długości 3072 bitów. Mniejszy klucz oznacza mniejszy plik CSR, szybsze nawiązywanie połączeń TLS (tzw. handshake) i mniejsze obciążenie procesora na serwerze. Generowanie żądania w standardzie ECC wymaga dwóch kroków w OpenSSL.

Najpierw generujemy parametry krzywej:

openssl ecparam -out server.key -name prime256v1 -genkey

A dopiero potem sam CSR na podstawie tego klucza:

openssl req -new -key server.key -out server.csr

Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał, że urzędy certyfikacji zaczną masowo wymuszać ECC jako domyślny standard przed końcem przyszłego roku. Na razie większość klientów korporacyjnych wciąż kurczowo trzyma się RSA ze względu na kompatybilność ze starszymi systemami magazynowymi.

Dekodowanie i weryfikacja żądania przed wysłaniem

Nie ma nic gorszego niż opłacenie zamówienia na certyfikat SSL u dostawcy, wklejenie kodu CSR i otrzymanie po godzinie informacji, że w nazwie firmy jest niedozwolony znak. Albo że zapomniałeś o literze w nazwie domeny.

Zanim wyślesz ten zaszyfrowany blok tekstu, sprawdź go. W systemie Linux służy do tego prosta komenda:

openssl req -in nazwadomeny.csr -noout -text

Terminal wypluje ci czystym tekstem wszystko, co zaszyfrowałeś. Zobaczysz pole Subject, gdzie wylistowane będą twoje C, ST, L, O, OU i CN. Sprawdzisz algorytm podpisu i sam klucz publiczny. Jeśli korzystasz z Windowsa, możesz wejść na dowolną stronę oferującą narzędzie „CSR Decoder”. Wklejasz tam tekst, a skrypt parsuje go i pokazuje zawartość w czytelnej tabelce.

Zjawisko utraty spójności kluczy

Dorzucę tu anegdotę z warsztatu. Dwa lata temu wdrażaliśmy potężny portal e-commerce. Zespół deweloperski wygenerował CSR na serwerze testowym. Kupili certyfikat EV, przeszli rygorystyczną weryfikację telefoniczną i dokumentową. Dostali pliki. W międzyczasie administratorzy postawili zupełnie nową maszynę produkcyjną i przenieśli tam aplikację, kasując stary serwer testowy razem z kluczem prywatnym.

Certyfikat za kilka tysięcy złotych stał się bezwartościowym ciągiem bajtów. Zrobiliśmy na wdrożeniu reinstalację paczek, potem zawiesiło się proxy, więc wprowadzono poprawkę w Nginx przed poniedziałkiem, ale z certyfikatem nie dało się zrobić nic. Musieliśmy wygenerować nowe żądanie CSR na właściwym serwerze i przejść proces reissue u dostawcy, co opóźniło start kampanii reklamowej o dwa dni.

Jak sprawdzić, czy twój CSR, klucz prywatny i ostateczny certyfikat SSL pasują do siebie? Obliczasz ich moduły matematyczne.

Dla klucza prywatnego:

openssl rsa -noout -modulus -in klucz.key | openssl md5

Dla pliku CSR:

openssl req -noout -modulus -in plik.csr | openssl md5

Jeśli ciągi znaków MD5 z obu komend są identyczne, wszystko do siebie pasuje. Jeśli różnią się choćby jednym znakiem, pliki nie pochodzą z tej samej pary. To najprostszy i najskuteczniejszy test przed próbą instalacji.

Czy można użyć tego samego CSR do odnowienia certyfikatu?

Technicznie? Tak. Większość urzędów certyfikacji pozwoli ci wkleić stary plik CSR podczas odnawiania usługi na kolejny rok. Oszczędza to czas, bo omijasz logowanie do terminala.

Z punktu widzenia bezpieczeństwa? To fatalny pomysł. Używanie tego samego żądania oznacza używanie tego samego klucza prywatnego. Złota zasada kryptografii mówi o rotacji kluczy. Im dłużej dany klucz prywatny leży na serwerze, tym większe prawdopodobieństwo, że ktoś go skopiował, wyciekł w backupach lub został skompromitowany przez lukę w oprogramowaniu serwera (pamiętamy Heartbleed z 2014 roku).

Zmieniliśmy te zasady na robocie. Wymuszamy generowanie nowej pary klucz/CSR co 12 miesięcy, bez wyjątków. To po prostu higiena pracy administratora.

Zautomatyzowane środowiska i ACME

Cały ten proces ręcznego wklepywania danych wydaje się archaiczny w czasach chmury i kontenerów. Narzędzia takie jak Certbot od Let’s Encrypt wykorzystują protokół ACME, aby załatwić sprawę bez udziału człowieka. Odpalasz skrypt, a on sam generuje klucz prywatny w tle, sam tworzy CSR, sam negocjuje z urzędem certyfikacji, pobiera SSL i restartuje serwer WWW.

Dlaczego więc ktokolwiek jeszcze bawi się w ręczne żądania? Z trzech powodów. Po pierwsze, certyfikaty korporacyjne (OV i EV) wymagają ręcznej weryfikacji tożsamości firmy przez pracownika CA. Tego nie da się w pełni zautomatyzować skryptem z racji wymogów formalnych. Po drugie, urządzenia sieciowe. Spróbuj zainstalować automatycznego Certbota na sprzętowym firewallu Cisco, load balancerze F5 czy starym switchu zarządzalnym. Musisz wygenerować CSR u nich w interfejsie i zaimportować podpisany certyfikat z palca. Po trzecie, wewnętrzne urzędy certyfikacji w firmach (Microsoft Active Directory Certificate Services), gdzie polityka bezpieczeństwa izoluje serwery od publicznego internetu.

Zagrożenia i wektory ataków na etapach przygotowawczych

Wydaje się, że sam plik z żądaniem podpisania nie stwarza zagrożenia, bo to tylko klucz publiczny i nazwa domeny. Jednak proces jego powstawania kryje ryzyko. Gdy generujesz CSR na niepewnym urządzeniu lub przez formularz na podejrzanej stronie, ryzykujesz przejęcie klucza prywatnego. Skompromitowany klucz prywatny w rękach atakującego pozwala na ataki Man-in-the-Middle (MitM). Atakujący może postawić fałszywą stronę, podszyć się pod twój bank lub sklep i odszyfrowywać ruch klientów w locie, a przeglądarka nie wyświetli żadnego błędu, bo podpis cyfrowy będzie się zgadzał.

Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze ze skanerami podatności? Sam się nad tym borykałem dzisiaj u siebie we wtorek. Skanery szukają starych, słabych kluczy RSA 1024-bit. Jeśli wygenerujesz CSR ze słabym kluczem, urząd certyfikacji z automatu odrzuci wniosek, zwracając błąd o niewystarczającej sile kryptograficznej. To mechanizm obronny narzucony przez konsorcjum CA/Browser Forum, które ustala zasady gry w branży SSL.

Struktura kodowania: PEM vs DER

Standardowy plik CSR, o którym tu cały czas rozmawiamy, używa formatu PEM (Privacy-Enhanced Mail). To po prostu ASCII. Możesz to otworzyć, skopiować do maila, wkleić na Slacku. Zaczyna się od myślników i słów BEGIN. Base64 dba o to, by znaki drukowalne nie uległy uszkodzeniu podczas przesyłania.

Istnieje też format DER (Distinguished Encoding Rules). To format binarny. Jeśli spróbujesz otworzyć plik CSR w formacie DER za pomocą notatnika, zobaczysz krzaki, dziwne symbole i całkowity chaos. Sprzęt sieciowy oparty o Javę często wymaga formatów binarnych. Konwersja między nimi to kwestia jednej komendy w OpenSSL.

openssl req -in zyczenie.csr -outform der -out zyczenie.der

Rzadko się z tym spotkasz przy standardowych serwerach WWW, ale praca z systemami bankowymi potrafi wymusić znajomość tych formatów w najmniej oczekiwanym momencie pod presją wdrożenia.

Podsumowanie problematyki kodowania i konfiguracji

Zrozumienie, czym jest żądanie podpisania certyfikatu, to podstawa administrowania usługami sieciowymi. Nie da się tego pominąć. Bez poprawnego żądania nie ma certyfikatu. Bez certyfikatu przeglądarki blokują dostęp do strony wielkim, czerwonym ostrzeżeniem o braku prywatności. To bezpośrednio uderza w zaufanie klientów i sprzedaż e-commerce.

Zamiast traktować to jako uciążliwy obowiązek, potraktuj generowanie par kryptograficznych jako fundament bezpieczeństwa twojej infrastruktury. Pilnuj kluczy prywatnych jak numeru PIN do własnej karty. Weryfikuj dane z dekoderem przed wysłaniem wniosku. Zrezygnuj z przesyłania kluczy prywatnych przez komunikatory w zespole.

Odpal teraz swój terminal. Wygeneruj testowe żądanie na sucho. Sprawdź, jak zachowuje się OpenSSL. Zrób błąd celowo w nazwie domeny i zdekoduj plik, by zobaczyć, jak to wygląda w logach. Pospolite ucięcie pomyłek na sucho pozwala uniknąć wstydu podczas rozmowy z supportem dostawcy o trzeciej w nocy.

Najczęściej zadawane pytania (FAQ)

• Czy plik CSR to to samo co certyfikat SSL?

  Nie. CSR to tylko wniosek (żądanie) o wydanie certyfikatu. Zawiera dane domeny i klucz publiczny. Certyfikat SSL to dokument wystawiony przez urząd na podstawie tego wniosku.

• Gdzie znajduje się klucz prywatny po wygenerowaniu CSR?

  Klucz prywatny zostaje zapisany na serwerze, na którym wykonano komendę generującą. W panelach hostingowych jest ukryty w specjalnym menedżerze kluczy.

• Czy mogę wygenerować plik CSR online?

  Technicznie tak, istnieją takie generatory. Ze względów bezpieczeństwa jest to wysoce odradzane. Generując CSR u kogoś na stronie, powierzasz mu również wygenerowanie Twojego klucza prywatnego.

• Co wpisać w polu Common Name?

  Należy wpisać dokładny adres domeny, która ma być chroniona. Dla certyfikatów Wildcard wpisujemy adres z gwiazdką: *.mojadomena.pl.

• Co zrobić, jeśli zgubiłem klucz prywatny do gotowego CSR?

  Musisz rozpocząć całą procedurę od początku. Wygeneruj nową parę i poproś dostawcę o ponowne wystawienie certyfikatu.

• Jak sprawdzić, czy plik CSR zawiera poprawne dane?

  Możesz użyć komendy konsolowej openssl lub skorzystać z dekoderów CSR, które parsują tekst na czytelną tabelę.

Bibliografia i źródła wiedzy technicznej

1. Fundacja Let’s Encrypt – https://letsencrypt.org
2. Dokumentacja projektu OpenSSL – https://www.openssl.org
3. Konsorcjum CA/Browser Forum – https://cabforum.org
4. Baza wiedzy Microsoft IIS – https://learn.microsoft.com
5. Standardy kryptograficzne NIST – https://www.nist.gov