Kan een servercertificaatketen de truststore van de client overschrijven?

Een browser toont een certificaatwaarschuwing op een site waarvan de keten volledig is, en de eerste reflex is de server repareren. Meestal presenteert de server precies wat hij hoort te presenteren. De client bepaalt welke ankers hij accepteert, en geen enkele rangschikking van tussenliggende certificaten kan die beslissing vanaf de andere kant van de verbinding veranderen. Die grens verklaart het grootste deel van wat op een certificaatprobleem lijkt.

Validatie draait op de client, met de ankers van de client

Padvalidatie neemt de gepresenteerde certificaten en bouwt een keten naar een vertrouwensanker dat het validerende systeem al bezit. RFC 5280 beschrijft dat model, en het legt de ankerkeuze bij de lokale implementatie in plaats van bij de server. Een applicatie kan er zijn eigen beleid bovenop leggen: een vastgezette sleutel, een bedrijfstruststore, of een strengere identiteitscontrole. De certificaatlijst die een server stuurt, is bewijs dat aan dat proces wordt aangeboden, nooit een instructie eraan.

Een volledige keten bewijst dus dat de server de onderdelen heeft. Het bewijst niet dat de client ze zal accepteren.

Om te zien wat de server werkelijk stuurt, voer openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts uit en tel de certificaten in de uitvoer. Een onvolledige keten daar is een correctie aan de serverkant. Een volledige keten verplaatst de vraag naar de client en zijn ankers, waar de server geen stem heeft.

Wat TLS-inspectie werkelijk verandert

Een inspectieapparaat beëindigt de TLS-sessie aan de clientzijde en opent een aparte sessie naar de echte dienst. De client valideert dan het certificaat van het apparaat, dat moet ketenen naar een anker dat de client vertrouwt. Daarom krijgen beheerde apparaten de inspectiewortel via apparaatbeheer, en daarom toont een persoonlijk apparaat zonder die wortel een waarschuwing.

De regeling is bewust en lokaal. Niets in de keten van de oorspronkelijke server kan een onbeheerde browser dwingen de vervangende identiteit te accepteren, en niets erin weerhoudt een beheerd apparaat ervan.

VPN-beëindiging is geen HTTPS-ontsleuteling

Een VPN-laag draagt pakketten tussen een client en een gateway. Die verwijderen, of de configuratie lezen, legt geen HTTPS-payload binnenin bloot.

De TLS-sessie loopt nog steeds tussen de browser en de webserver, met dezelfde validatieregels, tenzij iets hem expliciet beëindigt. De twee lagen verwarren leidt tot een verzoek aan de VPN-beheerder om het certificaat te leveren, terwijl het certificaat in kwestie bij een inspectieproxy of bij de site zelf hoort. Vraag welke component het certificaat presenteert voordat je een truststore wijzigt.

Stel verwachtingen in de component die je beheert

Als je de applicatie en zijn client beheert, definieer dan samen de verwachte dienstidentiteit, de geaccepteerde uitgevers en elke eis voor pinning of clientauthenticatie. Plan vernieuwing en herstel zodat een legitieme certificaatwijziging geen storing wordt. Als je alleen de openbare server beheert, documenteer dan welke authenticatie je eist en welke clientomgevingen je ondersteunt. Een voorkeursketen sturen certificeert niet het apparaat van een vreemde.

Op beheerde apparatuur los je incompatibiliteit op via de applicatie- en netwerkeigenaren. Validatie uitschakelen, een onverklaarde wortel toevoegen of proberen een inspectiebeleid te overleven stelt de beoogde peerverhouding niet vast.

Test het resultaat op een schoon clientprofiel, niet op de machine waar al een uitzondering is toegevoegd. Dat is de enige controle die laat zien wat een nieuw apparaat zal ervaren.