A que validadores afecta un certificado raíz adicional?

Atopa un certificado raíz que non debería estar aí, e a primeira pregunta é que identidade pode suplantar. A resposta honesta depende de que software consulta ese almacén e de como o seu VPN verifica a súa pasarela. Un navegador, un xestor de paquetes e un cliente VPN cunha pegada fixada non comparten necesariamente a mesma decisión de confianza. Mapee os validadores antes de decidir o alcance.

Unha raíz no almacén do sistema non é unha chave universal

Instalar unha raíz fai que os certificados asinados con esa chave sexan aceptables para os programas que usan o almacén afectado. Non os fai aceptables automaticamente en todas partes, porque algunhas aplicacións traen o seu propio paquete ou comproban un valor fixado. Tampouco demostra que alguén executase código na máquina; un cambio de confianza é unha capacidade entre varias. Trate o certificado como un achado que hai que delimitar, non como todo o incidente.

O almacén importa tanto como o certificado: un paquete a nivel de usuario e unha áncora a nivel de sistema chegan a consumidores distintos.

Mapee cada validador e a súa fonte de confianza

Anote cada compoñente que valida certificados para os fluxos de traballo afectados: navegador, xestor de paquetes, cliente de correo, VPN. Despois atope a fonte de confianza que le cada un.

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

A listaxe do directorio mostra áncoras engadidas localmente en sistemas de estilo Debian, e a lista de confianza mostra o que o almacén do sistema expón neste momento. Un navegador co seu propio almacén non aparecerá alí, e unha aplicación Java ou Python pode usar outro paquete máis. Rexistre que entradas son esperadas e cales non, usando a pegada en lugar de só o nome mostrado. Esa lista é a que necesita un responsable de resposta a incidentes antes de borrar nada.

Comprobe a validación de par do propio VPN

Un VPN con unha CA privada ou unha pegada explícita avalía a pasarela segundo a súa propia configuración. Compare o que espera o cliente co que presenta a pasarela.

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

A saída dá a pegada SHA-256 e o suxeito do certificado que presenta o punto final, que pode comparar co valor configurado. OpenVPN ten unha opción de pegada de par que realiza esa comparación para o túnel sen esixir que o almacén do sistema acepte o asinante. Esa independencia é útil para o túnel e non di nada sobre o navegador. Tampouco axuda se a pegada esperada se copiou da conexión sospeitosa desde o principio.

Delimite o incidente máis aló do certificado

Use o procedemento do propietario do dispositivo para eliminar áncoras non autorizadas e buscar os cambios que adoitan acompañalas: servizos novos, clientes modificados, axustes de proxy alterados. Nunha máquina xestionada, confirme a configuración lexítima antes de borrar material do que depende outro software. Para cada validador, rexistre de onde vén a súa confianza, que identidade espera e como confirmou que a configuración actual é correcta. Un túnel que funciona tras a limpeza é unha observación, non unha proba de que o punto final estea limpo.

Despois volva probar os fluxos de traballo que usaban o almacén, porque eliminar unha áncora pode romper un servizo interno que dependía dela lexitimamente. A recuperación remata cando as relacións de confianza esperadas funcionan e as inesperadas non.