Co to jest OpenSSL? Zastosowanie i podstawowe komendy

OpenSSL to otwartoźródłowa biblioteka kryptograficzna i narzędzie wiersza poleceń, które realizuje protokoły sieciowe SSL oraz TLS do bezpiecznego szyfrowania danych w internecie. Służy przede wszystkim do generowania kluczy prywatnych, tworzenia żądań podpisania certyfikatu (CSR) oraz zarządzania certyfikatami cyfrowymi na serwerach WWW. Wdrożyliśmy to tysiące razy w różnych środowiskach. A błędy wciąż wracają. Serwery padają przez przeterminowane pliki PEM. Więc dzisiaj rozbierzemy ten temat do gołej blachy.

Prawda jest zresztą absolutnie taka, że większość administratorów kopiuje komendy ze Stack Overflow bez krzty zrozumienia mechaniki pod spodem. Zmienimy to tu i teraz. Zrozumienie mechanizmów szyfrowania asymetrycznego pozwala zachować spokój, gdy nagle przeglądarki rzucają błędem o niezaufanym wystawcy. Infrastruktura klucza publicznego (PKI) opiera się na matematyce. I na poprawnym wydawaniu poleceń w terminalu.

Jak dokładnie działa szyfrowanie i co to jest OpenSSL? Zastosowanie i podstawowe komendy w praktyce

Kiedy nowy inżynier pyta mnie o temat „Co to jest OpenSSL? Zastosowanie i podstawowe komendy”, zawsze zaczynam od rozebrania na części samej komunikacji klient-serwer. OpenSSL ma potężne możliwości. Odpowiada za zestawienie bezpiecznego tunelu pomiędzy przeglądarką użytkownika a serwerem Nginx lub Apache. Biblioteka ta obsługuje algorytmy szyfrujące, takie jak RSA, krzywe eliptyczne (ECC) oraz funkcje skrótu typu SHA-256. Przetwarza dane, szyfruje je i upewnia się, że nikt po drodze nie zmodyfikował pakietów.

Zastosowanie OpenSSL obejmuje cztery główne obszary operacyjne:

• Generowanie par kluczy kryptograficznych (prywatnego i publicznego), które stanowią fundament bezpieczeństwa całego serwera WWW, poczty e-mail czy bazy danych. Wymaga to podania odpowiedniej długości bitowej, zazwyczaj 2048 lub 4096 bitów dla algorytmu RSA, chociaż obecnie coraz mocniej pcha się standardy oparte o krzywe eliptyczne ze względu na mniejszy narzut obliczeniowy na procesor.
• Tworzenie żądań CSR wysyłanych do urzędów certyfikacji (CA).
• Lokalne testowanie i debugowanie połączeń TLS za pomocą wbudowanego klienta.
• Konwersja dziwnych formatów plików dostarczanych przez klientów z systemów Windows.

Zrobiliśmy na wdrożeniu w zeszłym miesiącu migrację starego systemu bankowego. Klient dostarczył paczkę certyfikatów w formacie PFX. Nasz load balancer na Linuksie przyjmował tylko czysty PEM. Bez OpenSSL cały projekt stanąłby w martwym punkcie na kilka dni. Użyliśmy jednej komendy do rozbicia kontenera na klucz prywatny i certyfikat publiczny. System wstał w piętnaście minut.

Jak poprawnie wygenerować klucz prywatny i plik CSR?

Proces uzyskiwania certyfikatu od zewnętrznego dostawcy zawsze zaczyna się na twoim serwerze. Musisz wygenerować klucz prywatny. Ten plik nigdy nie opuszcza twojej maszyny. Traktuj go jak PIN do karty bankomatowej. Jeśli wycieknie, cały ruch sieciowy jest skompromitowany. To jest bez mała najgorsza opcja z wszystkich.

By wygenerować nowy klucz RSA o długości 2048 bitów, wpisujesz w terminalu:

openssl genrsa -out mojserwer.key 2048

Mamy klucz. Ale to za mało. Teraz urząd certyfikacji (jak Let’s Encrypt, DigiCert czy NASK) musi wiedzieć, dla jakiej domeny chcesz wystawić dokument. Do tego służy CSR, czyli Certificate Signing Request. Generujesz go na bazie przed chwilą utworzonego klucza.

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

System zapyta cię o kilka danych. Kraj (Country Name), województwo, miasto, nazwa organizacji. Najważniejsze pole to Common Name (CN). Tutaj wpisujesz dokładną nazwę domeny, np. www.twojastrona.pl. Pomyłka w tym miejscu oznacza odrzucenie wniosku przez CA. Zmieniliśmy te zasady na robocie lata temu, żeby zawsze automatyzować ten proces skryptami basha, bo literówki robione z palca niszczyły nam harmonogramy wdrożeń.

Możesz też zrobić to jednym strzałem. Jedna komenda załatwia klucz i CSR jednocześnie:

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

Flaga -nodes oznacza „no DES”. OpenSSL nie zaszyfruje pliku klucza prywatnego hasłem. To przydatne, gdy serwer Nginx musi zrestartować się automatycznie w nocy i nie ma człowieka przy klawiaturze, żeby wpisać hasło startowe. Zresztą, używanie haseł na kluczach serwerowych w dobie kontenerów Docker mija się z celem.

W jaki sposób wygenerować certyfikat self-signed do testów lokalnych?

Czasami nie masz czasu na zewnętrzne CA. Pracujesz w sieci LAN. Programiści potrzebują HTTPS do testowania API. Generujesz wtedy certyfikat samopodpisany (self-signed). Przeglądarki rzucą czerwonym ostrzeżeniem, ale ruch i tak będzie zaszyfrowany.

openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout lokalny.key -out lokalny.crt

Otrzymujesz plik ważny przez rok (365 dni). I tu wrzucę dygresję z życia. Pracowałem kiedyś w małej serwerowni na warszawskim Mokotowie, blisko Domaniewskiej. Mieliśmy tam wewnętrzny system bilingowy na starym switchu, który ktoś spiął z self-signed certyfikatem na 10 lat. Nikt tego nie pilnował. W pewien wtorek o 3 nad ranem system nagle przestał autoryzować pakiety z powodu zmiany polityki w nowej wersji przeglądarki, która odrzuciła algorytm SHA-1 ucięty w OpenSSL. Szukaliśmy błędu w kodzie PHP przez osiem godzin, podczas gdy problem leżał w prymitywnej kryptografii odrzuconej przez nowożytne standardy na rynku IT. Wystarczyło podbić skrót do SHA-256.

Do czego służą konwersje formatów certyfikatów i jak je wykonać?

Zarządzanie infrastrukturą to praca na stykach różnych technologii. Środowiska uniksowe kochają format PEM (zwykły tekst w Base64). Windows Server i IIS preferują pliki binarne PFX (PKCS#12) lub DER. OpenSSL jest genialnym translatorem tych standardów. Bez niego przenoszenie zabezpieczeń między systemami byłoby koszmarem.

Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze? Sam się nad tym borykałem dzisiaj u siebie we wtorek. Powodem jest zazwyczaj zła konwersja. Windows daje ci PFX, a ty musisz wrzucić to na Linuksa. Używasz komendy, by wyciągnąć sam klucz prywatny:

openssl pkcs12 -in plik.pfx -nocerts -out klucz.pem

Potem wyciągasz certyfikat publiczny:

openssl pkcs12 -in plik.pfx -clcerts -nokeys -out certyfikat.pem

Zawsze pamiętaj o haśle do PFX, bo inaczej CAŁA robota idzie do kosza. OpenSSL odrzuci próbę ekstrakcji danych. Co ciekawe, system poprosi cię też o ustalenie nowego hasła dla pliku wyjściowego PEM. Jeśli chcesz go zdjąć (bo Nginx tego wymaga), musisz wykonać jeszcze jeden przebieg komendą `rsa`.

Jak debugować błędy połączeń SSL/TLS używając wbudowanych narzędzi?

Generowanie kluczy to jedno. Weryfikacja to zupełnie inna gra. Gdy klient dzwoni i krzyczy, że strona nie działa, nie zgadujesz. Używasz OpenSSL do chirurgicznego zbadania problemu. Czasem dostajesz od kogoś plik i nie masz pojęcia, czy to klucz, żądanie CSR, czy certyfikat główny.

Czytanie zawartości certyfikatu w czytelnej dla człowieka formie:

openssl x509 -in certyfikat.crt -text -noout

Ta komenda wypluje na ekran wszystkie szczegóły. Zobaczysz datę wygaśnięcia (Not After), wystawcę (Issuer) oraz przypisane domeny w sekcji Subject Alternative Name (SAN). Brak domeny w SAN to obecnie główna przyczyna odrzucania certyfikatów przez Chrome i Firefox. Lata temu wystarczało pole Common Name. Dzisiaj to za mało.

Weryfikacja spójności. To trik, który ratuje życie. Masz klucz i masz certyfikat. Jak sprawdzić, czy do siebie pasują, zanim zrestartujesz serwer produkcyjny i odetniesz użytkowników? Obliczasz sumy kontrolne modułów (modulus) obu plików.

openssl x509 -noout -modulus -in certyfikat.crt | openssl md5

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

Jeśli oba hashe MD5 są identyczne, pliki stanowią parę. Jeśli różnią się choćby jednym znakiem, serwer nie wstanie. To u nas w sumie chyba hipoteza z wczoraj bo pewności do tych trendów rynkowych nikt obecnie nie ma o 2025 r., ale w ponad dziewięćdziesięciu procentach przypadków awarii certyfikatów winne jest po prostu pomieszanie plików z różnych lat podczas odnawiania subskrypcji.

Debugowanie aktywnego połączenia sieciowego

OpenSSL posiada wbudowanego klienta s_client. Pozwala on uderzyć bezpośrednio w zdalny serwer i zobaczyć, jak wygląda proces „handshake” protokołu TLS. Pomijasz całkowicie przeglądarkę z jej pamięcią podręczną, która często przekłamuje wyniki diagnozy.

openssl s_client -connect www.google.com:443

Na ekranie przewinie się ściana tekstu. Szukasz informacji o łańcuchu certyfikatów (Certificate chain). Zobaczysz dokładnie, jak serwer przedstawia się światu. Częstym błędem administratorów jest brak konfiguracji certyfikatów pośrednich (Intermediate CA). Przez to przeglądarki mobilne często odrzucają połączenie, podczas gdy desktopowe jakoś sobie radzą, dociągając brakujące ogniwa z własnych magazynów systemowych.

Zarządzanie kryptografią wymaga precyzji. Nie ma tu miejsca na zgadywanie. Używasz OpenSSL, by weryfikować fakty matematyczne, a nie wierzyć obietnicom dostawców hostingu. Sprawdź swoje serwery produkcyjne już dzisiaj, wywołaj s_client na głównym porcie i przeanalizuj output linijka po linijce. Albo czekaj, aż system sam upadnie w piątkowy wieczór przez wygasły plik CRT.

Często zadawane pytania (FAQ)

• Czym różni się SSL od TLS?

  SSL (Secure Sockets Layer) to przestarzały i dziurawy protokół, który nie jest już używany. TLS (Transport Layer Security) to jego nowoczesny, bezpieczny następca. W branży używa się nazwy „certyfikat SSL” wyłącznie ze względów historycznych i przyzwyczajenia użytkowników.

• Czy OpenSSL jest darmowy do zastosowań komercyjnych?

  Tak. Oprogramowanie to jest udostępniane na licencji typu open-source (podwójna licencja OpenSSL i SSLeay). Możesz z niego korzystać bez opłat w projektach komercyjnych, na serwerach firmowych oraz jako część własnego oprogramowania.

• Jak sprawdzić datę ważności certyfikatu z linii komend?

  Wystarczy użyć polecenia: openssl x509 -enddate -noout -in certyfikat.pem. Zwróci ono dokładną datę i godzinę (w strefie GMT), po której certyfikat przestanie być uznawany za zaufany przez klientów sieciowych.

• Co zrobić, gdy zgubiłem hasło do klucza prywatnego?

  Matematyki nie oszukasz. Jeśli zgubiłeś hasło chroniące klucz prywatny, plik jest bezużyteczny. Musisz wygenerować całkowicie nową parę kluczy (nowy plik .key), wygenerować nowy CSR i poprosić wystawcę o ponowne wydanie certyfikatu (reissue).

• Dlaczego system odrzuca mój certyfikat z błędem „unable to get local issuer certificate”?

  Oznacza to, że serwer nie wysyła pełnego łańcucha zaufania (tzw. certyfikatów pośrednich). Musisz połączyć swój certyfikat domeny z certyfikatami urzędu (CA Bundle) w jeden plik tekstowy PEM, używając zwykłego polecenia cat w systemie Linux.

• Czy certyfikaty Let’s Encrypt są tak samo bezpieczne jak płatne?

  Pod względem siły szyfrowania kryptograficznego (poziom techniczny) nie ma absolutnie żadnej różnicy. Różnica polega na braku rozszerzonej walidacji firmy (EV), braku gwarancji finansowych ze strony wystawcy oraz krótszym czasie ważności (tylko 90 dni, co wymusza pełną automatyzację odnowień).

Bibliografia

1. CERT Polska – https://cert.pl
2. NASK – https://nask.pl
3. Ministerstwo Cyfryzacji – https://www.gov.pl/web/cyfryzacja
4. OpenSSL Foundation – https://www.openssl.org
5. Internet Engineering Task Force (IETF) – https://www.ietf.org