Czym jest infrastruktura klucza publicznego (PKI) – jak działa SSL, TLS i certyfikaty X.509

• uwierzytelniania tożsamości podmiotów (serwery, użytkownicy, urządzenia),
• zapewnienia poufności i integralności komunikatów poprzez szyfrowanie,
• niezaprzeczalności (non-repudiation) operacji podpisu cyfrowego,
• zarządzania cyklem życia certyfikatów: wydawanie, odnawianie, unieważnianie.

Właśnie dlatego PKI jest fundamentem funkcjonowania protokołów SSL/TLS, podpisów cyfrowych, S/MIME oraz wielu mechanizmów uwierzytelniania urządzeń w środowiskach korporacyjnych i IoT.

Historia i rozwój PKI

Podstawy kryptografii asymetrycznej opracowali w latach 70. tacy badacze jak Whitfield Diffie, Martin Hellman, Ronald Rivest,
Adi Shamir i Leonard Adleman. Ich prace umożliwiły praktyczne wykorzystanie par kluczy: publicznego i prywatnego. W latach 90. kluczową rolę odegrał
Taher Elgamal, który w Netscape wprowadził protokół SSL; to z kolei stało się bazą dla dalszego rozwoju TLS (Transport Layer Security).

W kolejnych dekadach PKI ewoluowało od prostych rozwiązań do rozbudowanych ekosystemów z wieloma warstwami zaufania, mechanizmami audytu, HSM (Hardware Security Module) oraz usługami zarządzania kluczami w chmurze.

Co to jest SSL i TLS?

SSL (Secure Sockets Layer) i jego następca TLS (Transport Layer Security) to protokoły kryptograficzne służące do ustanawiania
szyfrowanych i uwierzytelnionych kanałów komunikacji pomiędzy klientem a serwerem. Mimo że termin „SSL” jest nadal powszechnie używany, oficjalnie
powinno się odnosić do TLS, w szczególności do wersji TLS 1.2 i TLS 1.3.

Natomiast najnowsza istotna specyfikacja to TLS 1.3 (RFC 8446), która zapewnia poprawę bezpieczeństwa i wydajności (mniej rund w handshake, lepsza prywatność).

Certyfikat SSL/TLS – cyfrowa tożsamość serwera

Certyfikat SSL/TLS jest dokumentem cyfrowym (zwykle w formacie X.509), który łączy tożsamość podmiotu z jego kluczem publicznym.
Zawiera on m.in.: nazwę domeny (CN / SAN), organizację (O), lokalizację, okres ważności oraz podpis wystawcy (CA).

Jednakże tylko certyfikat podpisany przez zaufany urząd certyfikacji (CA) zostanie uznany przez przeglądarki i systemy operacyjne za ważny.
W tym celu weryfikacja certyfikatu odbywa się podczas procesu SSL/TLS handshake i jest kluczowa dla ustalenia zaufania do serwera.

ALT dla obrazu schematu certyfikatu: alt="certyfikat X.509 – struktura i pola CN, O, SAN, okres ważności"

Jak działa uzgadnianie SSL/TLS (SSL/TLS handshake)?

SSL/TLS handshake to sekwencja komunikatów pomiędzy klientem a serwerem służąca do:

• wyboru wersji protokołu i zestawu szyfrów (cipher suite),
• weryfikacji certyfikatu serwera (i opcjonalnie klienta),
• wymiany parametrów kryptograficznych i ustanowienia klucza sesyjnego (session key).

W praktyce handshake wykorzystuje asymetryczne szyfrowanie do bezpiecznego ustanowienia wspólnego klucza sesyjnego, a dalsza komunikacja używa szyfrowania symetrycznego (wydajniejszego). W celu poprawy wydajności i szybkości w TLS 1.3 wiele operacji zostało zoptymalizowanych, m.in. skrócono liczbę rund (round trips) niezbędnych do ukończenia SSL/TLS handshake.

Szyfrowanie asymetryczne i symetryczne – podział ról

Szyfrowanie asymetryczne (public-key cryptography) operuje na parach kluczy: publicznym (może być swobodnie publikowany) i prywatnym (tajny).
Dlatego jako bezpieczniejszy rodzaj szyfrowania, służy do uwierzytelniania oraz bezpiecznej wymiany kluczy sesyjnych.

Szyfrowanie symetryczne stosuje pojedynczy klucz (ten sam do szyfrowania i deszyfrowania), jest znacznie szybsze i używane do szyfrowania strumienia danych
po ustanowieniu sesji.

Warto, abyś wiedział, że typowych algorytmów symetrycznych zalicza się AES (z trybami GCM lub CBC), a asymetryczne przykłady to RSA czy krzywe eliptyczne (ECC).

Natomiast obecnie preferowane są klucze publiczne o długości co najmniej 2048 bitów dla RSA lub stosowanie ECC (np. P-256) dla mniejszego rozmiaru i podobnego poziomu bezpieczeństwa.

Szyfrowanie e-maili: certyfikaty S/MIME

PKI umożliwia również zabezpieczanie poczty elektronicznej za pomocą certyfikatów S/MIME. Dzięki nim możliwe jest:

• podpisywanie wiadomości (integralność i niezaprzeczalność),
• szyfrowanie treści (poufność pomiędzy nadawcą a odbiorcą),
• weryfikowanie tożsamości nadawcy przez odbiorcę.

W praktyce, aby odczytać wiadomość zaszyfrowaną S/MIME, odbiorca musi posiadać odpowiedni certyfikat (klucz prywatny) odpowiadający parze kluczy nadawcy.

Czym jest certyfikat X.509?

X.509 to standard określający format certyfikatów używanych w PKI. Certyfikat X.509 zawiera:

• nazwę zwyczajową (CN) i/lub SAN (Subject Alternative Names),
• dane organizacji (O), lokalizację (L, ST, C),
• klucz publiczny i okres ważności,
• podpis cyfrowy urzędu certyfikacji (CA).

Uwaga: od 1 września 2022 r. pole jednostki organizacyjnej (OU) zostało wycofane z praktyk dotyczących niektórych implementacji X.509 (głosowanie SC47V2). Stąd zalecane jest minimalizowanie użycia OU w nowych certyfikatach.

Ekosystem PKI – role i elementy

Główne komponenty ekosystemu PKI to:

1. Urząd certyfikacji (CA) – wystawia certyfikaty i podpisuje je; utrzymuje zaufane łańcuchy certyfikatów.
2. Urząd rejestracji (RA) – weryfikuje tożsamość wnioskodawcy przed wystawieniem certyfikatu.
3. Subskrybent (Subject) – właściciel certyfikatu (np. domena, użytkownik, urządzenie).
4. Strona ufająca (Relying Party) – przeglądarka, system lub aplikacja, która weryfikuje certyfikat i ufa jego wystawcy.

Dodatkowe elementy obejmują magazyny certyfikatów (trust stores), listy unieważnień (CRL) oraz protokół OCSP (Online Certificate Status Protocol) do sprawdzania statusu certyfikatów w trybie online.

Prywatny PKI – kiedy warto go użyć?

Organizacje często wdrażają prywatne PKI dla środowisk zamkniętych, takich jak wewnętrzne serwery, systemy zarządzania urządzeniami, IoT lub PKI w chmurze do ochrony komunikacji wewnętrznej.
Wynika to z faktu, że prywatny PKI daje pełną kontrolę nad politykami wydawania certyfikatów, cyklem życia kluczy oraz procesami audytu, ale wymaga też odpowiedniej administracji i zabezpieczeń (np. HSM).

Do typowych scenariuszy użycia prywatnego PKI można zaliczyć: certyfikację urządzeń w środowisku korporacyjnym, automatyczne wydawanie certyfikatów dla mikroserwisów, wewnętrzny VPN oraz komunikację między komponentami w klastrze Kubernetes.

PKI, SSL/TLS a znane problemy bezpieczeństwa

Choć PKI jest centralnym elementem bezpieczeństwa, nie chroni przed wszystkimi zagrożeniami:

• Ataki na słabe algorytmy lub przestarzałe protokoły (np. SSLv3, TLS 1.0/1.1).
• Ataki na urzędy certyfikacji (CA) — historia pokazuje, że kompromitacja CA umożliwia wystawienie fałszywych certyfikatów.
• Błędy implementacji protokołów (ROBOT, LogJam, POODLE, BEAST), które eksploatują luki w negocjacji i algorytmach.

Z tego względu operatorzy powinni:

• stosować aktualne wersje TLS (1.2+; preferowany TLS 1.3),
• konfigurować silne zestawy szyfrów (cipher suites) i preferować AEAD (np. AES-GCM, ChaCha20-Poly1305),
• wykonywać testy bezpieczeństwa (np. SSL Labs, skanery konfiguracji TLS),
• korzystać z HSM do przechowywania kluczy prywatnych i stosować procedury audytu oraz rotacji kluczy.

Przykłady zastosowań PKI

PKI znajduje zastosowanie w wielu scenariuszach, m.in.:

• HTTPS dla stron internetowych i API,
• podpisywanie kodu (code signing),
• podpisywanie dokumentów elektronicznych (np. PDF),
• szyfrowanie i podpisy e-mail (S/MIME),
• uwierzytelnianie urządzeń i użytkowników w systemach Enterprise,
• ochrona komunikacji IoT i urządzeń edge.

Zalecenia wdrożeniowe i checklist

Krótka lista kontrolna przed uruchomieniem serwisu z certyfikatem PKI powinna obejmować:

• Wydanie certyfikatu od zaufanego CA lub poprawne skonfigurowanie prywatnego CA.
• Weryfikację konfiguracji TLS (obsługa tylko TLS 1.2/1.3; wyłączenie SSLv2/SSLv3).
• Włączenie OCSP stapling, wszędzie tam gdzie to możliwe.
• Regularną rotację kluczy i odnawianie certyfikatów przed ich wygaśnięciem.
• Monitorowanie list CRL/OCSP oraz automatyczne reagowanie na incydenty.
• Użycie HSM do przechowywania kluczy prywatnych krytycznych systemów.

Podsumowanie

PKI jest niezbędnym elementem współczesnego bezpieczeństwa sieciowego, ponieważ umożliwia uwierzytelnienie, szyfrowanie i integralność komunikacji.
Wiedza o certyfikatach X.509, mechanizmie SSL/TLS oraz roli CA/RA jest kluczowa dla administratorów systemów, inżynierów bezpieczeństwa i architektów rozwiązań.

Dlatego też wdrożenie PKI wymaga starannego zarządzania cyklem życia certyfikatów, wyboru bezpiecznych algorytmów i odpowiedniej infrastruktury (np. HSM, procesy audytu).