Tworzenie i zarządzanie łańcuchami certyfikatów

Główny CA to samopodpisany certyfikat, który pełni funkcję ostatecznej kotwicy zaufania. Klucz prywatny głównego CA należy przechowywać offline (w systemie odizolowanym od sieci lub w module HSM), ponieważ jego kompromitacja podważa bezpieczeństwo całej PKI. Polecenie "openssl req -x509 -new -nodes -key root_key.pem -sha256 -days 3650 -out root_cert.pem" generuje samopodpisany certyfikat główny ważny przez 10 lat.

Pośrednie CA są podpisywane przez główny CA i służą do bieżącego wystawiania certyfikatów. Najpierw należy wygenerować klucz pośredni i żądanie podpisania certyfikatu (CSR): "openssl req -new -key intermediate_key.pem -out intermediate.csr". Następnie główny CA podpisuje je za pomocą polecenia: "openssl x509 -req -in intermediate.csr -CA root_cert.pem -CAkey root_key.pem -CAcreateserial -days 1825 -out intermediate_cert.pem".

Certyfikaty końcowe (leaf) są podpisywane przez pośredni CA dla konkretnych serwerów lub klientów. Należy wygenerować klucz serwera i żądanie podpisania certyfikatu z nazwami Subject Alternative Names (SAN), a następnie podpisać je za pomocą pośredniego CA: "openssl x509 -req -in server.csr -CA intermediate_cert.pem -CAkey intermediate_key.pem -CAcreateserial -extensions v3_req -days 365 -out server_cert.pem".

Klucz prywatny głównego CA jest przechowywany offline i używany wyłącznie do podpisywania niewielkiej liczby certyfikatów pośrednich CA. Bieżące wystawianie certyfikatów jest realizowane przez pośrednie CA działające online. Jeśli pośredni CA zostanie przejęty, można go odwołać i zastąpić bez narażania głównego CA. Klucz główny pozostaje bezpieczny, ponieważ nigdy nie był dostępny online.

Polecenie "openssl ca" zapewnia pełniejszy przebieg pracy CA niż "openssl x509 -req". Utrzymuje bazę danych certyfikatów (index.txt), przypisuje numery seryjne na podstawie pliku z numerami seryjnymi i obsługuje generowanie CRL. Wymaga prawidłowo skonfigurowanego pliku openssl.cnf z sekcjami właściwymi dla CA, definiującymi zasady certyfikacji i ograniczenia długości ścieżki.

Kompletny plik łańcucha certyfikatów dla serwera internetowego zawiera certyfikat końcowy, a następnie certyfikaty pośrednich CA w odpowiedniej kolejności, kończąc tuż przed certyfikatem głównym. Certyfikatów głównych nie dołącza się, ponieważ przeglądarki mają fabrycznie zainstalowane magazyny certyfikatów głównych. Kolejność łączenia: "cat server_cert.pem intermediate_cert.pem > chain.pem". Nieprawidłowa kolejność powoduje niepowodzenie uzgadniania TLS.

"openssl verify -CAfile root_cert.pem -untrusted intermediate_cert.pem server_cert.pem" weryfikuje cały łańcuch. Flaga "-untrusted" dostarcza certyfikaty pośrednie, które należą do łańcucha, ale nie są jeszcze zaufane. Jeśli weryfikacja zakończy się powodzeniem, dane wyjściowe mają postać "server_cert.pem: OK". Typowe błędy wskazują na brak certyfikatów pośrednich lub wygaśnięcie certyfikatów.

Do częstych problemów z łańcuchem certyfikatów należą: brak certyfikatów pośrednich (serwer wysyła tylko certyfikat końcowy), nieprawidłowa kolejność łączenia (certyfikat końcowy musi być pierwszy), wygasły certyfikat pośredni (łatwo go przeoczyć, ponieważ monitoruje się wygaśnięcie certyfikatu końcowego), certyfikaty samopodpisane, których nie ma w magazynie zaufanych certyfikatów, oraz niezgodność nazwy (SAN certyfikatu nie odpowiada nazwie hosta). Wszystkie te problemy można zdiagnozować za pomocą "openssl s_client -showcerts".

PKCS#12 (.pfx lub .p12) to format kontenera, który łączy klucz prywatny, certyfikat końcowy i certyfikaty pośrednie w jednym zaszyfrowanym pliku. Tworzenie: "openssl pkcs12 -export -out bundle.pfx -inkey server_key.pem -in server_cert.pem -certfile intermediate_cert.pem". Jest wymagany przez IIS, .NET, magazyny kluczy Java i wiele aplikacji używanych w przedsiębiorstwach.

PEM to kodowanie ASCII w formacie base64, czytelne dla człowieka, obsługujące wiele obiektów w jednym pliku i używane przez Apache, nginx oraz narzędzia OpenSSL. DER jest formatem binarnym, w którym w jednym pliku znajduje się jeden obiekt; używa się go w środowiskach Java (importy JKS), Android i niektórych narzędziach używanych w przedsiębiorstwach. PKCS#12/PFX to zaszyfrowany binarny kontener na wiele obiektów, używany przez Windows i IIS. Przed wdrożeniem należy sprawdzić, jakiego formatu oczekuje system docelowy.

Współczesne CA muszą rejestrować wszystkie wystawione certyfikaty w dziennikach Certificate Transparency (CT) przed ich przekazaniem. Podczas tworzenia prywatnego CA do użytku wewnętrznego rejestrowanie w CT nie jest wymagane. Certyfikaty używane publicznie muszą jednak zawierać osadzone Signed Certificate Timestamps (SCT), aby Chrome uznawał je za zaufane. Prywatne CA mogą stosować własne zasady bez wymagań CT.

Główne CA są samopodpisane, przechowywane offline i podpisują wyłącznie certyfikaty pośrednie. Pośrednie CA obsługują bieżące wystawianie certyfikatów. Pliki łańcucha zawierają najpierw certyfikat końcowy, a następnie certyfikaty pośrednie; certyfikat główny jest pomijany. Weryfikację wykonuje się za pomocą "openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem". Pakiety PKCS#12 zawierają klucz i certyfikaty na potrzeby Windows/Java. Nieprawidłowa kolejność w łańcuchu jest częstą przyczyną niepowodzeń wdrożenia, które można zdiagnozować za pomocą s_client -showcerts.