OpenVPN sans certificat client : une politique de serveur, pas un profil

Vous supprimez les lignes de certificat et de clé, vous remettez le profil, et la connexion échoue toujours avec une erreur de certificat. Le profil n'a jamais été ce qui imposait cette exigence. C'est le serveur qui décide si un certificat client est obligatoire, et aucune modification côté client ne le négocie. Le correctif est donc un changement de politique côté serveur, fait délibérément, avec tout ce qui en dépend mis à jour dans la même passe.

Le profil n'est pas la politique

Community OpenVPN 2.6 est livré avec des certificats clients obligatoires, car verify-client-cert vaut par défaut require. Le passer à none est ce qui arrête l'exigence d'un certificat et confie l'authentification du client à la disposition nom d'utilisateur et mot de passe que le serveur exécute déjà. Les anciens guides se tournent vers client-cert-not-required, l'orthographe héritée de la même idée, alors utilisez la directive que documente votre version installée. Dans tous les cas, le changement se fait sur le serveur, et aucun profil client ne peut l'exécuter.

Le fragment ci-dessous est l'intégralité du changement côté serveur, et à lui seul il ne constitue pas une configuration d'authentification fonctionnelle. verify-client-cert none supprime l'exigence de certificat, tandis que username-as-common-name fait du nom de compte l'identité que voient les rappels ultérieurs et les fichiers par client. Aucune des deux lignes ne vérifie de mot de passe, donc un vérificateur doit toujours exister.

verify-client-cert none
username-as-common-name

Ce vérificateur est un greffon ou un script piloté par auth-user-pass-verify, et il doit être en place avant que l'une ou l'autre des lignes ci-dessus ne signifie quoi que ce soit. Inverser l'ordre vous donne une fenêtre où le serveur ne demande aucun certificat et ne vérifie aucun compte.

Ce qui vérifie encore le serveur

Abandonner le certificat client ne veut pas dire abandonner TLS. Le serveur garde son certificat et sa clé, et le client garde la confiance en l'autorité de certification et les contrôles de nom d'hôte qui l'empêchent de parler à un imposteur. Retirer remote-cert-tls server ou le paquet d'autorités parce que le client n'a plus de certificat est une mauvaise lecture courante et grave, et la référence 2.6 précise explicitement que les deux directions sont indépendantes. L'une prouve le serveur au client ; l'autre prouve le client au serveur.

Un profil peut aussi porter un bloc tls-auth ou tls-crypt. C'est une clé partagée de canal de contrôle avec son propre cycle de distribution et de rotation, donc un fichier sans lignes de certificat ni de clé n'est pas automatiquement sûr à publier. Traitez-le comme un secret tant que vous ne l'avez pas lu.

Un fichier de certificat copié depuis un profil fonctionnel ne prouve rien en soi ; la possession signifie détenir la clé privée qui lui correspond, ce qu'un déploiement authentifié par certificat vérifie. Un fichier qui contient un certificat n'est pas un fichier avec lequel on peut s'authentifier.

Ce que le vérificateur doit faire

L'exigence de certificat supprimée, tout repose sur le vérificateur : un greffon, ou un script piloté par auth-user-pass-verify. Il doit rejeter les identifiants invalides, rejeter les comptes désactivés ou inéligibles, et échouer en mode fermé lorsqu'il ne peut pas joindre son backend. username-as-common-name est souvent activé à ses côtés, et il change l'identité que voient les rappels ultérieurs et les fichiers de configuration par client. Il ne vérifie pas de mot de passe et ne rend pas éligible un compte qui ne l'est pas. Ce sont des tâches distinctes, et les confondre est la façon dont une migration passe son test du chemin heureux et échoue à son premier incident réel.

Testez les cas négatifs avec autant de soin que le cas positif. Un profil qui affiche une invite de mot de passe ne prouve que la capacité du client à dessiner une invite, tandis qu'un serveur qui accepte le mauvais mot de passe prouve quelque chose de bien pire. Ajoutez un compte désactivé et un identifiant expiré au jeu de tests, pas seulement un mauvais mot de passe.

Changez la politique, le profil et le mappage ensemble

Coordonnez trois choses : la directive du serveur, le profil du client et le mappage d'identité par client. Changez-les séparément et les clients échouent avant la vérification, ou se connectent sous un nom que l'administrateur n'attendait pas, ce qui est pire parce que cela ressemble à un succès. Une connexion qui réussit sous la mauvaise identité est plus difficile à remarquer qu'une connexion qui échoue.

Gardez deux comptes de test pour ce chemin, un valide et un connu comme mauvais, et utilisez les deux après tout changement du vérificateur. Le compte valide prouve le chemin heureux et le mappage d'identité ; le mauvais prouve que le rejet fonctionne toujours. Aucun des deux tests ne vous dit rien sur les règles d'éligibilité, alors ajoutez un compte qui devrait être refusé pour des raisons de politique si le déploiement en a. Lancez les trois après chaque changement, car un vérificateur qui se met à tout accepter ressemble exactement à une connexion fonctionnelle.

Consignez les méthodes d'authentification que le serveur accepte réellement, pas celles que le profil suggère. Cette consignation répond à la question que les gens ne cessent de poser, à savoir qui peut se connecter à ce service. Elle survit aussi à l'administrateur suivant, qui, sinon, la redécouvrirait à partir d'une capture de paquets.