Certificat VPN révoqué toujours connecté ? Vérifiez l'application de la CRL

Vous avez révoqué le certificat, généré une nouvelle liste, et l'ancien profil monte encore un tunnel. La révocation elle-même n'est pas cassée : une CRL est une déclaration signée qu'un numéro de série n'est plus valide, et elle ne change l'accès que lorsque le composant qui termine TLS la charge, pour le bon émetteur, avant de prendre la décision d'acceptation. C'est là que se situent la plupart de ces cas, et c'est pourquoi révocation et refus sont deux faits distincts.

Parcourez les cinq vérifications ci-dessous dans l'ordre, et arrêtez-vous à la première qui ne tient pas, car chaque vérification ultérieure suppose les précédentes vraies.

Vérifiez quel composant prend la décision d'acceptation

Nommez le processus qui valide le certificat client, car seul ce processus peut appliquer une liste. Sur un serveur OpenVPN, c'est le démon lui-même, configuré avec crl-verify. Sur ocserv, c'est la ligne crl dans ocserv.conf. Sur strongSwan, les entrées sont les CRL chargées avec strictcrlpolicy. Un proxy ou un équipement qui termine TLS devant le VPN peut aussi être le vrai vérificateur, et si c'est le cas, le démon derrière ne voit jamais le certificat client.

WireGuard relève d'une autre catégorie. Il n'a ni certificats ni liste de révocation ; un pair est admis par sa clé publique dans la configuration, donc couper l'accès signifie retirer cette clé. Si vous cherchez une CRL dans un déploiement uniquement WireGuard, ce mécanisme n'existe pas.

Attention aussi au piège côté client. Un client qui refuse de se connecter parce qu'il n'aime pas le certificat du serveur applique la chaîne du serveur, il ne révoque pas son propre justificatif. Un certificat utilisateur n'est révoqué que là où ce certificat utilisateur est validé, et c'est presque toujours côté serveur.

Vérifiez pour quel émetteur la liste a été signée

Une CRL est limitée à une seule AC émettrice. Avec une racine et une intermédiaire, les certificats feuilles viennent de l'intermédiaire, donc la liste qui compte est la CRL de l'intermédiaire ; la liste de la racine ne dit rien de ces feuilles. Un vérificateur pointé sur le mauvais fichier l'analyse allègrement, ne trouve aucune entrée correspondante et accepte tout.

Confirmez l'appariement avant de toucher au démon. L'émetteur du certificat doit correspondre au subject de la liste :

openssl x509 -in client.crt -noout -issuer -serial
openssl crl  -in intermediate.crl -noout -issuer -lastupdate -nextupdate

Quand les deux viennent de la même AC, le numéro de série imprimé pour le certificat est la valeur qui doit figurer dans la liste. S'ils ne concordent pas, vous tenez la mauvaise CRL ou la mauvaise copie de celle-ci.

La validité relève de la même vérification. Un nextUpdate dans le passé rend la liste obsolète, et un vérificateur qui échoue en fermé rejettera alors chaque client au lieu du seul révoqué.

Vérifiez que le numéro de série figure dans la copie chargée par le démon

La révocation écrit une entrée dans la base de l'AC, et la régénération écrit un nouveau fichier. Aucune des deux actions n'atteint un démon en cours d'exécution qui a chargé l'ancienne copie au démarrage. Videz la liste et cherchez le numéro de série :

openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crl

Vérifiez ensuite comment votre implémentation récupère le fichier. OpenVPN lit un chemin donné à crl-verify une fois au démarrage, donc une nouvelle liste exige un redémarrage ou un signal de redémarrage ; la même option pointée vers un répertoire est relue à chaque connexion, et c'est pourquoi le mode répertoire existe. strongSwan doit recharger ses identifiants, par exemple avec swanctl --load-creds. Que le fichier sur disque soit correct et que le vérificateur l'utilise sont deux faits différents.

Vérifiez la politique pour une liste absente ou expirée

C'est la décision que beaucoup de déploiements ne prennent jamais explicitement, et elle décide si la révocation vous protège ou enferme tout le monde dehors. Fail-closed signifie qu'aucune information de révocation utilisable ne produit de rejet ; fail-open signifie que le vérificateur continue sans elle. strongSwan expose le choix sous strictcrlpolicy. OpenVPN avec crl-verify refuse de démarrer sur un fichier qu'il ne peut ni lire ni analyser, et une liste expirée se manifeste comme une erreur de vérification TLS sur une CRL expirée plutôt que comme une acceptation silencieuse.

Quelle que soit la direction choisie, l'automatisation compte plus que le choix : une tâche qui régénère la CRL avant nextUpdate et une alerte quand la copie déployée vieillit empêchent l'une comme l'autre politique de devenir un incident. La vérification en ligne avec OCSP déplace la fraîcheur vers un répondeur, mais la même règle s'applique, car un vérificateur non configuré pour contrôler la réponse ne change rien.

Vérifiez la session active, puis les copies de la clé

La révocation est évaluée pendant la validation du certificat, qui a lieu à la connexion et à la renégociation. Une session établie continue jusqu'à ce qu'elle renégocie, et la valeur par défaut d'OpenVPN est une fois par heure avec reneg-sec 3600. Si la personne doit être hors du réseau maintenant, terminez la session en plus de publier la liste, puis confirmez que la reconnexion est refusée.

Séparez le justificatif de ses copies. Supprimer un profil sur un portable n'empêche pas une autre copie de la même clé privée de s'authentifier ; c'est la révocation qui rend chaque copie inutilisable, et seulement quand les vérifications précédentes tiennent. Donnez à un appareil de remplacement son propre certificat pour pouvoir révoquer l'un sans toucher l'autre.

Avant de le déclarer terminé : le composant validant est identifié, l'émetteur de la liste correspond à celui de la feuille, le numéro de série révoqué figure dans la copie que le démon a réellement chargée, la politique pour les listes absentes ou expirées est délibérée et surveillée, et la session active a été terminée plutôt qu'attendue. Les formats derrière tout cela sont spécifiés dans RFC 5280.