Quel fichier CA va dans un profil OpenVPN avec mot de passe uniquement ?

Parcourez quatre questions dans l’ordre et la boîte de dialogue CA cesse d’être ambiguë. Quel matériel l’opérateur a-t-il réellement émis, que contient déjà le profil, quel champ pose la question et que se passe-t-il une fois le fichier chargé ? Arrêtez-vous à la première question à laquelle vous ne pouvez pas répondre à partir des instructions de l’opérateur lui-même, car deviner au-delà est précisément la façon dont un certificat CA public finit associé à une clé privée qui n’aurait jamais dû quitter le serveur.

L’ordre compte : les deux dernières questions n’ont de sens qu’une fois que vous savez quel matériel est censé exister.

Commencez par ce que le profil contient déjà

Ouvrez le profil dans un éditeur de texte et cherchez un bloc ca avant de chercher un fichier. Un bloc ca intégré contenant le CA public de l’opérateur signifie que le profil est autonome, et un client qui demande encore un fichier CA lit peut-être un autre profil ou une importation incomplète. Si le profil a plutôt une ligne ca pointant vers un chemin, ce chemin est relatif au répertoire de travail du client dans certaines intégrations et absolu dans d’autres. Notez quelle forme vous avez avant de changer quoi que ce soit.

ca /absolute/path/operator-ca.crt
auth-user-pass
remote-cert-tls server

Vérifiez le paquet livré pour les fichiers auxquels le profil fait référence : un certificat CA, parfois un certificat client et une clé séparés, et éventuellement un fichier tls-auth ou tls-crypt. Un profil qui fait référence à quatre fichiers et en arrive avec deux est incomplet, et aucun pointage de champs ne répare cela. Demandez la pièce manquante à l’opérateur au lieu de la remplacer par un certificat que vous avez par hasard.

Séparez quatre types de matériel

Le certificat CA est un matériel public utilisé pour vérifier l’identité du serveur. Un certificat client identifie l’utilisateur ou l’appareil auprès du serveur. Une clé privée est la moitié secrète de ce certificat client, et elle ne doit jamais être la clé de signature du CA ni une clé de serveur. Le matériel tls-auth ou tls-crypt est un secret partagé distinct qui protège le canal de contrôle. Ces quatre-là ne sont pas interchangeables, et pointer le champ CA vers un certificat client produit un échec de vérification qui ressemble à un problème de confiance.

Authentification par mot de passe uniquement change lequel des quatre vous faut-il, pas ce qu’ils signifient. Avec auth-user-pass et remote-cert-tls server, le client vérifie toujours le serveur par rapport à un CA, ce qui explique pourquoi le champ CA apparaît même lorsqu’aucun certificat client n’existe. La politique de l’opérateur décide si un certificat client est aussi exigé, et aucune boîte de dialogue ne peut vous le dire.

Pointez le client vers le fichier de confiance

Sélectionnez le fichier de certificat CA lui-même, pas le dossier qui le contient et pas un paquet .p12 qui contient une identité client. Sous Windows, la syntaxe des chemins et le sélecteur de fichiers se comportent différemment des exemples Linux de la plupart des guides, alors utilisez ce que le client installé accepte et confirmez que le fichier est lisible par le compte qui l’exécute. Un problème de permissions et un fichier manquant se ressemblent dans la boîte de dialogue mais produisent des lignes de journal différentes. Après la sélection, rouvrez les paramètres du profil pour confirmer que le client a conservé le choix.

<ca>
-----BEGIN CERTIFICATE-----
...operator-provided public CA...
-----END CERTIFICATE-----
</ca>

Si le client prend en charge les blocs intégrés, préférez le profil intégré de l’opérateur à un profil assemblé à la main. Le matériel intégré voyage avec le profil et survit à une réimportation, tandis qu’un chemin absolu casse dès que le profil est déplacé vers une autre machine.

Lisez l’erreur suivante, pas la même

L’intérêt de fournir le bon CA est de changer l’erreur, pas de la faire disparaître. Un échec d’identité du serveur après le chargement du CA signifie que le certificat ne correspondait pas au nom attendu ni à l’attente remote-cert-tls, ce qui est une réparation différente d’un rejet de mot de passe. Un rejet de mot de passe signifie que la couche TLS a réussi et que l’identifiant est faux. Gardez le premier nouveau message ; c’est le plus utile.

Un client qui se connecte mais n’atteint rien a dépassé la confiance et fait maintenant face à une question de routage ou de DNS.

Ne désactivez jamais la vérification pour passer cette boîte de dialogue. Un client qui accepte n’importe quel certificat n’a aucune raison de demander un CA, et le tunnel qu’il construit n’est pas celui que l’opérateur avait prévu.