Certyfikat pośredni (Intermediate CA) – co to jest i dlaczego jest potrzebny?

Certyfikat pośredni (Intermediate CA) to plik kryptograficzny, który działa jak most łączący certyfikat SSL/TLS serwera z głównym urzędem certyfikacji (Root CA). Jest potrzebny, żeby chronić główny klucz prywatny przed atakami z sieci, pozwalając na delegowanie procesu wystawiania podpisów cyfrowych na niższe szczeble infrastruktury PKI. Przeglądarki internetowe ufają Twojej stronie tylko wtedy, gdy potrafią prześledzić ten ścisły łańcuch powiązań od serwera aż do korzenia.

Główny urząd certyfikacji ma ogromny problem biznesowy i technologiczny. Jego klucz prywatny gwarantuje bezpieczeństwo setek tysięcy domen. Jeśli hakerzy przejmą ten ciąg znaków, cały system zaufania w internecie upada w ułamku sekundy. Prawda jest zresztą absolutnie taka, że nikt przy zdrowych zmysłach nie trzyma głównego klucza na serwerze podłączonym do internetu. Root CA siedzi w stalowym sejfie. Odłączony od prądu. Odłączony od sieci. Roboty na froncie wykonują właśnie certyfikaty pośrednie.

Dlaczego łańcuch zaufania SSL pęka bez certyfikatów pośrednich?

Zaufanie w internecie nie bierze się znikąd. Systemy operacyjne Windows, macOS czy Linux mają wbudowane własne magazyny zaufanych urządzeń głównych. To fizyczne pliki na Twoim dysku. Przeglądarka weryfikuje każdy certyfikat end-entity (ten przypisany do Twojej domeny) sprawdzając, czy podpisał go ktoś z tej wąskiej listy. Certyfikat pośredni to dowód tożsamości wystawiony przez Root CA dla podwykonawcy. Podwykonawca z kolei wystawia certyfikat dla Ciebie.

Sam się nad tym borykałem dzisiaj u siebie we wtorek. Wdrażaliśmy nowy serwer Nginx dla małej hurtowni na warszawskim Targówku. Banalna sprawa na kwadrans pracy. Wrzucasz certyfikat, podpinasz konfigurację i idziesz na kawę. O trzeciej nad ranem dostaję na Slacku zrzut ekranu od klienta. Na starych telefonach z Androidem wyskakuje wielki czerwony błąd prywatności NET::ERR_CERT_AUTHORITY_INVALID. Zapomniałem dokleić łańcucha pośredniego do pliku fullchain.pem. Przez taki głupi błąd oprogramowanie nie potrafiło dojść po sznurku do urzędu głównego. Musiałem zalogować się po SSH i ręcznie sklejać pliki w terminalu za pomocą komendy cat. Wkurzający syf. Tak to jednak wygląda na produkcji, gdy pominiesz plik CA Bundle.

Bez wysłania przez serwer certyfikatu pośredniego przeglądarka zatrzymuje ładowanie strony. Użytkownik widzi ostrzeżenie o niebezpieczeństwie. Konwersja w sklepie internetowym spada do zera. A administrator musi szukać brakującego pliku na stronach wystawcy.

Jak dokładnie działa architektura PKI w praktyce?

Infrastruktura klucza publicznego (PKI) opiera się na twardej hierarchii. Zamiast budować płaską strukturę, inżynierowie podzielili odpowiedzialność na mniejsze fragmenty. Ten podział ma ogromny sens techniczny.

• Root CA (Główny Urząd Certyfikacji): Fundament. Wystawia certyfikaty tylko dla urzędów pośrednich. Jego klucz ważny jest zazwyczaj przez 10 do 25 lat. Działa w środowisku air-gapped.
• Intermediate CA (Urząd Pośredni): Warstwa robocza. Otrzymuje prawo do podpisywania certyfikatów dla klientów końcowych. Ważność tego dokumentu to przeważnie 3 do 5 lat. Jeśli zostanie skompromitowany, Root CA po prostu go unieważnia.
• End-Entity Certificate (Certyfikat Końcowy): Plik instalowany na Twoim serwerze. Służy do szyfrowania ruchu HTTPS dla konkretnej domeny. Obecnie ważny maksymalnie 398 dni.
• Certificate Revocation List (CRL) i OCSP: Mechanizmy sprawdzające w czasie rzeczywistym, czy dany certyfikat pośredni nie został przedwcześnie wycofany z obiegu z powodu naruszenia bezpieczeństwa.

Root CA może wygenerować kilka różnych certyfikatów pośrednich dla różnych celów. Jeden obsługuje podpisywanie kodu oprogramowania. Drugi wystawia zwykłe certyfikaty DV (Domain Validation) dla blogów. Trzeci weryfikuje organizacje w procesie EV (Extended Validation) dla banków. Separacja obowiązków zmniejsza ryzyko. Jeśli hakerzy przełamią zabezpieczenia serwera wydającego certyfikaty DV, banki pozostają całkowicie bezpieczne.

Gdzie leży fizycznie klucz prywatny Root CA i po co ta cała izolacja?

Sprzętowe moduły bezpieczeństwa (HSM) to fizyczne urządzenia przypominające serwery rackowe. Przechowują klucze kryptograficzne w sposób uniemożliwiający ich wyeksportowanie. Urząd główny trzyma swój sprzęt w bunkrach z kontrolą dostępu na odcisk palca i skan siatkówki. Wydanie nowego certyfikatu pośredniego wymaga fizycznej obecności kilku osób z fizycznymi kartami inteligentnymi.

To procedura długa i kosztowna. Używanie jej do wystawiania certyfikatu dla każdej małej strony na WordPressie całkowicie zablokowałoby rozwój internetu. Certyfikat pośredni rozwiązuje ten problem. Urząd główny podpisuje go raz na kilka lat podczas formalnej ceremonii. Następnie plik ten trafia na serwery online (Intermediate CA), które automatycznie, w ułamku sekundy, wydają certyfikaty końcowe przez protokół ACME.

Co się stanie, gdy serwer nie wyśle certyfikatu pośredniego do przeglądarki?

Zasada działania protokołu TLS wymusza na serwerze dostarczenie pełnego dowodu tożsamości podczas nawiązywania połączenia (handshake). Serwer wysyła swój certyfikat oraz wszystkie niezbędne certyfikaty pośrednie. Przeglądarka ma w systemie tylko certyfikat Root. Musi połączyć kropki.

Brak pliku pośredniego wymusza na przeglądarce próbę jego samodzielnego pobrania za pomocą rozszerzenia AIA (Authority Information Access). To pole zaszyte w certyfikacie końcowym, wskazujące adres URL do pobrania brakującego ogniwa. Problem polega na tym, że nie wszystkie przeglądarki to robią. Firefox odrzuca takie połączenia dla zasady. Narzuca to administratorom serwerów obowiązek poprawnej konfiguracji łańcucha. Jeśli tego nie zrobisz, stracisz klientów.

Zgubiony certyfikat Intermediate CA na serwerze Apache i Nginx

Błędy konfiguracyjne zdarzają się bez przerwy. W zdecydowanej większości wynikają z pośpiechu. Administrator wykupuje certyfikat. Dostaje w mailu plik zip. Wypakowuje go. Widzi plik domena.crt i wgrywa go na serwer. Ignoruje plik oznaczony jako ca-bundle.crt lub intermediate.pem. To błąd. Poważny.

W serwerze Nginx musisz połączyć swój certyfikat z certyfikatem pośrednim w jeden plik. Używasz komendy w systemie Linux. Najpierw zawartość Twojego certyfikatu, zaraz pod nim zawartość certyfikatu pośredniego. Kolejność ma ogromne znaczenie. Jeśli odwrócisz kolejność, Nginx po prostu nie wstanie i wyrzuci błąd przy restarcie usługi. W Apache od wersji 2.4 używasz jednej dyrektywy SSLCertificateFile wskazującej na taki sam połączony plik. W starszych wersjach Apache istniała osobna dyrektywa SSLCertificateChainFile, ale wycofano ją dla uproszczenia konfiguracji.

Skąd przeglądarka wie, że ma ufać wystawcy?

Google Chrome, Mozilla Firefox i Apple prowadzą własne programy zaufania (Root Store Programs). Zanim certyfikat głównego urzędu trafi do systemu operacyjnego, firma audytorska sprawdza procedury bezpieczeństwa wystawcy. Audyt WebTrust kosztuje dziesiątki tysięcy dolarów. Trwa miesiącami.

Dopiero po zaliczeniu rygorystycznych testów, plik Root CA ląduje w aktualizacji Windowsa czy macOS. Od tego momentu każdy certyfikat pośredni podpisany przez ten Root CA automatycznie zyskuje zaufanie miliardów urządzeń na świecie. To system oparty na ślepym zaufaniu do matematyki i procedur. Jeśli firma wydająca certyfikaty złamie zasady, przeglądarki wykreślają ją z listy. Tak stało się z firmą Symantec kilka lat temu. Google usunęło ich certyfikaty z Chrome, zmuszając miliony stron do zmiany dostawcy SSL.

Czy da się obejść instalację paczki CA Bundle?

Nie. Absolutnie nie ma takiej możliwości. Próba ominięcia tego kroku kończy się zawsze komunikatem o braku zabezpieczeń. Czasami administratorzy testują stronę na swoim komputerze i widzą zieloną kłódkę. Myślą, że zrobili wszystko dobrze. Wrzucają stronę na produkcję.

Zielona kłódka u nich na komputerze to wynik cache’owania. Ich system operacyjny pobrał i zapisał certyfikat pośredni podczas odwiedzania innej strony w przeszłości. System skleił łańcuch z pamięci podręcznej. Obcy klient, wchodzący na witrynę po raz pierwszy, dostanie błąd w twarz. Dlatego tak twardo wymaga się sprawdzania konfiguracji zewnętrznymi narzędziami, takimi jak SSL Labs. Narzędzie to symuluje połączenia z dziesiątek różnych urządzeń i od razu wytyka braki w łańcuchu zaufania, pokazując czerwony komunikat „Chain issues: Incomplete”.

Twardy audyt bezpieczeństwa i unieważnianie certyfikatów (CRL i OCSP)

Architektura pośrednia ma jedną potężną zaletę na wypadek awarii. Pozwala na szybkie odcięcie zakażonej tkanki. Jeśli haker włamie się na serwery urzędu wystawiającego (Intermediate CA), Root CA publikuje informacje o unieważnieniu w systemie CRL (Certificate Revocation List) oraz przez protokół OCSP (Online Certificate Status Protocol).

W 2011 roku holenderski urząd DigiNotar padł ofiarą ataku. Hakerzy wygenerowali fałszywe certyfikaty dla domen Google, Yahoo i Skype. Mogli podsłuchiwać ruch użytkowników w Iranie. Gdy sprawa wyszła na jaw, przeglądarki natychmiast unieważniły certyfikaty pośrednie DigiNotar. Firma zbankrutowała w ciągu kilku tygodni. Ten incydent udowodnił, że podział na Root i Intermediate to nie jest wymysł teoretyków, ale brutalna konieczność rynkowa zabezpieczająca przed globalnym paraliżem.

Współczesne serwery WWW używają techniki zwanej OCSP Stapling. Zamiast zmuszać przeglądarkę klienta do odpytywania urzędu certyfikacji o status unieważnienia certyfikatu pośredniego przy każdej wizycie, serwer sam pobiera ten dowód i „zszywa” go z główną odpowiedzią TLS. To oszczędza czas. Przyspiesza ładowanie strony. Zmniejsza obciążenie infrastruktury urzędów. Wymaga jednak prawidłowej konfiguracji na poziomie wirtualnego hosta.

Zostawiam was z prostym wyzwaniem. Zalogujcie się dzisiaj na swoje serwery produkcyjne. Uruchomcie test na zewnętrznym skanerze SSL i sprawdźcie, czy wasz serwer faktycznie wysyła pełny łańcuch, czy tylko bazujecie na szczęściu i cache’u przeglądarek klientów. Wpiszcie w terminalu polecenie testujące połączenie OpenSSL i przeczytajcie logi. Jeden brakujący plik dzieli was od potężnego spadku ruchu w sklepie.

Często zadawane pytania (FAQ)

• Co to jest certyfikat pośredni (Intermediate CA)?
  To plik kryptograficzny łączący certyfikat SSL Twojej domeny z głównym certyfikatem Root CA wbudowanym w system operacyjny. Weryfikuje autentyczność wystawcy.
• Gdzie mogę pobrać certyfikat pośredni dla mojej strony?
  Dostajesz go zazwyczaj w paczce .zip od firmy, w której kupiłeś certyfikat SSL. Często nazywa się ca-bundle.crt lub intermediate.pem.
• Co oznacza błąd „Incomplete certificate chain”?
  Oznacza, że Twój serwer WWW wysyła do przeglądarki użytkownika tylko certyfikat domeny, całkowicie pomijając wysłanie certyfikatu pośredniego.
• Czy mogę używać certyfikatu SSL bez pliku Intermediate?
  Teoretycznie serwer się uruchomi, ale w praktyce większość nowych użytkowników zobaczy ostrzeżenie o braku prywatności i zablokowane połączenie.
• Jak połączyć certyfikat z certyfikatem pośrednim w Nginx?
  Musisz skopiować zawartość certyfikatu pośredniego i wkleić ją dokładnie pod zawartością swojego certyfikatu w jednym pliku tekstowym, używając zwykłego edytora lub polecenia cat.
• Dlaczego Root CA nie wystawia certyfikatów bezpośrednio?
  Dla bezpieczeństwa. Główny klucz prywatny trzyma się na serwerach odłączonych od sieci. Ewentualny atak hakerski na urząd pośredni pozwala łatwo unieważnić tylko jeden węzeł, chroniąc cały system.

Bibliografia

1. Naukowa i Akademicka Sieć Komputerowa (NASK) – https://www.nask.pl
2. Ministerstwo Cyfryzacji – https://www.gov.pl/web/cyfryzacja
3. Internet Engineering Task Force (IETF) – https://www.ietf.org
4. Narodowe Centrum Bezpieczeństwa Cyberprzestrzeni – https://www.cyber.mil.pl
5. Let’s Encrypt – https://letsencrypt.org