Gardez la clé de signature de l’AC OpenVPN hors de /etc/openvpn
L’espace de travail de l’AC émet des identités ; le service ne consomme que le matériel déployé. Donnez à chaque rôle son propre compte, répertoire et sauvegarde, et vérifiez les deux.
Deux répertoires qui se ressemblent dans un tutoriel remplissent des fonctions totalement différentes. L’un contient l’autorité de certification : sa clé privée, son compteur de numéros de série et l’enregistrement de tout ce qu’elle a signé. L’autre contient ce dont le démon a besoin pour démarrer et servir des clients. Placer les deux sur le même hôte sous le même compte est pratique pour un après-midi et coûteux pour le reste de la vie du déploiement, car le démon tourne alors à côté de l’unique clé capable de fabriquer n’importe quelle identité qu’il souhaite.
Ce que contient l’espace de travail de l’AC
Un répertoire PKI est un état d’émetteur, pas une configuration. Il contient la clé privée et le certificat de l’AC, un fichier de numéro de série, un index des certificats émis et le matériel par identité qui en a été produit.
Signer une demande modifie cet état, ce qui explique pourquoi l’espace de travail appartient à un compte contrôlé par l’administrateur sur un hôte où le service VPN ne tourne pas. Quiconque peut lire la clé privée de l’AC peut émettre un certificat auquel le serveur fera confiance ; la protection de la clé est donc tout le modèle de confiance en un seul fichier. La copier à un second endroit pour gagner une étape crée une seconde chose à protéger et une seconde chose à oublier. Chaque signature incrémente aussi le numéro de série et ajoute une entrée à l’index, ce qui explique pourquoi l’espace de travail est une copie d’état et non un dossier de fichiers.
Le certificat public de l’AC est différent. Il est destiné à être distribué, et c’est ce que les clients et les serveurs utilisent pour se vérifier mutuellement.
Ce que le démon lit au démarrage
Un serveur en fonctionnement consomme un petit ensemble : son propre certificat, sa propre clé privée, le certificat de l’AC pour vérifier les pairs et le matériel de clés que son mode choisi exige. Il lit ces chemins au démarrage et de nouveau au rechargement.
La propriété doit être évaluée par rapport à l’unité qui se lance réellement, pas par rapport à un shell root interactif. Le bac à sable déclaré peut rendre une partie du système de fichiers en lecture seule ou invisible même lorsqu’un test manuel en root réussit.
systemctl show -p User -p Group -p ReadOnlyPaths [email protected]
stat -c '%a %U:%G' /etc/openvpn/server/server.key
runuser -u openvpn -- test -r /etc/openvpn/server/server.key; echo $?Cette troisième ligne est celle que les gens sautent. Elle demande au compte du démon lui-même s’il peut lire la clé, et c’est la seule version de la question qui compte une fois les privilèges abandonnés. Un code de sortie nul en root ne dit rien de ce qui se passe après l’abandon.
Les deux chemins de panne méritent d’être séparés avant de modifier la moindre permission. Un échec de signature pointe vers le répertoire PKI, la permission de recherche sur ses répertoires parents et le compte qui exécute l’émetteur. Un échec de démarrage pointe vers l’unité, son répertoire de travail et les chemins nommés dans la configuration du serveur. Rendre toute l’arborescence lisible par tous ne corrige ni l’un ni l’autre et supprime la frontière dont les deux dépendent.
Pourquoi copier la clé de l’AC sur le serveur échoue plus tard
La copie commence généralement comme une manœuvre de débogage : quelqu’un veut renouveler un client sur l’hôte VPN, donc la clé de l’AC atterrit dans /etc/openvpn et le renouvellement fonctionne. La tâche immédiate réussit, et la frontière a disparu.
Puis le serveur est sauvegardé, et l’autorité de signature rejoint les sauvegardes. Un instantané, un paquet de support ou une copie du répertoire de configuration porte désormais la capacité d’émettre des identités de confiance aussi longtemps que l’AC est valide. Quiconque détient cette copie peut fabriquer un certificat pour n’importe quel nom que le serveur accepte, y compris des noms qui n’ont jamais été émis. Le seul enregistrement de cette émission est celui qu’ils choisissent de conserver.
Se remettre de cet état n’est pas une question de supprimer un fichier. Il faut décider si la clé a été exposée, faire tourner l’AC si c’est le cas et redistribuer la confiance à chaque pair. Un espace de travail séparé évite toute la conversation.
Comptes, répertoires, sauvegardes
Donnez à l’émetteur son propre compte et répertoire personnel, tenus hors de l’hôte VPN lorsque c’est praticable. Donnez au démon un compte différent, avec un accès en lecture au matériel déployé et un accès en écriture à rien qui émette des certificats. Déployez en copiant les certificats publics vers l’extérieur et jamais en tirant l’état privé de l’émetteur vers l’intérieur. Sauvegardez les deux rôles séparément, car leur sensibilité et leurs histoires de restauration diffèrent.
Après une révocation, mettez à jour le fichier CRL que nomme la configuration du serveur, puis rechargez le service pour que les nouvelles connexions le lisent. La documentation Easy-RSA couvre l’agencement de l’espace de travail et le flux de signature ; les règles de propriété qui l’entourent restent une décision concernant votre hôte. Confirmez ce que le service a chargé avec openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate au lieu de supposer que le rechargement l’a pris en compte.
Un test qui prouve la séparation
Vérifiez le cas négatif, pas seulement celui qui fonctionne. Signez un certificat depuis le compte de l’émetteur comme prévu, puis confirmez que le même compte ne peut ni démarrer le service ni lire la clé privée du serveur. Confirmez ensuite que le compte du démon ne peut pas lire la clé privée de l’AC.
Ces trois contrôles prennent quelques minutes et survivent aux changements de personnel, car ce sont des affirmations sur les permissions et non sur les habitudes. Notez le résultat avec les chemins et les comptes qu’il couvrait, plus la date à laquelle vous les avez exécutés. La personne suivante qui héritera de ce déploiement redérivera sinon la frontière à partir d’un tutoriel qui n’en a jamais eu. Un enregistrement daté est aussi ce qui fait que la prochaine revue prend des minutes au lieu d’un après-midi.