Révoquer un appareil VPN perdu : clé, certificat ou compte

Votre ordinateur portable a disparu, et le VPN le liste toujours comme client. La question urgente n’est pas comment supprimer le profil sur une machine que vous n’avez plus, mais quelle identité le serveur accepte encore. WireGuard vérifie une clé publique, une configuration OpenVPN fondée sur une PKI vérifie un certificat client, et un VPN avec SSO vérifie un compte et son jeton de session. Ces trois se révoquent à des endroits différents, à des vitesses différentes, et corriger l’une en ignorant les autres est la façon dont un appareil perdu reste connecté.

Trois identités et ce que chacune contrôle

Chaque mécanisme répond à une question différente. Une clé de pair répond si c’est bien la machine que vous avez enrôlée. Un certificat répond s’il a été signé par votre AC et s’il n’a pas été révoqué. Un compte répond si cette personne s’est authentifiée assez récemment. Un déploiement qui en superpose deux, par exemple certificat plus connexion à l’annuaire, ne ferme la porte que lorsque chaque couche qui a délivré quelque chose à l’appareil a reçu l’ordre de ne plus l’accepter.

Le piège pratique est que la machine manquante détient la moitié privée de chaque justificatif, donc rien de ce que vous faites localement n’atteint le serveur.

WireGuard : supprimez le pair, car il n’existe pas de liste de révocation

WireGuard ne tient aucune liste de refus. L’interface accepte exactement les clés publiques configurées comme pairs, donc révoquer consiste à supprimer : exécutez wg set wg0 peer <public-key> remove, la forme documentée dans wg(8), puis supprimez le bloc [Peer] correspondant de wg0.conf. Faites les deux. Une suppression uniquement à l’exécution survit jusqu’au prochain redémarrage ou rechargement de la configuration, moment où le fichier remet la clé.

Les sessions existantes n’ont pas besoin d’un minuteur pour mourir. Retirer le pair abandonne sa poignée de main et son matériel de clé, donc le trafic s’arrête dès qu’une paire de clés valide est de nouveau exigée. Vérifiez wg show wg0 latest-handshakes sur le serveur : l’entrée de la clé perdue doit disparaître et rester absente, tandis que les autres pairs continuent de signaler des époques récentes.

Un avertissement compte plus qu’il n’y paraît. Si l’appareil perdu partageait une clé avec d’autres appareils parce que quelqu’un a copié un fichier de configuration, retirer cette clé les déconnecte tous ; c’est toujours le bon geste, et vous réémettez ensuite des clés par appareil au lieu de restaurer la clé partagée.

Certificats : une CRL ne compte que si le démon la lit

L’accès par certificat ajoute une étape que les gens sautent. easyrsa revoke laptop-01 marque le certificat comme révoqué dans la base de l’AC, mais le VPN n’apprend rien de cette base. Vous exécutez ensuite easyrsa gen-crl pour écrire crl.pem, vous le copiez vers le chemin indiqué dans l’option crl-verify du serveur et vous confirmez que le démon en cours utilise le nouveau fichier. Révoquer sans régénérer et distribuer la CRL est sans effet.

Le minutage est la seconde moitié. Une CRL est consultée lorsqu’un client se connecte ou renégocie, donc un tunnel établi peut continuer à transmettre jusque-là. Si l’appareil doit être coupé immédiatement, terminez cette session explicitement via l’interface de gestion d’OpenVPN plutôt que d’attendre la prochaine poignée de main. Recharger ou redémarrer le service, selon la façon dont le déploiement charge la CRL, fait partie du changement et n’est pas un extra facultatif.

La vérification vaut la peine d’être faite depuis une autre machine : présentez le certificat révoqué et attendez un échec de poignée de main, typiquement VERIFY ERROR: depth=0, error=certificate revoked. Si la connexion réussit encore, le client lit une CRL différente de celle que vous avez mise à jour.

Comptes et sessions : désactiver n’est pas la même chose qu’expulser

Les connexions à l’annuaire ou par SSO sont vérifiées au moment de l’authentification. Désactiver le compte bloque la prochaine connexion, mais le jeton de rafraîchissement et le tunnel établi peuvent continuer de fonctionner jusqu’à leur expiration. Révoquez les sessions et les jetons de cet utilisateur, ou augmentez une version de session si le fournisseur d’identité le prend en charge. Retirez aussi l’appareil perdu de l’enrôlement MFA, car un authentificateur enregistré est un chemin d’accès à part entière.

Les VPN adossés à RADIUS peuvent pousser un message de déconnexion ou un changement d’autorisation pour faire tomber une session active, mais tous les serveurs d’accès réseau ne le respectent pas. En cas de doute, terminez la session de l’utilisateur côté serveur et confirmez dans les journaux que l’ancienne session s’est fermée.

Ordre des opérations pour l’heure suivante

Partez de l’inventaire, pas du client : listez chaque identité liée à l’appareil, qu’il s’agisse d’une clé de pair, d’un numéro de série de certificat ou d’un compte. Révoquez dans chaque système émetteur dans l’ordre où la connexion se construit, c’est-à-dire le compte d’abord, puis le certificat, puis le pair. Prouvez ensuite le refus depuis une machine que vous contrôlez.

Deux suites sont faciles à oublier. D’abord, faites tourner tout ce que l’appareil détenait d’autre, en particulier les clés SSH, les identifiants de console cloud et une clé prépartagée WireGuard. Ensuite, vérifiez que la gestion de configuration, les instantanés ou les images dorées ne peuvent pas réintroduire le client supprimé lors de la prochaine reconstruction.

La solution durable est une identité par appareil. Quand chaque portable porte sa propre clé de pair ou son propre certificat, une perte coûte une commande de révocation et une réémission plutôt qu’une reconstruction de toute la flotte.