Utilisez votre CA d'entreprise existante pour les pairs OpenVPN

Rien dans OpenVPN n'exige que le certificat provienne d'Easy-RSA, et un parc qui dispose déjà d'une PKI d'organisation ne devrait généralement pas en construire une seconde. Le vrai travail n'est pas de choisir un outil, mais de décider ce que signifient les identités émises, quels pairs le tunnel accepte et comment le renouvellement et la révocation arrivent au vérificateur. Parcourez les cinq étapes ci-dessous dans l'ordre, car une étape ultérieure ne peut pas réparer une décision de rôle prise lors de la première.

Émettez deux rôles au lieu d'une identité partagée

Chaque pair a besoin de son propre certificat et de la clé privée correspondante. Demandez à l'équipe PKI une identité de serveur portant l'usage serveur et des identités client distinctes portant l'usage client, afin que le tunnel puisse les distinguer lors de la poignée de main.

Résistez aux raccourcis qui apparaissent sous la pression des délais. Une clé de serveur web copiée sur des ordinateurs portables efface la distinction dont dépend le contrôle de rôle, et une clé de signature de CA installée sur un point de terminaison VPN transforme un hôte compromis en hiérarchie compromise. Un paquet PKCS12 peut porter une clé de point de terminaison et sa chaîne, mais il n'autorise jamais la réutilisation de cette identité dans un autre rôle.

Raccordez les entrées de confiance de chaque côté

Le client et le serveur ont chacun besoin d'une ancre de confiance, de leur propre identité et d'une attente de rôle explicite. Un fragment client qui énonce les trois ressemble à ceci.

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

Le côté serveur le reflète avec remote-cert-tls client et son propre certificat, et c'est ce qui empêche un certificat client d'être accepté comme serveur. Le contrôle du nom est une décision distincte du contrôle de rôle. Lisez la configuration déployée pour voir quel champ est comparé plutôt que de supposer une correspondance de nom d'hôte à la manière d'un navigateur. Les deux côtés devraient aussi être explicites sur l'émetteur auquel ils font confiance, car un chemin de fichier partagé sur tout le parc n'est pas la même chose qu'une politique partagée.

Livrez les intermédiaires sans élargir la confiance

Les deux côtés n'ont pas à partager une seule chaîne d'émission. Lorsqu'un pair présente un certificat signé par un intermédiaire, le côté vérificateur a besoin de cet intermédiaire disponible, et OpenVPN distingue l'entrée d'ancre de confiance des certificats supplémentaires utilisés pour compléter une chaîne présentée localement. La référence des options TLS d'OpenVPN 2.6 documente les deux.

Une CA intermédiaire n'est pas un problème en soi, mais une racine d'entreprise large jetée dans le paquet de confiance en est un. Plus l'ancre est large, plus de certificats satisfont le test de chaîne, et un contrôle de rôle ne transforme pas cela en liste de personnel autorisé. Resserrez l'ancre sur l'émetteur qui signe réellement les identités VPN, là où la hiérarchie le permet. Si elle ne le permet pas, documentez l'ancre plus large comme un risque accepté délibérément au lieu de la laisser implicite.

Convenez avec l'équipe PKI de la manière dont le renouvellement et la révocation parviennent aux vérificateurs VPN, y compris quels émetteurs comptent et qui publie la liste. Un point de distribution CRL intégré à un certificat est une instruction, pas la preuve que quelque chose l'a récupéré.

Décidez comment la révocation arrive réellement

crl-verify amène le vérificateur à consulter un fichier ou un point de terminaison, et cette disposition a besoin d'un responsable et d'un chemin d'actualisation. Une liste copiée une fois lors du déploiement cesse silencieusement de vous protéger la première fois qu'un certificat est révoqué.

Notez le temps de propagation attendu et testez-le avec un certificat que vous êtes prêt à révoquer. Si la liste ne peut pas être actualisée sur l'hôte VPN, l'alternative est une période de validité plus courte plus un processus de renouvellement qui s'exécute réellement, pas l'hypothèse que la révocation fonctionne parce qu'une URL existe.

Prouvez l'acceptation avec un vrai client

Connectez un client qui devrait être autorisé et confirmez les détails du certificat négocié dans le journal. Essayez ensuite les cas qui doivent échouer : un certificat client présenté comme serveur, un certificat d'un émetteur hors de l'ancre de confiance et un certificat révoqué si vous en avez un en trop.

Consignez l'émetteur accepté, le contrôle de rôle et la source de révocation à côté du profil. Cette consignation est ce dont le prochain ingénieur a besoin lorsqu'un appareil qui fonctionnait le mois dernier cesse de se connecter, et c'est aussi la preuve que la CA d'entreprise est utilisée dans une limite d'acceptation documentée plutôt que comme un dépotoir de confiance à usage général.