Welke validators beïnvloedt een extra rootcertificaat?

U vindt een rootcertificaat dat er niet hoort te staan, en de eerste vraag is wiens identiteit het kan nabootsen. Het eerlijke antwoord hangt af van welke software dat archief raadpleegt en hoe uw VPN zijn gateway verifieert. Een browser, een pakketbeheerder en een VPN-client met een vastgezette vingerafdruk delen niet noodzakelijk dezelfde vertrouwensbeslissing. Breng de validators in kaart voordat u de omvang bepaalt.

Een root in het systeemarchief is geen universele sleutel

Een root installeren maakt certificaten die met die sleutel zijn ondertekend acceptabel voor programma's die het betrokken archief gebruiken. Het maakt ze niet automatisch overal acceptabel, omdat sommige toepassingen hun eigen bundel meebrengen of een vastgezette waarde controleren. Het bewijst ook niet dat iemand code op de machine heeft uitgevoerd; een vertrouwenswijziging is één van meerdere mogelijkheden. Behandel het certificaat als een bevinding die moet worden afgebakend, niet als het hele incident.

Het archief is net zo belangrijk als het certificaat: een bundel op gebruikersniveau en een anker op systeemniveau bereiken verschillende afnemers.

Breng elke validator en zijn vertrouwensbron in kaart

Noteer elke component die certificaten valideert voor de betrokken werkstromen: browser, pakketbeheerder, mailclient, VPN. Zoek daarna de vertrouwensbron die elk ervan leest.

ls /usr/local/share/ca-certificates
trust list | grep -i -E "vpn|corp"

De mapvermelding toont lokaal toegevoegde ankers op systemen in Debian-stijl, en de vertrouwenslijst toont wat het systeemarchief momenteel blootlegt. Een browser met een eigen archief verschijnt daar niet, en een Java- of Python-toepassing kan nog een andere bundel gebruiken. Noteer welke vermeldingen verwacht zijn en welke niet, met de vingerafdruk in plaats van alleen de weergegeven naam. Die lijst is wat een incidentresponder nodig heeft voordat er iets wordt verwijderd.

Controleer de eigen peervalidatie van de VPN

Een VPN met een privé-CA of een expliciete vingerafdruk beoordeelt de gateway op basis van zijn eigen configuratie. Vergelijk wat de client verwacht met wat de gateway presenteert.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256 -subject

De uitvoer geeft de SHA-256-vingerafdruk en het subject van het certificaat dat het eindpunt presenteert, die u met de geconfigureerde waarde kunt vergelijken. OpenVPN heeft een optie voor peer-vingerafdruk die die vergelijking voor de tunnel uitvoert zonder dat het systeemarchief de ondertekenaar hoeft te accepteren. Die onafhankelijkheid is nuttig voor de tunnel en zegt niets over de browser. Het helpt ook niet als de verwachte vingerafdruk vanaf het begin van de verdachte verbinding is gekopieerd.

Baken het incident af voorbij het certificaat

Gebruik de procedure van de eigenaar van het apparaat om ongeoorloofde ankers te verwijderen en te zoeken naar de wijzigingen die ze gewoonlijk vergezellen: nieuwe services, gewijzigde clients, gewijzigde proxy-instellingen. Bevestig op een beheerde machine de legitieme configuratie voordat u materiaal verwijdert waarvan andere software afhankelijk is. Noteer voor elke validator waar zijn vertrouwen vandaan komt, welke identiteit hij verwacht en hoe u hebt bevestigd dat de huidige configuratie correct is. Een werkende tunnel na het opschonen is één observatie, geen bewijs dat het eindpunt schoon is.

Test daarna de werkstromen opnieuw die het archief gebruikten, want het verwijderen van een anker kan een interne dienst breken die er terecht op vertrouwde. Het herstel is voltooid wanneer de verwachte vertrouwensrelaties werken en de onverwachte niet.