Comment supprimer un certificat VPN obsolète d'un magasin de confiance

Votre client VPN est désinstallé, le profil a disparu des Réglages, et le tunnel monte toujours avec les anciens identifiants. Ou vous le supprimez, redémarrez et le retrouvez le lendemain matin. Ni l’un ni l’autre n’est un bouton de suppression cassé. Un profil est une configuration ; un certificat est du matériel de clé plus une décision de confiance consignée dans un magasin que le profil ne fait que désigner. Lequel des deux vous tenez décide de ce que 'supprimer' doit vouloir dire.

Un profil n’est pas un certificat

Trois objets différents sont appelés 'le certificat' dans une configuration VPN. L’identité du client est un certificat feuille avec une clé privée, et la passerelle l’utilise pour décider qui vous êtes. La feuille propre au serveur et son intermédiaire sont ce que votre client vérifie à la connexion. L’ancre de confiance, généralement un certificat racine ou d’AC privée, est ce qui rend la chaîne vérifiable tout court. RFC 5280 nomme ces éléments ancre de confiance, intermédiaire et entité finale, et la chaîne ne se valide que tant que chaque maillon signe celui du dessous.

Supprimez l’identité et un appareil perd l’accès. Supprimez l’ancre et toute application qui valide contre ce magasin perd la capacité de vérifier quoi que ce soit émis sous elle, y compris des connexions sans aucun rapport avec le VPN. Cette asymétrie est tout le risque ici : une racine installée pour une passerelle est souvent la même racine qui signe un portail interne, un serveur de messagerie ou un miroir de paquets. Rappelez-vous laquelle des deux vous tenez.

La propriété décide si la suppression reste effective. Sur un ordinateur portable que vous possédez, vous êtes le seul à pouvoir remettre le certificat. Sur un appareil géré, un profil de configuration ou une charge MDM peut le réinstaller à la prochaine inscription, ce qui explique qu’il 'revienne' et pourquoi supprimer plus agressivement n’aide pas.

Trouvez quel magasin le détient encore

Les gens commencent dans l’application Réglages, qui est le seul endroit où un certificat n’est pas stocké. Les vrais emplacements sont les magasins de confiance du système d’exploitation, le magasin propre au navigateur et le magasin privé de l’application.

Faites correspondre le numéro de série ou l’empreinte, jamais le nom affiché. Les noms affichés sont définis par celui qui a émis le certificat et sont réutilisés : 'Example VPN' peut être trois certificats avec trois clés différentes, dont un encore utilisé au quotidien.

certutil -user -store My
certutil -store Root
openssl x509 -in vpn-client.pem -noout -subject -issuer -serial -fingerprint -sha256

Sur macOS, l’outil security donne les mêmes faits, et find-identity montre quels certificats ont encore une clé privée attachée :

security find-certificate -a -c "Example VPN" -Z /Library/Keychains/System.keychain
security find-identity -v -p ssl-client

Supprimez l’objet étroit, gardez l’émetteur partagé

Exportez avant de supprimer. Sans sauvegarde, la seule récupération est une réémission, ce qui, sur une AC privée, signifie revenir à celui qui exploite la PKI. Le PFX exporté est aussi ce que vous remettez si la suppression s’avère être la mauvaise décision.

certutil -user -exportPFX -p backup My <serial> C:\temp\vpn-id.pfx
certutil -user -delstore My <serial>
Remove-Item Cert:\CurrentUser\My<thumbprint>

L’option -user est celle que les gens oublient par accident. Sans elle, certutil travaille sur le magasin de la machine, ce qui signifie un shell élevé, un autre jeu de certificats et un rayon d’impact qui inclut désormais tous les autres comptes de la machine.

Sur macOS et Linux, la forme est la même : identifiez, exportez, puis supprimez du magasin le plus étroit qui explique le symptôme. Supprimer le fichier sous /usr/local/share/ca-certificates et relancer update-ca-certificates suffit ; --fresh n’aide que lorsque les liens symboliques de /etc/ssl/certs sont déjà incohérents. Les systèmes de la famille RHEL gardent les ancres dans /etc/pki/ca-trust/source/anchors, où trust anchor --remove fait le même travail.

sudo security delete-certificate -Z <sha1> /Library/Keychains/System.keychain
sudo rm /usr/local/share/ca-certificates/example-vpn.crt
sudo update-ca-certificates
sudo trust anchor --remove /etc/pki/ca-trust/source/anchors/example-vpn.crt

Avant de supprimer un certificat d’AC, vérifiez ce qui d’autre s’y enchaîne. Lister les sujets du paquet est une vérification en deux lignes et elle répond si cette ancre fait un autre travail :

openssl crl2pkcs7 -nocrl -certfile /etc/ssl/certs/ca-certificates.crt \
  | openssl pkcs7 -print_certs -noout | grep -i example

Supprimer le fichier n’est pas révoquer l’identité

Une suppression locale retire une copie. La clé privée peut encore se trouver dans un p12 attaché à un ancien ticket, un dossier de sauvegarde ou le second ordinateur portable configuré en même temps. S’il s’agissait d’une identité client, la passerelle continue d’accepter toute copie de cette clé jusqu’à ce que l’identité soit refusée côté serveur.

Pour une OpenVPN PKI, cela signifie révoquer le certificat et s’assurer que la CRL référencée par crl-verify est à jour ; easyrsa revoke puis easyrsa gen-crl est la version courte. Pour une passerelle liée à un fournisseur d’identité, désactivez l’utilisateur ou retirez l’appareil là-bas, car le certificat n’est qu’un identifiant en jeu. Supprimer la copie locale alors que le compte reste actif ressemble à un nettoyage et n’en est pas un.

Le travail d’incident a un autre ordre : préservez d’abord le certificat, son numéro de série et l’enregistrement de révocation, puis supprimez et révoquez. Ces enregistrements ne coûtent rien et n’exigent pas de laisser un identifiant opérationnel en place.

Vérifiez avec une poignée de main et une seconde application

Vérifiez la chaîne de l’extérieur, pas depuis la liste du magasin que vous venez de modifier. Le magasin montre votre modification ; la poignée de main montre le résultat.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com \
  -CAfile /etc/ssl/certs/ca-certificates.crt -verify_return_error < /dev/null
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt vpn-gateway.pem

Un code de retour de 0 signifie que les ancres restantes valident encore la passerelle. Une erreur de chaîne après la suppression de l’ancre est le résultat attendu, et elle confirme que vous avez touché l’ancre en usage et non un doublon dans un magasin que le client ne lit jamais. Si la connexion fonctionne encore, cherchez une seconde copie, un magasin intégré à l’application ou un certificat épinglé, tous courants dans les clients qui fournissent leur propre liste de confiance.

Testez ensuite quelque chose sans rapport : un site interne, un client de messagerie, un miroir de paquets. Cela mesure le rayon d’impact à moindre coût avant la fermeture de la fenêtre de changement.

• Rôle identifié comme identité, intermédiaire ou ancre de confiance
• Numéro de série et empreinte enregistrés, et la copie exportée vers l’emplacement approuvé
• Suppression effectuée dans le périmètre le plus étroit qui explique le symptôme
• Autorisation côté serveur révoquée lorsqu’une personne ou un appareil est parti
• Poignée de main expliquée, et une application sans rapport retestée
• Charge MDM ou profil de gestion mis à jour, sinon le certificat revient

Si le certificat est revenu après un redémarrage, le travail n’est pas terminé : quelque chose le possède et le réinstalle. Trouvez ce propriétaire avant de supprimer à nouveau, car une troisième suppression se comportera exactement comme les deux premières.