Quels validateurs un certificat racine supplémentaire affecte-t-il ?

Vous trouvez un certificat racine qui ne devrait pas être là, et la première question est quelle identité il peut usurper. La réponse honnête dépend du logiciel qui consulte ce magasin et de la façon dont votre VPN vérifie sa passerelle. Un navigateur, un gestionnaire de paquets et un client VPN avec une empreinte épinglée ne partagent pas forcément la même décision de confiance. Cartographiez les validateurs avant de décider de l'étendue.

Une racine dans le magasin système n'est pas une clé universelle

Installer une racine rend les certificats signés par cette clé acceptables pour les programmes qui utilisent le magasin concerné. Cela ne les rend pas automatiquement acceptables partout, car certaines applications embarquent leur propre lot ou vérifient une valeur épinglée. Cela ne prouve pas non plus que quelqu'un a exécuté du code sur la machine ; un changement de confiance est une capacité parmi d'autres. Traitez le certificat comme une constatation à délimiter, non comme tout l'incident.

Le magasin compte autant que le certificat : un lot au niveau utilisateur et une ancre au niveau système touchent des consommateurs différents.

Cartographiez chaque validateur et sa source de confiance

Notez chaque composant qui valide des certificats pour les flux de travail concernés : navigateur, gestionnaire de paquets, client de messagerie, VPN. Trouvez ensuite la source de confiance que chacun lit.

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

La liste du répertoire montre les ancres ajoutées localement sur les systèmes de type Debian, et la liste de confiance montre ce que le magasin système expose actuellement. Un navigateur doté de son propre magasin n'y apparaîtra pas, et une application Java ou Python peut utiliser encore un autre lot. Notez quelles entrées sont attendues et lesquelles ne le sont pas, en vous appuyant sur l'empreinte plutôt que sur le seul nom affiché. Cette liste est ce dont un intervenant en incident a besoin avant de supprimer quoi que ce soit.

Vérifiez la validation de pair du VPN lui-même

Un VPN avec une AC privée ou une empreinte explicite évalue la passerelle selon sa propre configuration. Comparez ce que le client attend avec ce que la passerelle présente.

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

La sortie donne l'empreinte SHA-256 et le sujet du certificat présenté par le point de terminaison, que vous pouvez comparer à la valeur configurée. OpenVPN dispose d'une option d'empreinte de pair qui effectue cette comparaison pour le tunnel sans exiger que le magasin système accepte le signataire. Cette indépendance est utile pour le tunnel et ne dit rien du navigateur. Elle n'aide pas non plus si l'empreinte attendue a été copiée dès le départ depuis la connexion suspecte.

Délimitez l'incident au-delà du certificat

Utilisez la procédure du propriétaire de l'appareil pour supprimer les ancres non autorisées et rechercher les changements qui les accompagnent habituellement : nouveaux services, clients modifiés, réglages de proxy altérés. Sur une machine gérée, confirmez la configuration légitime avant de supprimer du matériel dont dépend un autre logiciel. Pour chaque validateur, notez d'où vient sa confiance, quelle identité il attend et comment vous avez confirmé que la configuration actuelle est correcte. Un tunnel fonctionnel après le nettoyage est une observation, pas la preuve que le point de terminaison est propre.

Retestez ensuite les flux de travail qui utilisaient le magasin, car supprimer une ancre peut casser un service interne qui s'y fiait légitimement. La reprise est terminée lorsque les relations de confiance attendues fonctionnent et que les inattendues ne fonctionnent pas.