Certificat client perdu ? Révoquez par numéro de série, pas par nom

Le fichier du certificat de votre client a disparu, et le réflexe est de révoquer le nom et d’en émettre un nouveau. Ce réflexe laisse le certificat d’origine valide, car la révocation repose sur un numéro de série et non sur une étiquette. La CA conserve presque certainement une copie de ce qu’elle a émis, et retrouver cette copie est toute la tâche.

Perdre un fichier n’est pas perdre l’enregistrement de la CA

Une PKI Easy-RSA conserve les certificats publics qu’elle a émis, et les versions actuelles archivent aussi des copies par série dans le répertoire certs_by_serial de la PKI. La clé privée n’est pas nécessaire pour révoquer quoi que ce soit. L’essentiel est le certificat exact signé par la CA, que la CA possède déjà.

Travaillez sur une copie de sauvegarde de la bonne PKI, avec l’administrateur qui la possède. La révocation est une opération auditable, pas une réparation effectuée sur une base de production à minuit.

Une copie du certificat public intégré du client convient aussi, si le déploiement en a conservé une.

Lisez l’émetteur et la série avant tout le reste

Inspectez le PEM récupéré et notez l’émetteur, le numéro de série, le sujet et la fenêtre de validité. Le numéro de série est unique dans le périmètre d’un émetteur, pas parmi toutes les CA de votre parc, donc l’émetteur fait partie de l’identité. Si plusieurs certificats partagent un sujet, ce sont ces séries qui les distinguent.

Comparez les valeurs aux enregistrements de la CA et à l’appareil ou à la personne que vous croyez détenteur du certificat.

Un nom commun peut être réutilisé, et il l’est souvent. Ne décidez pas quels certificats retirer avant que les séries soient notées.

Pourquoi révoquer le nouveau certificat ne fait rien

Émettre un remplaçant avec le même nom commun crée un second certificat doté d’une autre série. Révoquer le remplaçant retire le nouveau et laisse l’original valide jusqu’à son expiration. Du point de vue de la CA, ce sont deux objets indépendants, et une CRL liste des séries et non des noms. L’index de la CA conserve une ligne par certificat émis précisément pour cette raison.

La même confusion produit l’erreur inverse : supprimer le fichier du client et supposer que la CA l’a oublié. La suppression chez le client n’est pas un événement de révocation, et le certificat continue de fonctionner pour quiconque en a une copie.

Les deux erreurs viennent de traiter le nom comme l’identité.

Révoquez le certificat que la série désigne

Identifiez l’objet avant de toucher à la CA : openssl x509 -in recovered-client.pem -noout -issuer -serial -subject -dates imprime les quatre valeurs en une seule passe, et la série est ce que vous comparez à l’archive de la CA. Easy-RSA conserve cette archive sous pki/certs_by_serial, avec un fichier par série. La commande de révocation prend un nom commun et non une série, alors copiez le fichier archivé vers pki/issued/<common-name>.crt et laissez le nom pointer vers l’objet identifié. Exécutez easyrsa revoke <common-name> depuis le répertoire de la PKI, puis vérifiez que la ligne correspondante dans index.txt est passée à R. La série est la façon de choisir l’objet, pas un argument que la commande accepte.

openssl x509 -in recovered-client.pem -noout -issuer -serial -subject -dates
cp pki/certs_by_serial/A1B2C3D4.pem pki/issued/client-01.crt
./easyrsa revoke client-01
grep -n client-01 pki/index.txt
./easyrsa gen-crl

Si index.txt n’affiche pas R, arrêtez-vous et lisez l’erreur avant de générer une CRL, car une CRL construite à partir d’un enregistrement encore valide ne retire rien. C’est seulement après le basculement de la ligne que vous lancez easyrsa gen-crl et passez à la distribution du fichier.

Publiez la CRL là où elle est réellement appliquée

Générez une nouvelle CRL via le flux de travail pris en charge par la PKI, puis publiez-la sur chaque vérificateur qui applique les révocations de cet émetteur.

Un fichier mis à jour qui reste sur la CA ne change rien, car le VPN tranche la décision chez son propre vérificateur. Vérifiez l’émetteur de la CRL, sa période de validité et les séries révoquées, et confirmez que le service recharge le fichier au lieu de mettre le précédent en cache. La propriété et le chemin comptent autant que le contenu : une CRL que le démon ne peut pas lire est indiscernable de l’absence de CRL. L’option crl-verify d’OpenVPN nomme le fichier que le démon lit, alors vérifiez ce chemin et la propriété du fichier dans la configuration du serveur.

Vérifiez par une véritable tentative de connexion, pas par l’horodatage du fichier.

Sachez quand une CRL est le mauvais outil

Si la clé privée de l’émetteur n’est plus digne de confiance, retirer des séries connues n’empêche pas un détenteur non autorisé de signer de nouveaux certificats. C’est une transition de confiance d’émetteur, donc une nouvelle CA et un plan de distribution, pas une entrée de plus dans la CRL. Qu’un ancien administrateur ait eu accès ne prouve pas en soi un usage abusif de la clé, alors établissez les faits avant de reconstruire la confiance.

Modifier à la main la base d’émission pour inverser une lettre de statut ne remplace pas une révocation signée et laisse la CRL incohérente avec les enregistrements.

Gardez la série, la CRL et l’étape de distribution dans une seule note, et le prochain audit devient un exercice de lecture. Le projet Easy-RSA documente les commandes prises en charge pour la version installée, et c’est la seule interface qui vaille d’être suivie.