Comment OpenVPN résout le certificat et la clé : PEM intégré ou chemin

Le message dit que OpenVPN ne peut pas charger un certificat intégré, et le nom de fichier que vous avez en tête affirme le contraire. Ce que le parseur a reçu compte plus que ce que contient le système de fichiers, car la directive cert accepte deux types de valeur totalement différents. L’un est un chemin qu’elle ouvre ; l’autre est du texte PEM arrivé à l’intérieur de la configuration. Tant que vous ne savez pas quelle forme le client en cours d’exécution a reçue, chaque correctif est une supposition.

Deux formes de stockage, une directive

Les directives cert, key et ca acceptent chacune un chemin ou un bloc intégré. Quand la valeur est un chemin, OpenVPN ouvre ce fichier et lit l’objet sur le disque. Quand la configuration contient un bloc délimité par des balises cert, la même directive consomme à la place le contenu entre ces balises, et aucun fichier séparé n’intervient.

Les deux formes produisent au final le même type d’objet, c’est pourquoi un déploiement fonctionnel peut passer de l’une à l’autre sans aucune autre modification. Un profil qui porte un certificat client et une clé privée intégrés est autonome, et le copier sur une autre machine fonctionne sans copier aussi un répertoire de certificats.

L’inverse n’est pas vrai. Déposer client.crt à côté d’un profil qui intègre ses propres données ne change rien, car rien dans la configuration ne renvoie à ce fichier. C’est la raison la plus fréquente pour laquelle un fichier qui existe manifestement semble ignoré.

Comment un bloc intégré devient un objet

Le contenu intégré est extrait de la configuration et remis au parseur PEM sous forme de texte. Ce parseur attend les limites habituelles : une ligne BEGIN, une charge base64 et une ligne END correspondante. Si le bloc a été tronqué par une copie ratée, enveloppé en HTML par une page de téléchargement ou ouvert dans un éditeur qui a normalisé les tirets, le parseur échoue sur un contenu qui semble présent.

<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>

C’est aussi pourquoi la formulation de l’erreur est trompeuse. Le mot intégré décrit où le chargeur a regardé, non ce qu’il y a trouvé. Un fichier nommé dans une configuration et un objet intégré dans celle-ci peuvent produire la même plainte quand les octets sous-jacents sont inutilisables.

Vérifiez quelle forme le profil chargé utilise réellement, et non quel fichier votre éditeur a ouvert par hasard :

grep -nE '^(ca|cert|key) |^<(ca|cert|key)>' client.ovpn

Comment une référence de chemin est résolue

Une valeur de chemin est ouverte relativement au répertoire de travail du client, et non au répertoire contenant la configuration. Sous systemd, ce répertoire de travail est ce que définit l’unité, et une exécution interactive depuis votre shell hérite de quelque chose de tout autre. C’est pourquoi le même fichier de configuration peut fonctionner quand vous le testez à la main et échouer en tant que service.

Les chemins relatifs héritent de la même ambiguïté. Quand vous voyez un nom de fichier nu, demandez quel est le répertoire courant du processus en production au lieu de supposer qu’il correspond à votre terminal.

Pour un certificat stocké séparément, une analyse hors ligne confirme l’objet avant que vous ne déboguiez quoi que ce soit au-dessus :

openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -check

Ces commandes prouvent que les fichiers sont lisibles et structurellement valides. Elles ne prouvent pas que le pair fait confiance à l’émetteur, que le certificat est encore dans sa fenêtre de validité ou que la clé lui appartient.

Ce que l’erreur du parseur peut et ne peut pas vous dire

Un échec d’analyse localise le problème sur une entrée et une étape. Il ne vous dit pas laquelle des deux formes de stockage le client a utilisée, et il ne vous dit pas si l’objet aurait été accepté. Ce sont des questions distinctes avec des preuves distinctes.

Une fois l’analyse réussie, l’échec suivant appartient à une étape ultérieure. Un rejet de confiance, une inadéquation d’usage ou une inadéquation de clé est signalé par le pair ou par la couche TLS, non par le chargeur. Remplacer le même fichier à répétition ne déplacera pas cette erreur.

Gardez la moitié sensible hors des rapports publics pendant votre investigation. Partagez les noms des directives, le texte de l’erreur et la structure du bloc, le matériel de clé et toute charge identifiante retirés. Le manuel openvpn(8) documente les deux formes des directives de fichier et le comportement du répertoire de travail qui les sous-tend.