Kan en servercertifikatkedja åsidosätta klientens förtroendelager?

En webbläsare visar en certifikatvarning på en webbplats vars kedja är fullständig, och den första impulsen är att reparera servern. Vanligtvis presenterar servern exakt det den ska. Klienten avgör vilka ankare den accepterar, och ingen ordning av mellanliggande certifikat kan ändra det beslutet från andra änden av anslutningen. Den gränsen förklarar det mesta av det som ser ut som ett certifikatproblem.

Valideringen körs på klienten, med klientens ankare

Sökvägsvalidering tar de presenterade certifikaten och bygger en kedja till ett förtroendeankare som valideringssystemet redan har. RFC 5280 beskriver den modellen, och den placerar ankarvalet hos den lokala implementationen snarare än hos servern. En applikation kan lägga sin egen policy ovanpå: en fäst nyckel, ett företagsförtroendelager, eller en strängare identitetskontroll. Listan med certifikat som en server skickar är bevis som erbjuds den processen, aldrig en instruktion till den.

Så en fullständig kedja bevisar att servern har delarna. Den bevisar inte att klienten kommer att acceptera dem.

För att se vad servern faktiskt skickar, kör openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts och räkna certifikaten i utdata. En ofullständig kedja där är en rättelse på serversidan. En fullständig kedja flyttar frågan till klienten och dess ankare, där servern inte har någon röst.

Vad TLS-inspektion faktiskt ändrar

En inspektionsapparat avslutar TLS-sessionen på klientsidan och öppnar en separat session till den riktiga tjänsten. Klienten validerar sedan apparatens certifikat, som måste kedja till ett ankare som klienten litar på. Därför får hanterade enheter inspektionsroten via enhetshantering, och därför visar en personlig enhet utan den en varning.

Arrangemanget är avsiktligt och lokalt. Ingenting i den ursprungliga serverns kedja kan tvinga en ohanterad webbläsare att acceptera den ersatta identiteten, och ingenting i den hindrar en hanterad enhet från att göra det.

VPN-avslut är inte HTTPS-dekryptering

Ett VPN-lager transporterar paket mellan en klient och en gateway. Att ta bort det, eller läsa dess konfiguration, avslöjar inte en HTTPS-nyttolast inuti.

TLS-sessionen går fortfarande mellan webbläsaren och webbservern, med samma valideringsregler, om inte något uttryckligen avslutar den. Att blanda ihop de två lagren skapar en begäran till VPN-administratören att tillhandahålla certifikatet, medan certifikatet i fråga tillhör en inspektionsproxy eller själva webbplatsen. Fråga vilken komponent som presenterar certifikatet innan du ändrar något förtroendelager.

Sätt förväntningarna i komponenten du kontrollerar

Om du driftar applikationen och dess klient, definiera den förväntade tjänsteidentiteten, de accepterade utgivarna och eventuella krav på fästning eller klientautentisering tillsammans. Planera förnyelse och återställning så att en legitim certifikatändring inte blir ett avbrott. Om du bara driftar den publika servern, dokumentera vilken autentisering du kräver och vilka klientmiljöer du stöder. Att skicka en föredragen kedja certifierar inte en främmandes enhet.

På hanterad utrustning löser du inkompatibilitet genom applikations- och nätverksägarna. Att inaktivera validering, lägga till en oförklarad rot eller försöka överleva en inspektionspolicy etablerar inte det avsedda peer-förhållandet.

Testa resultatet på en ren klientprofil, inte på maskinen där ett undantag redan lagts till. Det är den enda kontrollen som visar vad en ny enhet kommer att uppleva.