Easy-RSA dit que la PKI est absente ? Il regarde ailleurs

La commande s'arrête sur un ca.crt manquant ou un index.txt manquant, alors que la CA émet des certificats depuis des mois. Rien n'a changé du côté de l'autorité ; la commande a simplement regardé ailleurs. Easy-RSA 3 résout un répertoire PKI à partir d'une option, d'une variable d'environnement, d'un fichier vars et d'une valeur par défaut intégrée, et chacune de ces sources peut pointer loin de l'autorité du déploiement. Vérifiez laquelle a gagné avant de créer quoi que ce soit.

L'erreur nomme un fichier, pas un répertoire

Le répertoire d'installation et le répertoire de l'émetteur sont deux endroits différents. Trouver easyrsa sur la machine prouve seulement que l'outil est installé, pas qu'il a trouvé l'autorité à laquelle votre VPN fait confiance.

C'est pourquoi réinstaller le paquet ou relancer l'étape init semble productif et ne change rien.

Vérifiez le sélecteur avant tout le reste

Dans Easy-RSA 3, le sélecteur est EASYRSA_PKI ou l'option correspondante --pki-dir. Indiquez un chemin absolu comme --pki-dir=/srv/pki/office, et la réponse cesse de dépendre de l'endroit où vous vous trouviez. Cette seule habitude élimine toute une classe de ce bogue, surtout pour les scripts lancés depuis cron ou depuis un checkout de CI.

Confirmez d'abord la génération, car l'habitude d'Easy-RSA 2 avec un fichier vars plus build-key est un modèle différent de celui qu'attend Easy-RSA 3. easyrsa --version affiche la génération avant de faire quoi que ce soit d'autre, et ./easyrsa --help liste les sous-commandes : une cible build-key signifie 2.x, tandis que build-client-full signifie 3.x. Transporter un ancien chemin KEY_DIR vers un appel 3.x parce que le nom du répertoire semble familier produit exactement cette erreur.

Si la chaîne de version et la syntaxe de la commande ne concordent pas, arrêtez-vous et lisez la documentation de la version installée.

La priorité explique un fichier vars perdant

La priorité documentée est l'option de ligne de commande, puis l'environnement, puis le fichier vars, puis la valeur par défaut intégrée. Une valeur correcte dans vars perd donc face à une variable d'environnement héritée, et c'est la version silencieuse de cette défaillance. Inspectez les variables prévues et la sélection de fichier au lieu de déverser tout l'environnement dans un ticket. La différence entre les deux est généralement un secret.

Parcourez la chaîne dans l'ordre et notez quelle source a fourni le chemin utilisé par la commande. Une fois que vous le savez, le correctif est un indicateur ou un export, pas une nouvelle autorité de certification.

La référence de configuration d'Easy-RSA définit le sélecteur et la priorité, et c'est la citation à mettre dans le ticket.

Confirmez l'émetteur avec du matériel public

Avec l'émetteur habituel basé sur des fichiers, lisez ca.crt et comparez son empreinte à l'enregistrement d'émetteur que vous avez approuvé. Un nom de sujet identique n'est pas une preuve d'identité, pas plus qu'un répertoire nommé production. Seule l'empreinte relie le fichier trouvé à l'autorité à laquelle vos pairs ont été invités à faire confiance.

Un contrôle en lecture seule suffit : openssl x509 -in /srv/pki/office/ca.crt -noout -subject -issuer -serial -fingerprint -sha256.

Établissez ensuite le rôle du répertoire. Un répertoire de demandes utilisé par un client n'est pas une base de données d'émetteur, et une clé de signature conservée hors ligne n'a rien à faire sur chaque hôte VPN. Un ca.key manquant est une propriété de conception dans cette disposition, pas une permission d'inventer une autorité de remplacement.

Si l'état a vraiment disparu

Parfois le chemin est correct et l'état n'est véritablement pas là. Un index.txt vide et un compteur de série réinitialisé vous donnent une PKI qui semble saine et ne peut rien prouver sur les certificats qu'elle n'a jamais vus : les renouvellements ne révoqueront pas les anciens, et les nouveaux numéros entreront en collision avec l'historique. Restaurez plutôt depuis la sauvegarde approuvée de la CA, car initialiser une PKI vide ailleurs ne fait que déplacer l'erreur et laisse derrière elle une seconde autorité sans rapport.

Une fois le chemin et l'émetteur d'accord, traitez la défaillance suivante selon son mérite. Permission denied, une clé de signature qui a besoin de sa phrase secrète et un enregistrement d'émission manquant sont trois pannes différentes, et une seule concerne le répertoire que vous venez de corriger.

Ne supprimez jamais le chiffrement des clés et n'élargissez pas les permissions de répertoire pour masquer une erreur de chemin. L'erreur est peu coûteuse à corriger ; la réparation ne l'est pas.