W ostatnich latach sposób, w jaki generujemy CSR (Certificate Signing Request), przeszedł rewolucję.
Jeszcze kilka lat temu CSR był jednym z najmniej problematycznych elementów procesu wydawania certyfikatu – prostym plikiem tekstowym, w którym należało podać domenę, ewentualnie dane firmy, wygenerować klucz i tyle.
Dziś, w 2025 roku, CSR jest punktem krytycznym w procesie certyfikacji – elementem, który w bezpośredni sposób wpływa na bezpieczeństwo całej infrastruktury PKI, a w praktyce decyduje o tym, czy certyfikat zostanie wydany, czy nie.

Zmieniły się bowiem:

• standardy CA/B Forum,
• algorytmy kryptograficzne,
• sposób walidacji danych,
• wymagania przeglądarek,
• długości ważności certyfikatów,
• a nawet sposób, w jaki dane z CSR interpretowane są przez automaty, load balancery i mechanizmy CT Logs.

W efekcie CSR Hardening stał się obowiązkiem – nie opcją.

CSR w 2025 roku: od prostego formularza do elementu bezpieczeństwa.

Największa zmiana polega na odejściu od prostych, historycznych zasad i przejściu na model, w którym CSR musi spełniać normy kryptograficzne, proceduralne i zgodnościowe. Większość administratorów wciąż pamięta epokę, gdy wystarczało „wpisać CN, kliknąć enter i gotowe”. Tymczasem współczesne wymagania są bez porównania bardziej rygorystyczne.

Wystarczy jedna z poniższych rzeczy, aby CA odrzuciła CSR lub aby certyfikat po prostu nie działał poprawnie:

• brak SAN,
• przestarzały algorytm,
• niewłaściwa długość klucza,
• obecność pola OU,
• niezgodność danych firmy z rejestrem,
• CSR wygenerowany przez stary OpenSSL (np. 1.0.2),
• błędnie ustawione rozszerzenia.

Każdy z tych elementów może zatrzymać proces walidacji, nawet jeśli certyfikat został opłacony i zamówiony poprawnie.

Sercem CSR Hardening jest kryptografia – i tu zaszły największe zmiany.

W 2025 roku świat certyfikatów odchodzi od RSA 2048. Jest on nadal akceptowalny, ale jego dalsze używanie w nowych projektach jest przejawem konserwatyzmu, nie zgodności z nowoczesną praktyką. Coraz częściej minimalnym punktem startowym jest RSA 3072, a w sektorach wysokiego bezpieczeństwa – RSA 4096.
Jednak to nie RSA jest kierunkiem rozwoju. Standardem staje się ECDSA – zarówno w certyfikatach, jak i w samych CSR.

Dlaczego?
Ponieważ ECDSA pozwala na dużo krótsze klucze (P-256 i P-384), niższe obciążenie procesora, szybszy handshake, a w perspektywie kryptografii post-kwantowej – lepsze przygotowanie do hybrydowych modeli podpisu.

Nie zmienia to faktu, że wdrażając ECDSA należy zachować ostrożność – nie wszystkie urządzenia, aplikacje, systemy embedded i IoT są gotowe na rezygnację z  RSA.W takich środowiskach sprawdza się model dual-cert, w którym obsługiwane są oba algorytmy równolegle.

SAN stał się fundamentem – CN pełni dziś rolę historyczną.

Największą rewolucją w strukturze CSR jest przejście na model, gdzie CN stracił realne znaczenie. Dawniej wystarczyło wpisać CN=domena.pl i wszystko działało. Dziś, nawet jeśli certyfikat zostanie wystawiony z prawidłowym CN, przeglądarki i tak będą sprawdzać wyłącznie SAN (Subject Alternative Name).

Brak pola SAN oznacza:

• certyfikat może zostać wydany,
• ale Chrome, Firefox, Safari i Edge oznaczą go jako nieważny.

To najczęstsza przyczyna błędów, zwłaszcza gdy CSR generowany jest w panelach hostingowych, które wciąż nie wymuszają SAN lub implementują go w sposób niezgodny z normą.

Bezpieczeństwo klucza prywatnego – najczęściej zaniedbywany element.

W rozmowach z administratorami najczęściej pojawiają się pytania o to „jakie pola wpisać w CSR”. Znacznie rzadziej – jak zabezpieczyć klucz prywatny. A to właśnie klucz jest elementem absolutnie krytycznym: jego kradzież oznacza przejęcie całej tożsamości domeny.

Z naszej praktyki najczęściej widzimy błędy takie jak:

• klucz generowany w panelu hostingu (niewiadoma entropia),
• klucz przechowywany w katalogu public_html/private_html,
• klucz z uprawnieniami 644 lub 664,
• klucz kopiowany między serwerami,
• klucz udostępniany przez FTP,
• klucz wysyłany e-mailem (!).

W nowoczesnych systemach bezpieczeństwa klucz prywatny powinien być generowany lokalnie, przechowywany z prawami 600 i w idealnym przypadku – zabezpieczony poprzez izolację procesów (oddzielne pule PHP-FPM, separacja użytkowników Linux) lub wręcz w HSM.

Case Studies – Realne problemy wynikające z niedopracowanego CSR.

1. Duży sklep e-commerce – 7 godzin przestoju przez brak SAN.

Agencja obsługująca kilkanaście dużych sklepów odnowiła DV SSL na hostingu, który generuje CSR automatycznie. Problem polegał na tym, że panel wyświetlał SAN, ale w rzeczywistości go nie dodawał. CA odrzucało CSR kilkanaście razy, a administratorzy szukali winy w CA lub w certyfikacie.

Dopiero gdy przeanalizowaliśmy plik CSR, okazało się, że:

• SAN nie istnieje,
• OU było automatycznie dodawane,
• algorytm podpisu to SHA-1 (!),
• klucz miał tylko 2048 bit i generowano go przez przeglądarkę.

Po przygotowaniu poprawnego CSR certyfikat został wydany w trzy minuty – ale sklep zdążył stracić ruch i sprzedaż.

2. Certyfikat OV zablokowany na cztery dni przez skrót nazwy.

W innym przypadku firma SaaS czekała cztery dni na certyfikat OV. Przyczyną była pozornie nieistotna różnica między:

CSR: „TechCloud Systems”
Rejestr: „TechCloud Systems Spółka z ograniczoną odpowiedzialnością”

Dla CA to nie jest subtelność – to całkowita niezgodność danych. CSR został odrzucony, a cały proces walidacji zresetowany.

3. ECDSA wdrożone zbyt agresywnie – 18% użytkowników bez dostępu.

Startup z branży medycznej postanowił przejść w 100% na ECDSA. Nowy certyfikat był idealny technicznie – szybki handshake, mniejsze obciążenie serwera, świetne parametry. Niestety, 18% urządzeń IoT pacjentów nie obsługiwało ECDSA. Przez trzy dni nie działało pobieranie danych z urządzeń monitorujących stan zdrowia pacjentów. Dopiero wdrożenie dual-cert RSA+ECDSA przywróciło kompatybilność.

Kluczowe elementy poprawnego CSR w 2025 roku:

• SAN jest obowiązkowy,
• OU nie może się pojawić,
• RSA 3072 lub ECDSA P-256/P-384,
• OpenSSL 3.x dla zgodności z przyszłymi algorytmami,
• dane firmy zgodne 1:1 z rejestrem,
• klucz prywatny generowany lokalnie i zabezpieczony.

CSR HARDENING 2025 jest fundamentem przyszłościowego bezpieczeństwa.

Wraz ze skracającą się ważnością certyfikatów i przejściem na modele automatyczne (ACME, krótkie cykle, hybrydy PQC), CA i przeglądarki stają się coraz mniej tolerancyjne na błędy. Certyfikaty stają się „paliwem infrastruktury” – ale CSR to zawór bezpieczeństwa, który musi działać perfekcyjnie.

Firmy, które wdrożą CSR Hardening już teraz, przygotują się na:

• zmianę algorytmów,
• skrócenie cyklów,
• automatyzację,
• post-quantum TLS,
• pełną zgodność z CA/B Forum.

A te, które zostaną przy starych metodach, będą co 3 miesiące powtarzać ten sam dramat: odrzucony CSR, błędny certyfikat i nagłe „Why isn’t SSL working?”.

PQC i CSR przyszłości – co zmieni kryptografia post-kwantowa?

Choć większość administratorów myśli o CSR w kontekście RSA lub ECDSA, w tle zachodzi dużo większa zmiana: przygotowanie infrastruktury certyfikatów do nadejścia kryptografii post-kwantowej (PQC).
NIST zakończył proces standaryzacji pierwszych algorytmów odpornych na ataki komputerów kwantowych, z których kluczowy jest CRYSTALS-Kyber (algorytm KEM) oraz Dilithium (podpis cyfrowy).

W praktyce oznacza to, że cały ekosystem TLS – serwery, przeglądarki, CA, load balancery – będzie musiał ewoluować, tak jak kiedyś z SHA-1 → SHA-256. Różnica polega na tym, że teraz zmiana dotyczy fundamentalnej struktury kluczy i podpisów, w tym również pliku CSR.

Najbliższe lata przyniosą stopniowe wdrażanie certyfikatów hybrydowych, czyli takich, które zawierają dwa algorytmy naraz:

• klasyczny (ECDSA lub RSA),
• kwantoodporny (Kyber).

Tzw. „hybrid certificates” będą w stanie funkcjonować zarówno w środowiskach tradycyjnych, jak i tych przygotowanych na TLS post-quantum.

A co z CSR?

Tu właśnie pojawia się kluczowy aspekt:
CSR musi być generowany przy użyciu bibliotek i narzędzi, które są w stanie obsługiwać struktury hybrydowe. OpenSSL 1.x nigdy nie będzie kompatybilny z PQC – pełne wsparcie zaczyna się od OpenSSL 3.x, a część wdrożeń będzie wymagała dodatkowych patchy.

W przyszłości CSR będzie zawierał:

1. Podwójny zestaw parametrów klucza – klasyczny oraz kwantoodporny.
2. Rozszerzenia pola KeyUsage dostosowane do podpisów PQC.
3. Nowe formaty certyfikacji KEM (Key Encapsulation Mechanism).
4. Znacznie większe nagłówki CSR, ponieważ PQC generuje dużo większe klucze publiczne.

To nie jest teoria – CA już prowadzą testy, a wiele firm (Google, DigiCert, Cloudflare) wdraża PQC w środowiskach produkcyjnych w formie eksperymentalnej. CSR przyszłości nie będzie więc pojedynczym plikiem „req”, ale kontenerem wieloalgorytmicznym, mieszczącym klasyczne ECDSA i elementy PQC.

Dlatego pierwsza zasada CSR Hardening dotycząca przyszłości brzmi: Twórz CSR zawsze przy użyciu nowoczesnych wersji OpenSSL – inaczej w 2026–2028 i tak będziesz musiał to zrobić od nowa.

Najczęstsze mity o CSR, które powodują realne problemy.

Pomimo ogromnych zmian w standardach TLS, wiele mitów dotyczących CSR nadal żyje – głównie dlatego, że większość dokumentacji dostępnej w internecie ma 10–15 lat. Te mity prowadzą do błędów, odrzuconych certyfikatów, a nawet naruszeń bezpieczeństwa. Warto je obalić raz na zawsze – zwłaszcza że w 2025 roku skutki tych pomyłek są dużo poważniejsze.

Mit 1: „W CSR najważniejszy jest CN”.

Nieprawda. CN jest dziś polem historycznym. Od 2017 roku przeglądarki ignorują CN w procesie walidacji domeny. Liczy się wyłącznie SAN, a certyfikat bez SAN będzie nieważny.

Mit 2: „RSA 2048 jest bezpieczne i wystarczające”.

Było – w 2012 roku. W 2025 roku RSA 2048 jest minimalnym progiem akceptowalności, a nie rekomendacją. Przy nowych projektach jest to zły wybór, bo z dużą dozą pewności trzeba będzie wrócić do tematu w ciągu 1-2 lat.

Mit 3: „OU można zostawić, bo to tylko informacja pomocnicza”.

OU jest deprecated i faktycznie stanowi ryzyko: może wprowadzać w błąd, nie jest walidowane, CA traktują je jako bezużyteczne i niechętnie widzą je w CSR. W przypadku OV i EV pole OU bywa powodem natychmiastowego odrzucenia żądania.

Mit 4: „CSR można wygenerować na dowolnym hostingu, przecież to tylko formularz”.

Właśnie NIE. Wiele hostingów:

• generuje RSA 2048, nawet jeśli użytkownik wybiera 4096,
• nie dodaje SAN,
• używa starych wersji OpenSSL,
• dodaje OU mimo że użytkownik go nie wpisał,
• używa SHA-1 (!).

CSR z paneli hostingu to częsta recepta na problemy.

Mit 5: „Klucz prywatny nie jest aż tak istotny, przecież liczy się certyfikat”.

To najbardziej niebezpieczny mit. Certyfikat można wymienić w 2-5 minut. Klucz prywatny jest elementem unikalnym – jego utrata oznacza kompromitację tożsamości domeny.

Kradzież klucza = możliwość podszywania się pod Twoją stronę.

Mit 6: „CSR można przenosić między serwerami razem z kluczem”.

Technicznie można, ale nie wolno. Klucz powinien istnieć w jednym miejscu. W rzeczywistości wiele incydentów wynika z tego, że klucze są kopiowane między środowiskami, testami, stagingiem, serwerami programistów, a nawet backupami w chmurze.

Mit 7: „CSR nie ma wpływu na zgodność TLS i kompatybilność z urządzeniami”.

Ma – i to ogromny. Jeśli w CSR wymusisz ECDSA, certyfikat ECDSA nie będzie działał na starszych urządzeniach. Jeśli wybierzesz RSA 4096, część urządzeń embedded lub starszych przeglądarek odrzuci handshake. CSR wpływa bezpośrednio na to, czy Twoją stronę da się odwiedzić.

Mit 8: „CSR nie ma żadnego związku z PQC”.

Ma – bo CSR definiuje, jakiego formatu i struktury klucz zostanie użyty teraz i w przyszłości. Jeżeli dziś generujesz CSR narzędziami, które nie wspierają nowoczesnych bibliotek kryptograficznych, za chwilę będziesz musiał powtarzać całą migrację.

Masz pytania związane z certyfikatami SSL lub rozwiązaniami w zakresie cybersecurity dla Twojej firmy? Skontaktuj się z naszym działem sprzedaży.