Mettre en pause l’accès d’un client et le retirer définitivement ressemblent à la même tâche jusqu’à ce qu’on essaie d’annuler l’une des deux. Révoquer un certificat écrit un enregistrement que le serveur traite comme définitif, et l’inverser signifie éditer à la main la base de données de l’émetteur. Abandonner le tunnel actif est une commande de gestion qui ne change rien à la confiance. Choisissez le levier en demandant si la clé est toujours digne de confiance, pas en demandant à quel point la demande semble urgente.

La croyance : révoqué et suspendu, c’est la même chose

Un sous-traitant est mis en pause pour une semaine et le réflexe est de révoquer, parce que révocation sonne comme éteindre quelque chose. Cela paraît propre, cela prend dix secondes, et cela laisse une édition de la base de données comme seul chemin de retour. Le réflexe est compréhensible et il est plus proche de brûler un passeport que de fermer une porte. Un appareil en pause et une clé compromise demandent des traitements différents, et un seul des deux est bon marché à annuler.

La distinction porte sur l’identifiant et non sur la personne. Une clé encore entre de bonnes mains peut être mise en pause et reprise sans aucune perte de confiance. Une clé qui a pu être copiée ne devrait jamais être restaurée, car restaurer affirme que la copie n’existe pas.

Écrivez la réponse avant de toucher à l’un ou l’autre système. Si vous ne pouvez pas dire si la clé est exposée, la réponse prudente est le remplacement.

Abandonnez la session active avec l’interface de gestion

OpenVPN expose une interface de gestion qui peut lister les sessions et en tuer une par nom commun. Activez-la sur localhost, gardez-la à l’écart de l’interface publique, et envoyez la commande de mise à mort quand une session doit disparaître maintenant. La commande ne ferme que ce tunnel, et tous les autres clients continuent de fonctionner.

C’est une réponse à un problème actif, pas une politique de suspension. Le même profil peut se reconnecter en une minute, car rien de son identifiant n’a changé. Utilisez-la quand la session doit partir et que la décision durable est encore en cours.

Confirmez que la session était connectée avant de la tuer, pour ne pas chasser un client qui ne s’est jamais connecté. La commande d’état ci-dessous imprime ce qui est actuellement connecté.

printf 'status 2\nquit\n' | nc 127.0.0.1 7506
printf 'kill kiosk-14\nquit\n' | nc 127.0.0.1 7506

Si la mise à mort signale qu’aucun client de ce nom n’existe, le nom commun du certificat n’est pas la chaîne que vous avez tapée. Lisez la sortie d’état plutôt que le nom du fichier de profil.

Ce que la CRL contrôle réellement

Le serveur ne consulte pas un indicateur de révocation stocké sur le certificat. Il lit la liste de révocation de certificats nommée par crl-verify, à chaque nouvelle connexion, et rejette un certificat dont le numéro de série figure sur cette liste. Deux conséquences en découlent, et les deux comptent en exploitation. Le fichier doit être lisible par le compte auquel le serveur abandonne ses privilèges, et un client déjà connecté continue de fonctionner jusqu’à ce qu’il se reconnecte.

Cette seconde conséquence surprend les gens pendant les incidents. Révoquer un certificat ne ferme pas le tunnel qui l’utilise en ce moment. Associez la révocation à une mise à mort de gestion si la session doit se terminer immédiatement, et traitez les deux actions comme des étapes distinctes du manuel.

Inspectez la liste pour voir ce que le serveur appliquera réellement, au lieu de faire confiance à l’horodatage du dernier fichier copié. Le nombre de numéros de série est la partie qui compte.

openssl crl -in /etc/openvpn/server/crl.pem -noout -text | sed -n '1,14p'
ls -l /etc/openvpn/server/crl.pem

Une liste sans entrées et une liste avec les bonnes entrées sont identiques dans un listage de répertoire, c’est pourquoi le nombre de numéros de série mérite d’être imprimé. La ligne des permissions compte tout autant, car un fichier que le démon ne peut pas lire produit une panne qui ressemble à un client rejeté.

Restaurer un enregistrement, avec soin

Restaurer un certificat signifie inverser un enregistrement dans la base d’émission et publier une nouvelle liste. easy-rsa 3 conserve cette base sous forme d’index.txt dans le répertoire PKI, tandis que les dispositions plus anciennes utilisaient un autre agencement. Une ligne commence par une lettre d’état et une date d’expiration. Une ligne révoquée insère un horodatage de révocation avant de poursuivre avec le numéro de série, le nom du fichier de certificat et le nom distinctif. Remettre une ligne en place signifie supprimer cet horodatage et inverser la lettre, en laissant tout le reste tranquille.

Sauvegardez le fichier d’abord, et faites l’édition par script plutôt qu’en tapant dans un éditeur de texte. Une faute de frappe qui change le nombre de champs d’une ligne casse l’émission pour chaque certificat ajouté ensuite. C’est la raison d’automatiser le changement et de copier le fichier avant d’y toucher.

Une seconde révocation du même nom échoue souvent aussi, parce que la première exécution a déplacé ce certificat et sa clé hors des répertoires où l’outil s’attend à les trouver. L’outil ne trouve alors plus ce qu’on lui demande de révoquer, et le message d’erreur n’explique pas toujours clairement pourquoi.

cp /etc/easy-rsa/pki/index.txt /root/index.txt.$(date +%F-%H%M)
grep -c '^R' /etc/easy-rsa/pki/index.txt
easyrsa gen-crl

Publiez la nouvelle liste, corrigez son propriétaire et faites en sorte que le serveur la lise. Un rechargement suffit sur la plupart des installations, mais la confirmation doit venir d’une connexion neuve, car la session existante n’a jamais rien revérifié.

Vérifiez quel levier le cas mérite

Posez la question qui décide de tout le manuel : la clé privée est-elle encore uniquement là où elle doit être. Si oui, la mise à mort de la session plus une pause documentée couvre le cas et ne laisse aucun enregistrement permanent. Si non, la seule réponse sûre est une nouvelle clé avec l’ancien certificat laissé révoqué.

Vérifiez ensuite le résultat par une tentative de connexion plutôt que par une différence de configuration. La différence vous dit ce que vous vouliez, et la connexion vous dit ce que le serveur applique.

openssl crl -in /etc/openvpn/server/crl.pem -noout -text | grep -c 'Serial Number'
printf 'status 2\nquit\n' | nc 127.0.0.1 7506

Quand un client restauré se connecte et apparaît dans la sortie d’état, l’édition de l’enregistrement a fonctionné. Quand un client révoqué est refusé et que le journal nomme la CRL, la révocation a fonctionné. Tout ce qui se situe entre les deux est un problème de permissions ou de rechargement, et cela vaut la peine d’être corrigé avant que la demande suivante n’arrive.

Articles similaires