remote-cert-tls server : ce que la directive vérifie dans un profil OpenVPN

Trois questions différentes reçoivent une réponse de trois parties différentes d'un profil OpenVPN, et c'est en les fusionnant que les gens finissent par désactiver une vérification qui fonctionnait. Le certificat du pair est-il signé par l'autorité à laquelle je fais confiance ? Ce certificat déclare-t-il le rôle de serveur TLS ? Est-ce bien le serveur précis que je voulais joindre ? remote-cert-tls server ne répond qu'à la question du milieu, et il le fait en lisant les extensions à l'intérieur du certificat.

Trois vérifications faciles à fusionner dans votre tête

L'ancre de confiance réside dans la directive ca. La vérification du rôle appartient à remote-cert-tls. La vérification d'identité appartient à verify-x509-name, lorsqu'un profil l'utilise, ou à toute vérification de nom que le déploiement ajoute.

Elles couvrent des défaillances différentes :

Un profil peut avoir les trois et rester faible si l'autorité de certification est partagée trop largement, ce qui est une question de gestion des clés et non de directive.

Ce que lit la vérification du rôle

La directive est une macro. Elle se développe en une exigence d'usage de clé et une exigence d'usage étendu de clé nommant le rôle de serveur web TLS, donc le certificat du pair doit réellement déclarer cette finalité. Un certificat émis pour l'authentification du client ne la satisfait pas, même lorsque la même autorité a signé les deux.

Cela compte parce qu'une autorité partagée est courante dans les petits déploiements. Une autorité signe chaque client et le serveur, et sans vérification du rôle, n'importe lequel de ces certificats pourrait achever le côté serveur de la poignée de main. La vérification ne rend pas ce scénario impossible, mais elle en retire la version triviale.

La directive est asymétrique par conception : les clients portent remote-cert-tls server, et les serveurs portent remote-cert-tls client. Échangez-les et chaque connexion échoue avec une erreur de rôle qui ressemble à un certificat cassé.

Les profils plus anciens utilisent parfois ns-cert-type dans le même but. Les pages de manuel actuelles considèrent cette option comme remplacée, donc un profil qui s'y fie encore mérite une migration plutôt qu'un débogage.

Pourquoi la désactiver ressemble à une solution

Quand la vérification du rôle échoue, la connexion s'arrête avec une erreur de vérification et le geste évident est de supprimer la ligne. La connexion monte alors, ce qui donne l'impression d'un progrès et constitue en fait le mode de défaillance que la directive existe pour empêcher. Vous acceptez maintenant un pair dont le certificat n'était jamais destiné à ce rôle.

Lisez plutôt l'erreur. Elle nomme la vérification qui a échoué, et le certificat de l'autre côté peut être inspecté pour voir quelles extensions il porte réellement. Deux minutes de lecture tranchent si la faute est dans l'émission ou dans la configuration. Deviner coûte un après-midi et se termine généralement par un profil affaibli. Un certificat de serveur renouvelé qui a perdu son usage étendu de clé est une vraie faute dans le renouvellement, pas une raison de relâcher le client.

La vérification du nom est une directive distincte

Satisfaire la vérification du rôle dit que le pair est un serveur signé par votre autorité. Cela ne dit rien sur lequel, ce qui compte quand la même autorité émet des certificats pour plusieurs passerelles et que l'une d'elles est compromise ou réaffectée.

verify-x509-name compare le sujet du certificat à une valeur que vous configurez, avec des modes de correspondance pour un sujet exact, un préfixe ou un seul champ. Utilisez le champ qui identifie réellement la passerelle, et attendez-vous à le mettre à jour délibérément quand le nom change.

Aucune des deux directives ne remplace une bonne gestion des clés. Si le fichier de clé du client est copié un peu partout avec le profil, l'identité du pair n'est aussi solide que la liste de distribution.

Inspectez le certificat avant de modifier le profil

Lisez le certificat du pair et le journal du client, dans cet ordre. Le certificat vous dit quels rôles il déclare ; le journal vous dit quelle vérification l'a rejeté.

Ces commandes impriment les extensions d'usage et les lignes de vérification d'une connexion détaillée :

openssl x509 -in server.crt -noout -text | grep -A1 -E "Key Usage|Extended Key Usage"
sudo openvpn --config client.ovpn --verb 4 2>&1 | grep -i verify

Si les extensions montrent le rôle de serveur et que le journal signale encore un échec de rôle, le profil pointe probablement vers le mauvais fichier de certificat plutôt que vers un mauvais certificat. Si les extensions ne montrent que l'authentification du client, cessez de regarder le client et corrigez l'émission. Dans tous les cas, restaurez la vérification avant de déclarer la connexion saine, car une poignée de main réussie après la suppression de la vérification prouve moins que l'erreur qu'elle a remplacée.