Fichier DH ou clé tls-auth ? Distinguer deux fichiers OpenVPN

Deux fichiers, deux directives et l’habitude de nommer les deux d’après ce qu’ils configurent. C’est ainsi qu’un dh.pem se retrouve sur une ligne tls-auth et que le client échoue avec un message sur un format de clé inattendu. La décision qui vous attend n’est pas quel fichier est le plus fort. C’est quel rôle le déploiement a réellement besoin, et trois conditions la tranchent : quel échange de clés votre pile TLS négociera, si vous voulez ou non une authentification du canal de contrôle, et si le matériel doit rester secret.

Répondez-y dans l’ordre et la question du fichier se répond d’elle-même. Sautez-les et les noms de directives commencent à paraître interchangeables, ce qui est exactement l’état dont l’erreur provient.

Lisez l’étiquette avant le nom du fichier

La première ligne du fichier est plus instructive que son nom, parce qu’un nom est une convention humaine et que l’étiquette est produite par l’outil. Les paramètres Diffie-Hellman portent une étiquette PEM BEGIN DH PARAMETERS. Une clé statique OpenVPN est une structure entièrement différente, avec son propre en-tête et sa charge hexadécimale.

Renommer ne convertit rien. Un fichier de paramètres nommé ta.key reste des paramètres, et une clé statique nommée dh.pem reste une clé statique ; l’analyseur lit le contenu et rejette la discordance. Vérifiez avant de modifier le profil :

head -n 1 dh.pem
head -n 1 ta.key

Trois conditions qui décident du fichier dont vous avez besoin

La première condition est l’échange. Une poignée de main Diffie-Hellman à champ fini a besoin d’un groupe, et la directive dh est l’endroit où le serveur nomme les paramètres correspondants. Une poignée de main sur courbe elliptique n’a pas du tout besoin de ce fichier, car la courbe est le jeu de paramètres. Si votre serveur ne négocie que des suites ECDHE, un fichier DH est un poids mort plutôt qu’une force supplémentaire.

La deuxième condition est l’authentification du canal de contrôle, une fonction distincte avec son propre matériel. Un fichier tls-auth est une clé statique partagée que les deux pairs détiennent, utilisée pour signer les paquets du canal de contrôle afin qu’un pair non authentifié ne puisse même pas terminer la poignée de main. Elle existe que vous utilisiez ou non un DH à champ fini, et elle n’a rien à voir avec les paramètres de groupe.

La troisième condition est le secret et la distribution. Les paramètres DH peuvent être publiés sans affaiblir la session, car les valeurs secrètes sont générées par poignée de main et ne quittent jamais les pairs. Une clé statique ne doit pas être publiée : ce sont les mêmes octets aux deux extrémités, elle ne tourne pas d’elle-même, et quiconque la détient peut produire des signatures valides du canal de contrôle. Ces deux réponses mènent à des règles de traitement complètement différentes, et c’est pourquoi l’un des fichiers peut rester dans un dépôt et l’autre non.

Générez le bon matériel pour chaque rôle

Utilisez l’outil qui produit le format attendu par la directive plutôt que de convertir entre eux. Pour la clé partagée sous OpenVPN 2.6, la forme typée du générateur énonce explicitement l’objectif.

openvpn --genkey tls-auth ta.key

Cette commande crée du nouveau matériel secret ; elle ne répare ni n’inspecte une clé existante, et la relancer vous donne une clé différente que les autres pairs ne possèdent pas. Copiez le fichier obtenu vers les pairs qui en ont besoin par un canal que vous utiliseriez pour tout secret partagé, et gardez la convention de sens cohérente : avec tls-auth, un côté utilise key-direction 0 et l’autre key-direction 1.

Les paramètres DH, quand vous en avez besoin, viennent de la génération de paramètres et non d’un générateur de clés, et leur provenance compte même si la sortie est publique. Un groupe tiré d’une source inconnue ne devient pas fiable parce qu’il est public ; il doit encore être un groupe sur lequel vos pairs s’accordent et qui n’est pas affaibli par sa taille ou sa construction.

Ce que dh none fait et ne fait pas

dh none est une vraie directive à la portée étroite : aucun fichier de paramètres à champ fini ne sera chargé, car la poignée de main utilise Diffie-Hellman sur courbe elliptique. Ce n’est pas un raccourci pour « sauter l’étape DH » au sens d’affaiblir quoi que ce soit, et elle ne dit certainement pas à OpenVPN d’accepter un autre fichier en remplacement.

Deux erreurs découlent d’une mauvaise lecture. La première est de supposer que dh none supprime le besoin de tls-auth, alors que les deux contrôlent des choses différentes. La seconde est de garder une ligne dh obsolète à côté d’une configuration uniquement courbe, puis de se demander quel fichier le serveur utilise réellement ; si la directive est présente, le fichier est lu, et un chemin cassé à cet endroit fait échouer le démarrage pour une raison sans rapport avec l’échange qui sera négocié.

Si le mauvais fichier est déjà déployé

Restaurez le secret prévu auprès du propriétaire du profil et ne touchez pas à la vérification du certificat pendant ce temps. La défaillance est une discordance de format, pas une défaillance de confiance, et désactiver la vérification pour contourner l’erreur remplace un problème de démarrage par un problème silencieux.

Séparez ensuite les deux incidents que les gens ont tendance à fusionner. Publier un fichier de paramètres DH est presque inoffensif, car les paramètres étaient publics par conception. Exposer la clé tls-auth est un autre événement : la clé authentifie les paquets du canal de contrôle pour chaque pair qui la détient, donc le remplacement doit être coordonné sur tout le déploiement plutôt qu’appliqué à un seul hôte.

Une vérification de cinq minutes tranche le cas dans lequel vous êtes : lisez la première ligne de chaque fichier, confirmez la directive qui le référence et confirmez que la distribution du fichier correspond à ce que le matériel exige. C’est un travail plus petit que de régénérer une PKI fonctionnelle, et c’est celui que les trois conditions désignaient depuis le début.