Czy łańcuch certyfikatów serwera może nadpisać magazyn zaufania klienta?

Przeglądarka pokazuje ostrzeżenie o certyfikacie na witrynie, której łańcuch jest pełny, a pierwszym odruchem jest naprawa serwera. Zwykle serwer przedstawia dokładnie to, co powinien. Klient decyduje, które kotwice akceptuje, i żaden układ certyfikatów pośrednich nie może zmienić tej decyzji z drugiego końca połączenia. Ta granica wyjaśnia większość tego, co wygląda na problem z certyfikatem.

Walidacja odbywa się po stronie klienta, z kotwicami klienta

Walidacja ścieżki bierze przedstawione certyfikaty i buduje łańcuch do kotwicy zaufania, którą system walidujący już posiada. RFC 5280 opisuje ten model i umieszcza wybór kotwicy w implementacji lokalnej, a nie na serwerze. Aplikacja może dodać własne zasady: przypięty klucz, korporacyjny magazyn zaufania, albo bardziej rygorystyczną weryfikację tożsamości. Lista certyfikatów wysyłana przez serwer jest dowodem oferowanym temu procesowi, nigdy poleceniem dla niego.

Pełny łańcuch dowodzi więc, że serwer ma elementy. Nie dowodzi, że klient je zaakceptuje.

Aby zobaczyć, co serwer faktycznie wysyła, uruchom openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts i policz certyfikaty w wyniku. Niepełny łańcuch to poprawka po stronie serwera. Pełny łańcuch przenosi pytanie do klienta i jego kotwic, gdzie serwer nie ma głosu.

Co naprawdę zmienia inspekcja TLS

Urządzenie inspekcyjne kończy sesję TLS po stronie klienta i otwiera osobną sesję do rzeczywistej usługi. Klient sprawdza wtedy certyfikat urządzenia, który musi łańcuchowo prowadzić do kotwicy zaufanej przez klienta. Dlatego urządzenia zarządzane otrzymują główny certyfikat inspekcji przez zarządzanie urządzeniami, i dlatego urządzenie osobiste bez niego pokazuje ostrzeżenie.

Układ jest celowy i lokalny. Nic w łańcuchu oryginalnego serwera nie może zmusić niezarządzanej przeglądarki do zaakceptowania tożsamości zastępczej i nic w nim nie powstrzymuje urządzenia zarządzanego przed tym.

Zakończenie VPN to nie odszyfrowanie HTTPS

Warstwa VPN przenosi pakiety między klientem a bramą. Usunięcie jej lub odczytanie jej konfiguracji nie ujawnia ładunku HTTPS w środku.

Sesja TLS nadal odbywa się między przeglądarką a serwerem webowym, z tymi samymi zasadami walidacji, chyba że coś wyraźnie ją zakończy. Mylenie obu warstw prowadzi do prośby skierowanej do administratora VPN o dostarczenie certyfikatu, choć certyfikat, o którym mowa, należy do proxy inspekcyjnego albo do samej witryny. Zapytaj, który komponent przedstawia certyfikat, zanim zmienisz jakikolwiek magazyn zaufania.

Ustal oczekiwania w komponencie, który kontrolujesz

Jeśli zarządzasz aplikacją i jej klientem, zdefiniujcie razem oczekiwaną tożsamość usługi, akceptowanych wystawców oraz wszelkie wymagania dotyczące przypinania lub uwierzytelniania klienta. Planujcie odnawianie i odtwarzanie tak, aby legalna zmiana certyfikatu nie stała się awarią. Jeśli zarządzasz tylko serwerem publicznym, udokumentuj, jakiego uwierzytelniania wymagasz i jakie środowiska klientów obsługujesz. Wysyłanie preferowanego łańcucha nie certyfikuje urządzenia obcej osoby.

W zarządzanym sprzęcie rozwiązuj niezgodność przez właścicieli aplikacji i sieci. Wyłączanie weryfikacji, dodawanie niewyjaśnionego certyfikatu głównego lub próba przetrwania polityki inspekcji nie ustanawiają zamierzonej relacji równorzędnej.

Przetestuj wynik na czystym profilu klienta, a nie na maszynie, na której już dodano wyjątek. To jedyna kontrola, która pokazuje, czego doświadczy nowe urządzenie.