Un profil OpenVPN contient trois blocs de certificat : lequel est secret ?

Vous ouvrez un fichier .ovpn pour changer une ligne et trouvez trois blocs de base64 qui ressemblent tous à des identifiants. L’un est sans danger à publier, un autre est aussi sensible qu’un mot de passe, et le dernier est une clé publique qui ne signifie rien si autre chose n’a pas été signé avec sa paire. Les gens collent le fichier entier dans un fil d’assistance parce que les blocs semblent interchangeables, et c’est ainsi qu’une clé client finit dans une archive publique. Distinguer ce que fait chaque bloc explique l’essentiel de la confusion autour de ces profils, et vous indique aussi quelles pannes sont à corriger de votre côté.

Un fichier, trois blocs, des rôles différents

Un profil typique intègre un bloc ca, un bloc cert et un bloc key entre les marqueurs BEGIN et END, ou bien renvoie aux mêmes trois sous forme de fichiers séparés. Certains profils ajoutent un quatrième bloc pour une clé tls-auth ou tls-crypt, qui est un secret partagé et non un certificat. Le client lit chaque bloc selon la directive qui le nomme, donc les libellés comptent plus que l’ordre d’apparition.

Traitez le profil assemblé comme sensible jusqu’à ce que vous ayez réellement regardé à l’intérieur. Un certificat public et une clé privée peuvent se trouver à quelques lignes l’un de l’autre dans le même fichier, et une capture d’écran incluant l’en-tête peut inclure les deux. Masquer le base64 visible à la main n’est pas fiable non plus, car un bloc partiel laisse fuiter les métadonnées du certificat qui nomment votre déploiement. Copier les trois directives sans leurs valeurs suffit généralement à poser une question utile.

Les directives autour des blocs décident de leur usage. Changez ca et le client fait confiance à une autre autorité ; changez cert sans changer key et la poignée de main échoue sur une incohérence qui n’a rien à voir avec la confiance.

Le bloc CA est public, la clé de CA ne l’est jamais

Une autorité de certification signe des certificats qui lient une clé publique à une identité, et son propre certificat est l’ancre dont un client se sert pour décider si une chaîne est digne de confiance. Ce certificat est public par conception : le livrer dans chaque profil est normal, et c’est pourquoi un déploiement auto-signé peut fonctionner sans autorité commerciale.

Ce qui ne doit jamais apparaître dans un profil client, c’est la clé de signature privée de l’autorité. Le client n’en a besoin pour aucune validation, et sa présence signifie que quiconque détient le profil peut créer de nouvelles identités pour tout le déploiement.

Faire confiance à une autorité est aussi plus étroit que cela n’en a l’air. Un client qui accepte n’importe quel certificat signé par la CA acceptera encore un certificat émis pour un autre service sur la même CA. Les options qui épinglent le rôle ou le nom attendu du serveur comblent cette faille, et la référence des options TLS liste les directives de vérification qui le font.

Les certificats serveur et client pointent dans des directions opposées

Le certificat du serveur est ce que le client inspecte pour confirmer qu’il a atteint le bon point de terminaison. Votre certificat client va dans l’autre sens : le serveur s’en sert pour décider que cet appareil ou cet utilisateur est bien un qu’il a enregistré. Même format, sens de confiance opposé.

Une adresse n’est pas une identité. Atteindre la bonne IP ne prouve rien sur qui a répondu, c’est pourquoi la vérification du nom d’hôte ou du nom du certificat relève toujours du profil. Un mot de passe de compte ne remplace pas non plus discrètement un certificat client exigé, car les deux sont contrôlés à des étapes différentes et un déploiement peut exiger les deux.

La clé privée du client est la partie qui doit rester privée. Si elle a pu être exposée, supprimer le fichier de votre ordinateur portable ne change rien sur le serveur, qui continuera d’accepter le certificat correspondant jusqu’à ce que l’opérateur le révoque. Demander à l’opérateur de remplacer ou de révoquer cette identité est la seule correction qui voyage avec vous.

Deux invites qui se ressemblent et ne sont pas identiques

Une clé stockée sous forme chiffrée demande une phrase de passe avant que le client puisse l’utiliser. Le service VPN peut demander séparément un mot de passe de compte, et les deux invites peuvent apparaître à quelques secondes d’intervalle avec presque la même formulation. La phrase de passe protège un fichier sur votre disque ; le mot de passe prouve un compte auprès d’un serveur. Les confondre envoie les gens vers des réinitialisations qui ne peuvent en aucun cas aider.

Lisez l’invite avant de réinitialiser quoi que ce soit. Une réinitialisation de mot de passe de compte ne fait rien pour une phrase de passe de clé oubliée, un certificat révoqué ou un certificat expiré, et réinitialiser le mot de passe alors que la panne est une validation de certificat transforme une correction de deux minutes en dossier d’assistance. Si la plainte mentionne des dates de validité, vérifiez d’abord l’horloge de l’appareil, puis la fenêtre propre du certificat nommé.

Quand le certificat a réellement expiré, le remplacement doit venir de celui qui l’a émis. Une clé appartenant à quelqu’un d’autre n’est pas une voie de renouvellement, pas plus qu’emprunter un profil qui fonctionne à un collègue.

Ce qu’une poignée de main propre prouve et ce qu’elle ne prouve pas

Atteindre une poignée de main TLS terminée signifie que la relation d’identité configurée a tenu : le certificat du serveur s’est chaîné à votre CA et votre certificat a été accepté. Cela ne dit rien de la politique de journalisation de l’opérateur, ni si vos applications fonctionneront une fois le tunnel monté.

Les routes et le DNS sont des étapes ultérieures de la connexion, donc un hôte intranet injoignable après une connexion réussie est un problème de connectivité et non de certificat. Travaillez cette couche plutôt que d’échanger les identifiants, et gardez ensemble l’origine du profil, son matériel privé et ses contrôles d’identité quand vous le remettez à quelqu’un.