Jak wygenerować certyfikat SSL: przewodnik po OpenSSL krok po kroku (self-signed i CSR)

Każdy certyfikat SSL/TLS zaczyna się tak samo: od klucza prywatnego i requesta. Niezależnie od tego, czy stawiasz lokalny serwer deweloperski, testujesz mTLS między dwiema wewnętrznymi usługami, czy występujesz o certyfikat do publicznego CA — te same kilka komend OpenSSL stanowi podstawę wszystkiego.

Ten przewodnik przechodzi przez wszystkie z nich — od najszybszego one-linera po pełny CSR z Subject Alternative Names.

TL;DR: najszybszy sposób na wygenerowanie certyfikatu

Jeśli potrzebujesz działającego certyfikatu tu i teraz, do lokalnego developmentu albo wewnętrznego środowiska testowego:

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes -subj "/CN=api.auth-test.pl"

Ta jedna komenda generuje 2048-bitowy klucz prywatny RSA (key.pem) oraz certyfikat self-signed (cert.pem) ważny przez 365 dni, bez hasła (-nodes). Wystarczy, żeby zadziałało curl -k albo żeby przejść przez ostrzeżenie w przeglądarce. Nie wystarczy do niczego, co przeglądarka albo restrykcyjny klient TLS musi zaufać automatycznie — po to czytaj dalej.

Co faktycznie potrzebujesz, zanim zaczniesz

• Zainstalowany OpenSSL (openssl version — jest domyślnie na macOS i większości dystrybucji Linuksa; na Windowsie zainstaluj przez Git Bash albo WSL).
• Nazwę hosta lub adres IP, dla którego certyfikat będzie faktycznie serwowany. We wszystkich przykładach poniżej używamy api.auth-test.pl — podmień na własną domenę albo nazwę wewnętrznej usługi.
• Jasność co do tego, co właściwie budujesz: certyfikat self-signed (sam jesteś swoim trust anchorem — OK do użytku wewnętrznego/deweloperskiego) czy CSR, który ma podpisać CA — publiczne albo prywatne (potrzebne wszędzie tam, gdzie musi Ci zaufać klient, nad którym nie masz kontroli).

Krok 1: Wygeneruj klucz prywatny

Wszystko, co dalej, zależy od tego klucza — traktuj go jak sekret, bo nim jest.

openssl genrsa -out key.pem 2048

2048-bitowy RSA to bezpieczny domyślny wybór. Jeśli chcesz mniejszych, szybszych kluczy i nie potrzebujesz kompatybilności z bardzo starymi klientami, dobrą alternatywą jest klucz EC:

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

Krok 2: Wygeneruj certyfikat self-signed

Mając klucz, możesz od razu podpisać nim certyfikat sam:

openssl req -new -x509 -key key.pem -out cert.pem -days 365 -subj "/CN=api.auth-test.pl"

To właściwe narzędzie do lokalnego developmentu, wewnętrznych środowisk testowych i mTLS między usługami, nad którymi masz pełną kontrolę i możesz sam rozdystrybuować CA/certyfikat. To nie jest właściwe narzędzie do niczego, czemu przeglądarka albo zewnętrzny klient muszą zaufać bez ręcznego obejścia — certyfikaty self-signed nie mają za sobą łańcucha zaufania, który jakikolwiek klient rozpozna od razu.

Krok 3: Wygeneruj CSR, żeby certyfikat podpisało CA

Jeśli certyfikatowi musi zaufać coś, nad czym nie masz kontroli — publiczna strona, klient partnera, sklep z aplikacjami — potrzebujesz Certificate Signing Request (CSR) zamiast certyfikatu self-signed. Generujesz CSR, a klucz prywatny zostaje u Ciebie; do CA trafia tylko CSR.

openssl req -new -key key.pem -out request.csr -subj "/CN=api.auth-test.pl"

CSR zawiera Twój klucz publiczny i tożsamość, dla której występujesz o certyfikat. Wyślij request.csr do swojego CA — publicznego (Let’s Encrypt, DigiCert itd.) albo wewnętrznego/prywatnego CA Twojej organizacji — w odpowiedzi dostaniesz podpisany cert.pem. Klucz prywatny w ogóle nie opuszcza Twojej maszyny.

Krok 4: Dodaj Subject Alternative Names (SAN)

Od Chrome 58 (2017) przeglądarki całkowicie ignorują pole Common Name przy walidacji nazwy hosta i wymagają zamiast tego pasującego Subject Alternative Name. Certyfikat z samym CN i bez SAN nie przejdzie walidacji w żadnej nowoczesnej przeglądarce — to najczęstszy powód, dla którego “działająca” komenda OpenSSL generuje certyfikat, któremu nikt tak naprawdę nie ufa.

Samo -subj nie ustawi SAN, więc potrzebny jest mały plik konfiguracyjny:

cat > san.cnf << 'EOF'
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no

[req_distinguished_name]
CN = api.auth-test.pl

[v3_req]
subjectAltName = @alt_names

[alt_names]
DNS.1 = api.auth-test.pl
DNS.2 = *.auth-test.pl
EOF

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes -config san.cnf

Te same bloki [v3_req] / [alt_names] mają zastosowanie, jeśli zamiast certyfikatu self-signed generujesz CSR — wystarczy podmienić ostatnią komendę na tę z Kroku 3 i tam też dodać -config san.cnf.

Krok 5: Zweryfikuj, co faktycznie wygenerowałeś

Zanim podepniesz certyfikat gdziekolwiek, sprawdź, czy zrobił to, czego oczekujesz:

# Pełny, czytelny dla człowieka zrzut
openssl x509 -in cert.pem -noout -text

# Sam okres ważności
openssl x509 -in cert.pem -noout -dates

# Subject, issuer i SAN na pierwszy rzut oka
openssl x509 -in cert.pem -noout -subject -issuer -ext subjectAltName

Jeśli subjectAltName nie pojawia się w wyniku tej ostatniej komendy, wróć do Kroku 4 — taki certyfikat zostanie odrzucony przez każdą nowoczesną przeglądarkę i restrykcyjnego klienta TLS.

Najczęstsze błędy

• Brak SAN, tylko CN. Opisane wyżej — to najczęstsza przyczyna certyfikatu, który generuje się bez błędów, ale realnie nie działa.
• 1024-bitowe klucze RSA. Przestarzałe od lat; większość nowoczesnych narzędzi ich w ogóle nie zaakceptuje.
• Klucze prywatne trafiające do gita. key.pem nigdy nie powinien opuścić maszyny albo vaulta, na którym został wygenerowany. Dodaj *.pem i *.key do .gitignore, zanim cokolwiek wygenerujesz.
• Brak śledzenia terminu ważności. Certyfikat self-signed albo z wewnętrznego CA wygasa dokładnie tak samo jak publiczny — różnica jest taka, że żaden klient ACME ani panel CA Cię o tym nie ostrzeże. Więcej o tym poniżej.

Wygenerowanie jednego certyfikatu jest łatwe. Zarządzanie setkami — już nie.

Wszystko powyżej zajmuje z pół minuty, gdy zrobisz to kilka razy. Prawdziwy koszt pojawia się później: która usługa używa którego certyfikatu, w jakim jest środowisku i ile dni mu zostało — pomnożone przez każdą wewnętrzną usługę, każde środowisko i każde prywatne CA, które postawiłeś.

Dokładnie tę lukę wypełnia Certyfizer. Ten sam flow generuj → dostarcz → monitoruj z tego przewodnika dostępny jest jako jedno kliknięcie w interfejsie — certyfikat od razu trafia na listę, Twój pipeline CI/CD może go pobrać automatycznie, a Certyfizer pilnuje terminu ważności, żeby nie był niespodzianką o 3 nad ranem.