Przeglądarka ufa stronie przez łańcuch certyfikatów, którego zwykle nie widzisz
Certyfikat strony internetowej często nie jest podpisany bezpośrednio przez urząd znajdujący się w magazynie zaufania przeglądarki. Zamiast tego klient buduje ścieżkę: certyfikat serwera został podpisany przez urząd pośredni, ten przez kolejny urząd, a dopiero na końcu znajduje się zaufany „root”. RFC 5280 nazywa taki ciąg certification path. Dzięki temu korzenie mogą być rzadko używane i silnie chronione, a codzienną emisję certyfikatów obsługują pośrednie klucze. Zaufanie do zwykłej strony jest więc wynikiem weryfikacji całego łańcucha podpisów i ograniczeń, a nie pojedynczego znaczka w jednym pliku.
Certyfikat serwera nie musi być samowystarczalny
Gdy serwer przedstawia swój certyfikat, klient musi ustalić, dlaczego miałby ufać zawartemu w nim kluczowi. RFC 5280 opisuje mechanizm ścieżki certyfikacji: certyfikat końcowy jest podpisany przez CA, ten urząd może mieć własny certyfikat podpisany przez inny CA, a ścieżka kończy się w punkcie zaufania znanym wcześniej klientowi. Przeglądarka nie „wierzy” więc dowolnemu podpisowi. Sprawdza kolejne powiązania aż do jednego z lokalnie akceptowanych trust anchors.
Korzeń zaufania jest specjalny właśnie dlatego, że nie można go zweryfikować w nieskończoność
Jeśli każdy certyfikat miałby wymagać certyfikatu podpisującego, powstałby nieskończony regres. Dlatego system zaczyna od ograniczonego zbioru kluczy zaufanych poza samą ścieżką. RFC 5280 wprost traktuje trust anchor jako wejście do algorytmu walidacji i zauważa, że bezpieczne dostarczenie takich kluczy jest krytycznym procesem poza zakresem samego protokołu. W praktyce zbiory zaufanych korzeni są dystrybuowane przez systemy operacyjne lub przeglądarki zgodnie z ich politykami.
Pośrednie CA ograniczają ekspozycję korzeni
Gdyby klucz root CA podpisywał bezpośrednio miliony certyfikatów serwerowych, musiałby być często używany i dostępny operacyjnie. Zamiast tego root może podpisywać certyfikaty pośrednich urzędów, a te wykonują codzienną pracę. To tworzy dodatkową warstwę zarządzania ryzykiem: kompromitację konkretnego pośrednika można obsługiwać inaczej niż kompromitację korzenia, a certyfikaty mogą zawierać ograniczenia mówiące, do czego dany klucz CA jest uprawniony.
Walidacja to więcej niż sprawdzenie jednego podpisu
Algorytm ścieżki sprawdza nie tylko matematyczną poprawność podpisów. Znaczenie mają okresy ważności, podstawowe ograniczenia, przeznaczenie klucza, nazwy, polityki i inne rozszerzenia. Klient musi też ustalić, czy certyfikat serwera odpowiada nazwie hosta, z którą chce się połączyć. Dlatego poprawny podpis na pojedynczym certyfikacie nie wystarcza. Bezpieczeństwo wynika z całego zestawu reguł przetwarzających ścieżkę.
Łańcuch wyjaśnia, dlaczego zaufanie jest lokalną decyzją klienta
Dwa urządzenia mogą mieć różne magazyny zaufanych korzeni i dlatego inaczej ocenić tę samą ścieżkę. RFC 5280 zaznacza, że wybór trust anchor jest kwestią polityki. To ważna intuicja: certyfikat nie nosi w sobie uniwersalnej właściwości „zaufany”. Jest obiektem podpisanym kryptograficznie, a klient podejmuje decyzję na podstawie własnego zestawu zaufanych punktów, reguł i aktualnego stanu walidacji.
Serwer zwykle nie musi wysyłać przeglądarce zaufanego korzenia
Podczas typowego zestawiania TLS serwer przedstawia własny certyfikat i potrzebne certyfikaty pośrednie, natomiast zaufany korzeń znajduje się już w magazynie zaufania klienta. To ma sens: gdyby serwer mógł sam dostarczyć dowolny „zaufany korzeń”, cała konstrukcja niczego by nie gwarantowała. Klient buduje ścieżkę od certyfikatu serwera do punktu zaufania, który zaakceptował wcześniej, i weryfikuje ograniczenia kolejnych certyfikatów zgodnie z regułami PKI. RFC 5280 rozdziela pojęcia path building i path validation właśnie dlatego, że samo znalezienie łańcucha podpisów nie wystarcza. Trzeba jeszcze sprawdzić m.in. okresy ważności, zastosowania kluczy, ograniczenia nazw i zasady dla urzędów pośrednich. Łańcuch jest więc dowodem tylko w odniesieniu do lokalnie przyjętego trust anchor.
Jedna domena może mieć więcej niż jedną możliwą ścieżkę do zaufanego korzenia
PKI nie zawsze jest pojedynczym drzewem. Certyfikaty pośrednie mogą być wystawione lub cross-signed w sposób pozwalający różnym klientom zbudować różne ścieżki do korzeni znajdujących się w ich magazynach zaufania. RFC 5280 definiuje algorytm walidacji ścieżki niezależnie od konkretnego sposobu jej znalezienia. Ma to praktyczne znaczenie dla kompatybilności: starsze urządzenie i nowa przeglądarka mogą znać inne korzenie, a mimo to zaakceptować ten sam certyfikat końcowy przez inne ścieżki. Jednocześnie zwiększa to złożoność infrastruktury, bo „certyfikat jest poprawny” zależy nie tylko od samego pliku serwera, lecz także od zestawu pośrednich certyfikatów, lokalnych trust anchors i reguł walidacji klienta.