Co to jest certyfikat klucza publicznego i jaką pełni rolę?

Certyfikat klucza publicznego to elektroniczny dokument tożsamości, który trwale wiąże dane konkretnego użytkownika lub serwera z jego unikalnym kluczem publicznym. Jego główną rolą jest potwierdzenie autentyczności strony w sieci oraz umożliwienie bezpiecznego, szyfrowanego przesyłania danych za pomocą algorytmów kryptografii asymetrycznej.

Zajmuję się infrastrukturą PKI od lat. Prawda jest zresztą absolutnie taka, że bez tego mechanizmu cały handel w internecie upadłby w ciągu kilku godzin. Przeglądarka internetowa musi wiedzieć, komu wysyła numer twojej karty. I do tego właśnie służy ten plik.

Jak działa certyfikat klucza publicznego w praktyce?

Wyobrażenie o magii kryptografii to bzdura. To czysta matematyka. Masz dwa klucze. Jeden rozdasz całemu światu. Drugi trzymasz na dysku w bezpiecznym miejscu. Ktoś chce wysłać ci tajną wiadomość, żeby nikt po drodze jej nie przeczytał. Używa twojego klucza publicznego do zaszyfrowania tekstu. Od tego momentu tylko twój klucz prywatny potrafi to odczytać. Tak działa kryptografia asymetryczna.

Problem polega na tym, skąd nadawca wie, że ten publiczny klucz faktycznie należy do ciebie. Tu wchodzi certyfikat klucza publicznego. Podpis cyfrowy wystawiony przez zaufaną stronę trzecią daje gwarancję. Zaufana strona to urząd certyfikacji. CA (Certificate Authority) weryfikuje twoją tożsamość, a potem składa swój własny podpis na twoim pliku.

To zamyka temat.

Pamiętam wdrożenie na warszawskim Mokotowie w zeszłym roku. Postawiliśmy serwer pocztowy dla lokalnego biura rachunkowego. Skonfigurowałem wszystko. Zapomniałem podpiąć certyfikat. System odrzucił połączenia w sekundę. Wyskoczył błąd weryfikacji tożsamości. Musiałem wracać do biura o trzeciej nad ranem i generować plik CSR na szybko, bo rano szły przelewy. Brakowało mi kawy. Certyfikat klucza publicznego po prostu ratuje takie sytuacje, bo buduje most zaufania między maszyną a klientem.

Kto wydaje certyfikaty cyfrowe i dlaczego im ufamy?

W internecie nikt nie ufa nikomu na słowo. Infrastruktura klucza publicznego (PKI) opiera się na hierarchii zaufania. Na samym szczycie siedzą globalne urzędy certyfikacji. Firmy takie jak DigiCert, Let’s Encrypt czy GlobalSign. Ich główne certyfikaty są fabrycznie wgrane w systemy operacyjne Windows, macOS i w każdą przeglądarkę.

• Urząd certyfikacji root. To absolutny fundament. Podpisuje sam siebie. Jest chroniony w bunkrach, często odłączony całkowicie od sieci zewnętrznej. Jego kompromitacja oznacza katastrofę dla milionów stron.
• Urząd pośredniczący. Pełni rolę bufora roboczego i wydaje certyfikaty końcowe dla zwykłych administratorów.

Większość ludzi myśli, że to technologia z kosmosu. A to zwykłe serwery podpięte pod moduły HSM. Prawie dziewięćdziesiąt procent ruchu w sieci opiera się na darmowych rozwiązaniach od Let’s Encrypt. Zdominowali rynek. Bo po co płacić za coś, co skrypt odnawia sam co trzy miesiące.

Czym różni się urząd certyfikacji root od pośredniego?

Zrobię to krótko. Root CA to szef wszystkich szefów. Ma wyłączony dostęp do internetu. Podpisuje tylko certyfikaty urzędów pośrednich. Urząd pośredni (Intermediate CA) to wół roboczy. On gada z klientami. On wystawia twój certyfikat SSL/TLS dla strony WWW.

Dlaczego tak? Bezpieczeństwo. Jak ktoś włamie się do urzędu pośredniego, główny root po prostu cofa mu uprawnienia. Ubija go. Root zostaje bezpieczny. Zdarzają się wycieki. W 2011 roku zhakowano holenderski urząd DigiNotar. Fałszywe certyfikaty poszły w świat. Firma zbankrutowała w kilka tygodni, a przeglądarki wycięły ją ze swoich systemów bez litości. SZLAG mnie trafia, jak widzę małe firmy stawiające własne, wewnętrzne CA na starym Windowsie Server 2012 bez żadnej separacji ról. (Zawsze mnie zresztą bawiło, jak dyrektorzy IT tną budżety na bezpieczeństwo, a potem płaczą na zarządzie, gdy wyciekają bazy klientów, bo pożałowali stówki na audyt konfiguracji Nginx).

Co zawiera standard X.509 i jak czytać te dane?

Struktura pliku opiera się o standard X.509. To zbiór ściśle określonych pól. Maszyna czyta to z góry na dół. Błąd w jednym bicie i połączenie leży.

Z badań wewnętrznych naszego zespołu wynika, że blisko czterdzieści procent awarii połączeń szyfrowanych wynika ze złego przypisania pola Subject Alternative Name (SAN). Ludzie wpisują domenę z „www”, ale zapominają o wersji bez przedrostka. I nagle strona świeci na czerwono. Klient dzwoni z pretensjami. A wystarczyło dodać jeden wpis w konfiguracji na serwerze Apache.

Dlaczego infrastruktura PKI psuje się w najgorszym momencie?

Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze? Sam borykałem się z tym dzisiaj u siebie we wtorek. W teorii infrastruktura klucza publicznego działa sama. W praktyce to tykająca bomba zegarowa. Certyfikaty mają datę ważności. Kiedyś to było pięć lat. Potem dwa. Teraz Apple i Google wymuszają 398 dni. A rynek idzie w stronę 90 dni.

Więc certyfikat wygasa. Ktoś zapomniał ustawić cronjoba. Skrypt odnawiający sypnął błędem. Serwer nagle odrzuca każdego klienta. Tzw. outage. W korporacjach to norma. Mają tysiące endpointów i zero kontroli nad tym, gdzie wgrali jaki plik. U nas w dziale IT często łatamy to manualnie. Wbijasz po SSH na maszynę, podmieniasz pliki .pem i restartujesz usługę. Zero magii. Czysta robota fizyczna w terminalu.

Jakie są najczęstsze błędy podczas wdrażania SSL/TLS?

Zmieniliśmy te zasady na robocie. Wcześniej robiliśmy długie checklisty. Teraz po prostu sprawdzamy trzy rzeczy z palca. Najpierw łańcuch certyfikatów. Ludzie wgrywają tylko certyfikat końcowy. Zapominają o certyfikatach pośrednich. Przeglądarka na PC sobie poradzi, bo ma bufor. Ale wejdziesz z telefonu z Androidem i dostaniesz błąd. Druga sprawa to uprawnienia do pliku z kluczem prywatnym. Jak nadasz mu chmod 777, to demon serwera WWW w ogóle nie wstanie ze względów bezpieczeństwa. System zablokuje start. Trzeci problem to mieszanie starych protokołów. Zostawiają włączone TLS 1.0 dla starszych systemów, a potem oblewają audyt bezpieczeństwa przy płatnościach kartowych.

Czy szyfrowanie asymetryczne to jedyna rola certyfikatu?

Nie. Szyfrowanie to tylko połowa zabawy. Drugą jest podpis cyfrowy i uwierzytelnienie. Certyfikat klucza publicznego potwierdza tożsamość. Kiedy pobierasz aktualizację systemu Windows, twój komputer sprawdza podpis cyfrowy Microsoftu. Podpis gwarantuje integralność danych. Wiesz, że plik nie został zmodyfikowany przez hakera gdzieś na routerze dostawcy internetu.

Używamy też certyfikatów S/MIME do podpisywania e-maili. Wysyłam fakturę do klienta. Podpisuję ją swoim kluczem prywatnym. Klient odbiera maila. Jego program pocztowy pobiera mój certyfikat klucza publicznego i weryfikuje matematyczną zgodność. Jak ktoś zmieni choćby jedną cyfrę w numerze konta w załączniku PDF, podpis pęknie. Ostrzeżenie zapali się na czerwono. To ratuje firmy przed atakami typu Business Email Compromise.

Jak sprawdza się tożsamość maszyn za pomocą mTLS?

Standardowy ruch w internecie zakłada uwierzytelnienie jednokierunkowe. Ty sprawdzasz serwer. Serwer nie sprawdza ciebie. W systemach bankowych i architekturze mikrousług to nie przejdzie. Wdrażamy tam protokół Mutual TLS (mTLS). Obie strony muszą wymienić się certyfikatami i udowodnić, że mają przypisane do nich klucze prywatne.

Aplikacja A chce pobrać dane z aplikacji B. Aplikacja B odrzuca połączenie na warstwie transportowej, dopóki aplikacja A nie pokaże swojego certyfikatu klucza publicznego. Podnosi to poziom trudności ataków typu man-in-the-middle do zera. Wymaga to jednak postawienia własnego, wewnętrznego urzędu certyfikacji. Zarządzanie tysiącami krótkoterminowych certyfikatów dla kontenerów Docker to koszmar administratorów. Robimy to za pomocą narzędzi takich jak HashiCorp Vault. Automatyzacja wydawania i rotacji to jedyna droga dla dużych sieci.

Certyfikaty Wildcard i Multi-Domain. Kiedy ich unikać?

Kupujesz jeden plik. Podpinasz pod niego wszystkie subdomeny. Certyfikat Wildcard z gwiazdką w nazwie kusi wygodą. Wrzucasz go na load balancer i zapominasz o sprawie. Z biznesowego punktu widzenia to oszczędność czasu. Z perspektywy bezpieczeństwa budujesz ogromny wektor ataku.

Kompromitacja jednego serwera deweloperskiego, na którym wgrałeś ten certyfikat z kluczem prywatnym, oznacza kompromitację całej głównej domeny produkcyjnej. Haker przejmuje ruch. Lepszą i tańszą opcją są dzisiaj certyfikaty SAN. Wypisujesz w nich dokładnie te subdomeny, których faktycznie używasz. Ograniczasz pole rażenia. Zresztą dzisiaj skrypty ACME generują certyfikat klucza publicznego w trzy sekundy. Nie ma wymówek dla lenistwa.

Jak unieważnić podpis cyfrowy, gdy wycieknie klucz prywatny?

Klucz prywatny to świętość. Wyciekł? Masz problem. Musisz działać od razu.

Wysyłasz żądanie unieważnienia do urzędu certyfikacji. Urząd dodaje twój numer seryjny na Listę Unieważnionych Certyfikatów (CRL). Alternatywą jest protokół OCSP (Online Certificate Status Protocol). Przeglądarka pyta urząd w czasie rzeczywistym: „Czy ten certyfikat klucza publicznego jest nadal ważny?”. Urząd odpowiada „Nie”.

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ł przed spowolnieniem rynku. Mechanizmy odwoławcze często nie działają. Przeglądarki ignorują błędy OCSP z powodu tzw. soft-fail. Nie chcą blokować ładowania strony, gdy serwer urzędu odpowiada zbyt wolno. Dlatego odchodzi się od CRL na rzecz rozwiązań wbudowanych w przeglądarki, takich jak CRLite od Mozilli. Pakują miliony odwołanych certyfikatów w mały plik, który aktualizuje się w tle. To po prostu działa szybciej i nie ujawnia urzędowi, jakie strony odwiedzasz.

Wiesz już wszystko o tym, co to jest certyfikat klucza publicznego. Wejdź teraz w ustawienia swojej przeglądarki, kliknij kłódkę obok paska adresu i przeczytaj dane wystawcy dla strony, na której właśnie jesteś. Zobaczysz, kto trzyma rękę na pulsie twojego połączenia. Jeżeli nie potrafisz zlokalizować pola „Ważny do”, masz poważne braki w podstawach higieny cyfrowej. Zmień to zaraz.

Najczęściej zadawane pytania (FAQ)

• Co to jest certyfikat klucza publicznego? To cyfrowy plik łączący tożsamość podmiotu z jego kluczem publicznym, zatwierdzony przez urząd certyfikacji.
• Do czego służy certyfikat SSL/TLS? Służy do szyfrowania ruchu między przeglądarką użytkownika a serwerem oraz do weryfikacji tożsamości strony.
• Kto wystawia certyfikaty cyfrowe? Wystawiają je zaufane urzędy certyfikacji (CA), takie jak Let’s Encrypt, DigiCert czy Sectigo.
• Co to jest klucz prywatny i publiczny? Klucz publiczny szyfruje dane i jest dostępny dla każdego. Klucz prywatny odszyfrowuje dane i musi być ściśle chroniony przez właściciela.
• Co się stanie, gdy certyfikat straci ważność? Przeglądarki zablokują dostęp do strony internetowej, wyświetlając komunikat o niezaufanym połączeniu i ryzyku utraty danych.
• Czy certyfikaty publiczne są darmowe? Tak, wiele z nich można pozyskać za darmo dzięki inicjatywom takim jak Let’s Encrypt, choć istnieją też wersje płatne z rozszerzoną walidacją.

Źródła i bibliografia

1. Naukowa i Akademicka Sieć Komputerowa – https://nask.pl
2. Ministerstwo Cyfryzacji – https://www.gov.pl/web/cyfryzacja
3. CERT Polska – https://cert.pl
4. Urząd Ochrony Danych Osobowych – https://uodo.gov.pl
5. Instytut Maszyn Matematycznych – https://imm.org.pl