Un client révoqué se connecte encore : la liste n’est jamais arrivée

La révocation ne pénètre jamais dans un tunnel en cours pour supprimer une session. La liste est une entrée de la vérification du certificat et elle est consultée pendant l’échange du canal de contrôle qui ouvre une session TLS. Ce seul fait explique les deux surprises : un client révoqué se reconnecte parce que la liste n’est jamais parvenue au vérificateur, et une session existante survit parce que personne n’a revérifié quoi que ce soit.

Une liste est une entrée, pas une action

Lors de l’établissement de la session, le serveur valide le certificat du client par rapport à ses ancres de confiance, et la directive de révocation ajoute à cette décision une consultation de la liste. La vérification a lieu sur le serveur, donc le client ne peut pas voir que son certificat a été révoqué et continue de proposer le même. Un profil qui se connecte encore ne prouve donc que la chaîne a été acceptée par un vérificateur, pas que la révocation a échoué.

La liste est elle-même un objet signé avec une date d’émission et une date de prochaine mise à jour. Une liste étrangère, une liste signée par une autre autorité ou une liste dont la prochaine mise à jour est passée ne remplacent pas la liste courante, et le rejet ou l’acceptation silencieuse d’une liste périmée dépend du déploiement.

Nouvelle connexion contre session en cours

La révocation est évaluée lors de l’établissement ou de la renégociation d’une session, pas contre le canal de données à chaque paquet. Un client déjà connecté détient des clés de trafic, il continue donc de laisser passer des paquets après que son certificat apparaît sur la liste. L’intervalle de renégociation par défaut se mesure en heures, ce qui explique qu’une liste mise à jour prenne effet pour les nouveaux venus tandis qu’un tunnel en cours reste debout.

Une application immédiate exige une action délibérée et non la seule liste. Redémarrer le service force chaque client à se reconnecter, tandis que terminer une seule session via l’interface de gestion laisse les autres intactes. Choisissez-en une par incident et notez celle que vous avez utilisée. Les deux options ont une portée différente, et c’est la vraie décision.

Livrez le fichier que le vérificateur lit réellement

La liste doit être générée à partir de l’enregistrement de l’autorité, puis copiée sur chaque machine qui vérifie des certificats. La générer sur l’hôte de la CA sans jamais l’installer sur le serveur est la défaillance la plus courante, et elle ressemble exactement à une fonction de révocation cassée.

ca ca.crt
cert server.crt
key server.key
crl-verify /etc/openvpn/crl.pem

Deux détails décident si le fichier est réellement lu. Un chemin relatif est résolu par rapport au répertoire de configuration, donc une copie laissée dans le répertoire personnel d’un opérateur peut ne jamais être trouvée. Et le démon abandonne généralement ses privilèges après le démarrage, donc le compte d’exécution a besoin d’un droit de recherche sur chaque répertoire parent et d’un droit de lecture sur le fichier. Vérifiez les deux avec le compte d’exécution et non avec root, sinon le test démontre la mauvaise chose.

Sur les hôtes systemd, une unité durcie peut aussi masquer le chemin, avec une vue en lecture seule ou un répertoire système protégé. Depuis l’intérieur du service, cela est indiscernable d’un fichier absent, alors vérifiez les restrictions de l’unité avant d’aller chercher une erreur de permissions. Lisez le fichier d’unité avant d’accuser le mode du fichier.

Confirmez sur le serveur, pas sur le client

Le journal du serveur nomme ce qui s’est passé : l’ouverture de la liste, son chargement ou l’échec de la vérification avec le numéro de série révoqué. Le client ne rapporte qu’un échec générique de poignée de main, c’est pourquoi les journaux du client sont un mauvais endroit pour chercher une décision de révocation.

Vérifiez avec une tentative fraîche depuis le profil révoqué, puis arrêtez. Une connexion réussie depuis ce profil est le signal pour inspecter le chemin du fichier et le compte d’exécution, pas pour supposer que la liste était fausse. Gardez cette tentative réussie comme test d’acceptation, et ne comptez pas une reconnexion que vous n’avez pas observée.

Ce qui ne révoque rien

Supprimer le profil d’un ordinateur portable, retirer le fichier de certificat du client ou dire à l’utilisateur d’arrêter de se connecter ne change rien sur le serveur. Le certificat reste valide jusqu’à ce que l’autorité enregistre la révocation et que le vérificateur lise la liste résultante.

C’est aussi pourquoi la chaîne mérite d’être écrite : enregistrez la révocation, générez et signez la liste, diffusez exactement ce fichier et confirmez que le compte du service peut le lire. Chaque maillon est court, et il suffit qu’un seul manque pour qu’un client révoqué se connecte allègrement. Une liste de contrôle de quatre lignes vaut mieux qu’une supposition qui n’en a aucune.