One place for hosting & domains

      place

      Comment mettre en place un pare-feu avec UFW sur Ubuntu 20.04


      Introduction

      UFW, ou Uncomplicated Firewall, est une interface de gestion de pare-feu simplifiée qui masque la complexité des technologies de filtrage de paquets de niveau inférieur telles que iptables et nftables. Si vous souhaitez commencer à sécuriser votre réseau, et vous n’êtes pas sûr de l’outil à utiliser, UFW peut être le bon choix pour vous.

      Ce tutoriel vous montrera comment mettre en place un pare-feu avec UFW sur Ubuntu 20.04.

      Conditions préalables

      Pour suivre ce tutoriel, vous aurez besoin de :

      UFW est installé par défaut sur Ubuntu. S’il a été désinstallé pour une raison quelconque, vous pouvez l’installer avec sudo apt install ufw.

      Étape 1 — Utilisation d’IPv6 avec UFW (facultatif)

      Ce tutoriel a été écrit en tenant compte d’IPv4, mais il fonctionnera aussi bien pour IPv6 pour autant que vous l’ayez activé. Si votre serveur Ubuntu a activé IPv6, assurez-vous qu’UFW est configuré pour prendre en charge IPv6 afin de gérer les règles de pare-feu pour IPv6 en plus d’IPv4. Pour ce faire, ouvrez la configuration UFW avec nano ou votre éditeur préféré.

      • sudo nano /etc/default/ufw

      Ensuite, assurez-vous que la valeur d’IPV6 est yes. Cela devrait ressembler à ceci :

      /etc/default/ufw excerpt

      IPV6=yes
      

      Enregistrez et fermez le fichier. Maintenant, lorsque l’UFW est activé, il sera configuré pour écrire les règles de pare-feu IPv4 et IPv6. Cependant, avant d’activer UFW, nous voulons nous assurer que votre pare-feu est configuré pour vous permettre de vous connecter via SSH. Commençons par définir les politiques par défaut.

      Étape 2 — Mise en place des politiques par défaut

      Si vous commencez tout juste à utiliser votre pare-feu, les premières règles à définir sont vos politiques par défaut. Ces règles contrôlent la manière de traiter le trafic qui ne correspond pas explicitement à d’autres règles. Par défaut, UFW est configuré pour refuser toutes les connexions entrantes et autoriser toutes les connexions sortantes. Cela signifie que toute personne essayant d’atteindre votre serveur ne pourra pas se connecter, tandis que toute application à l’intérieur du serveur pourra atteindre le monde extérieur.

      Remettons vos règles UFW à leur valeur par défaut afin que nous puissions être sûrs que vous pourrez suivre ce tutoriel. Pour définir les valeurs par défaut utilisées par UFW, utilisez ces commandes :

      • sudo ufw default deny incoming
      • sudo ufw default allow outgoing

      Ces commandes définissent les valeurs par défaut pour refuser les connexions entrantes et autoriser les connexions sortantes. Ces paramètres par défaut du pare-feu peuvent suffire pour un ordinateur personnel, mais les serveurs doivent généralement répondre aux demandes entrantes d’utilisateurs extérieurs. Nous verrons cela plus loin.

      Étape 3 — Autoriser les connexions SSH

      Si nous activions notre pare-feu UFW maintenant, il refuserait toutes les connexions entrantes. Cela signifie que nous devrons créer des règles qui autorisent explicitement les connexions entrantes légitimes – connexions SSH ou HTTP, par exemple – si nous voulons que notre serveur réponde à ce type de demandes. Si vous utilisez un serveur cloud, vous voudrez probablement autoriser les connexions SSH entrantes afin de pouvoir vous connecter à votre serveur et le gérer.

      Pour configurer votre serveur afin d’autoriser les connexions SSH entrantes, vous pouvez utiliser cette commande :

      Cela créera des règles de pare-feu qui autoriseront toutes les connexions sur le port 22, qui est le port que le démon SSH écoute par défaut. UFW sait quel port allow ssh désigne parce qu’il est listé comme un service dans le fichier /etc/services.

      Cependant, nous pouvons réellement écrire la règle équivalente en spécifiant le port au lieu du nom du service. Par exemple, cette commande fonctionne de la même manière que celle ci-dessus :

      Si vous avez configuré votre démon SSH pour utiliser un port différent, vous devrez spécifier le port approprié. Par exemple, si votre serveur SSH écoute sur le port 2222, vous pouvez utiliser cette commande pour autoriser les connexions sur ce port :

      Maintenant que votre pare-feu est configuré pour autoriser les connexions SSH entrantes, nous pouvons l’activer.

      Étape 4 — Activation d’UFW

      Pour activer UFW, utilisez cette commande :

      Vous recevrez un avertissement qui indique que la commande peut perturber les connexions SSH existantes. Nous avons déjà mis en place une règle de pare-feu qui autorise les connexions SSH, donc nous pouvons continuer. Répondez à l’invite avec y et appuyez sur ENTER.

      Le pare-feu est maintenant actif. Exécutez la commande sudo ufw status verbose pour connaître les règles fixées. Le reste de ce tutoriel explique plus en détail comment utiliser UFW, par exemple en autorisant ou en refusant différents types de connexions.

      Étape 5 — Autoriser d’autres connexions

      À ce stade, vous devez autoriser toutes les autres connexions auxquelles votre serveur a besoin de répondre. Les connexions que vous devez autoriser dépendent de vos besoins spécifiques. Heureusement, vous savez déjà comment écrire des règles qui autorisent les connexions basées sur un nom de service ou un port ; nous l’avons déjà fait pour SSH sur le port 22. Vous pouvez également le faire pour :

      • HTTP sur le port 80, qui est ce qu’utilisent les serveurs web non cryptés, en utilisant sudo ufw allow http ou sudo ufw allow 80
      • HTTPS sur le port 443, qui est ce qu’utilisent les serveurs web cryptés, en utilisant sudo ufw allow https ou sudo ufw allow 443

      Il existe plusieurs autres moyens d’autoriser d’autres connexions, outre la spécification d’un port ou d’un service connu.

      Plages de ports spécifiques

      Vous pouvez spécifier des plages de ports avec UFW. Certaines applications utilisent plusieurs ports, au lieu d’un seul.

      Par exemple, pour autoriser les connexions X11 qui utilisent les ports 60006007, utilisez ces commandes :

      • sudo ufw allow 6000:6007/tcp
      • sudo ufw allow 6000:6007/udp

      Lorsque vous spécifiez des plages de ports avec UFW, vous devez spécifier le protocole (tcp ou udp) auquel les règles doivent s’appliquer. Nous n’avons pas mentionné cela auparavant car le fait de ne pas spécifier le protocole autorise automatiquement les deux protocoles, ce qui est correct dans la plupart des cas.

      Adresses IP spécifiques

      Lorsque vous travaillez avec UFW, vous pouvez également spécifier des adresses IP. Par exemple, si vous souhaitez autoriser les connexions à partir d’une adresse IP spécifique, comme une adresse IP professionnelle ou personnelle de 203.0.113.4, vous devez spécifier from, puis l’adresse IP :

      • sudo ufw allow from 203.0.113.4

      Vous pouvez également spécifier un port spécifique auquel l’adresse IP est autorisée à vous connecter en ajoutant to any port suivi du numéro de port. Par exemple, Si vous souhaitez autoriser 203.0.113.4 à se connecter au port 22 (SSH), utilisez cette commande :

      • sudo ufw allow from 203.0.113.4 to any port 22

      Sous réseaux

      Si vous souhaitez autoriser un sous-réseau d’adresses IP, vous pouvez le faire en utilisant la notation CIDR pour spécifier un masque de réseau. Par exemple, si vous souhaitez autoriser toutes les adresses IP allant de 203.0.113.1 à 203.0.113.254 vous pourriez utiliser cette commande :

      • sudo ufw allow from 203.0.113.0/24

      De même, vous pouvez également spécifier le port de destination auquel le sous-réseau 203.0.113.0/24 est autorisé à se connecter. Une fois encore, nous utiliserons le port 22 (SSH) comme exemple :

      • sudo ufw allow from 203.0.113.0/24 to any port 22

      Connexion à une interface réseau spécifique

      Si vous souhaitez créer une règle de pare-feu qui s’applique uniquement à une interface réseau spécifique, vous pouvez le faire en spécifiant « allow in on » suivi du nom de l’interface.

      Vous pouvez consulter vos interfaces réseau avant de continuer. Pour ce faire, utilisez cette commande :

      Output Excerpt

      2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state . . . 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default . . .

      Le résultat mis en évidence indique les noms d’interface réseau. Elles sont généralement nommées par quelque chose comme : eth0 ou enp3s2.

      Donc, si votre serveur a une interface réseau publique appelée eth0, vous pouvez l’autoriser à recevoir du trafic HTTP (port 80) avec cette commande :

      • sudo ufw allow in on eth0 to any port 80

      Cela permettrait à votre serveur de recevoir des requêtes HTTP de l’Internet public.

      Ou, si vous voulez que votre serveur de base de données MySQL (port 3306) écoute les connexions sur l’interface de réseau privé eth1, par exemple, vous pourriez utiliser cette commande :

      • sudo ufw allow in on eth1 to any port 3306

      Cela permettrait à d’autres serveurs de votre réseau privé de se connecter à votre base de données MySQL.

      Étape 6 — Refuser les connexions

      Si vous n’avez pas modifié la politique par défaut des connexions entrantes, UFW est configuré pour refuser toutes les connexions entrantes. En général, cela simplifie le processus de création d’une politique de pare-feu sécurisée en vous obligeant à créer des règles qui autorisent explicitement le passage de ports et d’adresses IP spécifiques.

      Cependant, il peut arriver que vous souhaitiez refuser des connexions spécifiques en fonction de l’adresse IP source ou du sous-réseau, peut-être parce que vous savez que votre serveur est attaqué à partir de là. De plus, si vous souhaitez modifier votre politique d’entrée par défaut a allow (ce qui n’est pas recommandé), vous devrez créer des règles deny pour tous les services ou adresses IP pour lesquels vous ne souhaitez pas autoriser les connexions.

      Pour écrire des règles deny, vous pouvez utiliser les commandes décrites ci-dessus, en remplaçant allow par deny.

      Par exemple, pour refuser des connexions HTTP, vous pourriez utiliser cette commande :

      Ou si vous souhaitez refuser toutes les connexions à partir de 203.0.113.4 vous pouvez utiliser cette commande :

      • sudo ufw deny from 203.0.113.4

      Examinons maintenant comment supprimer des règles.

      Étape 7 — Suppression de règles

      Savoir comment supprimer des règles de pare-feu est tout aussi important que de savoir comment les créer. Il existe deux façons différentes de spécifier les règles à supprimer : par le numéro de la règle ou par la règle elle-même (de la même façon que les règles ont été spécifiées lors de leur création). Nous commencerons par la méthode delete by rule number, car elle est plus facile.

      Par numéro de règle

      Si vous utilisez le numéro de règle pour supprimer des règles de pare-feu, la première chose que vous voudrez faire est d’obtenir une liste de vos règles de pare-feu. La commande UFW status permet d’afficher des numéros à côté de chaque règle, comme illustré ici :

      Numbered Output:

      Status: active To Action From -- ------ ---- [ 1] 22 ALLOW IN 15.15.15.0/24 [ 2] 80 ALLOW IN Anywhere

      Si nous décidons que nous voulons supprimer la règle 2, celle qui autorise les connexions sur le port 80 (HTTP), nous pouvons la spécifier dans une commande de suppression UFW comme celle-ci :

      Cela affichera une demande de confirmation puis supprimera la règle 2, qui autorise les connexions HTTP. Notez que si vous avez activé IPv6, vous voudrez également supprimer la règle IPv6 correspondante.

      Par règle réelle

      L’alternative aux numéros de règle est de spécifier la règle réelle à supprimer. Par exemple, si vous voulez supprimer la règle allow http, vous pouvez l’écrire comme ceci :

      • sudo ufw delete allow http

      Vous pouvez également spécifier la règle par allow 80, au lieu de par nom de service :

      Cette méthode supprimera les règles IPv4 et IPv6, si elles existent.

      Étape 8 — Vérification de l’état et des règles d’UFW

      À tout moment, vous pouvez vérifier le statut d’UFW avec cette commande :

      Si UFW est désactivé, ce qui est le cas par défaut, vous verrez quelque chose comme ceci :

      Output

      Status: inactive

      Si UFW est actif, ce qui devrait être le cas si vous avez suivi l’étape 3, la sortie indiquera qu’il est actif et énumérera toutes les règles qui sont définies. Par exemple, si le pare-feu est configuré pour autoriser les connexions SSH (port 22) de n’importe où, la sortie pourrait ressembler à ceci :

      Output

      Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), disabled (routed) New profiles: skip To Action From -- ------ ---- 22/tcp ALLOW IN Anywhere

      Utilisez la commande status si vous souhaitez vérifier comment UFW a configuré le pare-feu.

      Étape 9 – Désactivation ou réinitialisation d’UFW (facultatif)

      Si vous décidez que vous ne voulez pas utiliser UFW, vous pouvez le désactiver avec cette commande :

      Toutes les règles que vous avez créées avec UFW ne seront plus actives. Vous pourrez toujours exécuter la commande sudo ufw enable si vous devez l’activer plus tard.

      Si vous avez déjà configuré des règles UFW mais que vous décidez de tout recommencer, vous pouvez utiliser la commande reset :

      Cela désactivera l’UFW et supprimera toutes les règles qui ont été définies précédemment. Gardez à l’esprit que les règles par défaut ne retrouveront pas leurs paramètres d’origine, si vous les avez modifiées à un moment quelconque. Cela devrait vous permettre de repartir à zéro avec UFW.

      Conclusion

      Votre pare-feu est maintenant configuré pour autoriser (au moins) les connexions SSH. Veillez à autoriser toutes les autres connexions entrantes dont votre serveur a besoin, tout en limitant les connexions inutiles, afin que votre serveur soit fonctionnel et sécurisé.

      Pour en savoir plus sur les configurations UFW les plus courantes, consultez le tutoriel UFW Essentials : Règles et commandes communes de pare-feu.



      Source link

      Comment mettre en place et configurer un serveur OpenVPN sur Ubuntu 20.04


      Introduction

      Un réseau privé virtuel (VPN) vous permet de traverser des réseaux non fiables comme si vous étiez sur un réseau privé. Il vous donne la liberté d’accéder à l’internet en toute sécurité depuis votre smartphone ou votre ordinateur portable lorsque vous êtes connecté à un réseau non sécurisé, comme le WiFi d’un hôtel ou d’un café.

      Combinée aux connexions HTTPS, cette configuration vous permet de sécuriser vos connexions et transactions sans fil. Vous pouvez contourner les restrictions géographiques et la censure, et protéger votre emplacement et tout trafic HTTP non crypté contre les réseaux non fiables.

      OpenVPN est une solution VPN de sécurité de la couche transport (TLS) complète et open-source qui s’adapte à un large éventail de configurations. Dans ce tutoriel, vous allez installer OpenVPN sur un serveur Ubuntu 20.04, puis le configurer pour qu’il soit accessible depuis une machine cliente.

      Remarque : si vous prévoyez de configurer un serveur OpenVPN sur une Droplet DigitalOcean, sachez que, comme de nombreux fournisseurs d’hébergement, nous facturons les dépassements de bande passante. Veillez donc à surveiller la quantité de trafic gérée par votre serveur.

      Consultez cette page pour plus d’informations.

      Conditions préalables

      Pour suivre ce tutoriel, vous aurez besoin de :

      Remarque : Bien qu’il soit techniquement possible d’utiliser votre serveur OpenVPN ou votre machine locale comme autorité de certification, cela n’est pas recommandé car cela ouvre votre VPN à certaines vulnérabilités de sécurité. Selon la documentation officielle d’OpenVPN, vous devez placer votre AC sur une machine autonome qui est dédiée à l’importation et à la signature des demandes de certificats. Pour cette raison, ce guide suppose que votre AC se trouve sur un serveur Ubuntu 20.04 séparé qui a également un utilisateur non root avec des privilèges sudo et un pare-feu de base activé.

      En plus de cela, vous aurez besoin d’une machine cliente que vous utiliserez pour vous connecter à votre serveur OpenVPN. Dans ce guide, nous appellerons cela le Client OpenVPN. Pour les besoins de ce tutoriel, il est recommandé d’utiliser votre machine locale comme client OpenVPN.

      Une fois ces conditions préalables réunies, vous êtes prêt à commencer à installer et à configurer un serveur OpenVPN sur Ubuntu 20.04.

      Remarque : Veuillez noter que si vous désactivez l’authentification par mot de passe lors de la configuration de ces serveurs, vous pourriez rencontrer des difficultés lors du transfert de fichiers entre eux plus loin dans ce guide. Pour résoudre ce problème, vous pourrez réactiver l’authentification par mot de passe sur chaque serveur. Sinon, vous pourrez générer une paire de clés SSH pour chaque serveur, puis ajouter la clé SSH publique du serveur OpenVPN au fichier authorized_keys de la machine AC et vice versa. Consultez Comment configurer des clés SSH sur Ubuntu 20.04 pour obtenir des instructions sur la manière d’exécuter l’une ou l’autre de ces solutions.

      Étape 1 – Installation d’OpenVPN et d’Easy-RSA

      La première étape de ce tutoriel consiste à installer OpenVPN et Easy-RSA. Easy-RSA est un outil de gestion de l’infrastructure à clé publique (ICP) que vous utiliserez sur le serveur OpenVPN pour générer une demande de certificat que vous vérifierez et signerez ensuite sur le serveur de l’AC.

      Pour commencer, mettez à jour l’index des paquets de votre serveur OpenVPN et installez OpenVPN et Easy-RSA. Les deux paquets sont disponibles dans les référentiels par défaut d’Ubuntu. Vous pouvez donc utiliser apt pour l’installation :

      • sudo apt update
      • sudo apt install openvpn easy-rsa

      Ensuite, vous devrez créer un nouveau répertoire sur le serveur OpenVPN en tant qu’utilisateur non root appelé ~/easy-rsa :

      Vous devez maintenant créer un lien symbolique à partir du site easyrsa que le paquet a installé dans le répertoire ~/easy-rsa que vous venez de créer : 

      • ln -s /usr/share/easy-rsa/* ~/easy-rsa/

      Remarque : alors que d’autres guides peuvent vous demander de copier les fichiers du package easy-rsa dans votre répertoire ICP, ce tutoriel adopte une approche par lien symbolique. Par conséquent, toute mise à jour du paquet easy-rsa sera automatiquement répercutée dans les scripts de votre ICP.

      Enfin, assurez-vous que le propriétaire du répertoire est votre utilisateur sudo non root et limitez l’accès à cet utilisateur en utilisant chmod: 

      • sudo chown sammy ~/easy-rsa
      • chmod 700 ~/easy-rsa

      Une fois ces programmes installés et déplacés aux bons endroits sur votre système, l’étape suivante consiste à créer une infrastructure à clé publique (ICP) sur le serveur OpenVPN afin que vous puissiez demander et gérer les certificats TLS pour les clients et les autres serveurs qui se connecteront à votre VPN.

      Étape 2 – Création d’une ICP pour OpenVPN

      Avant de pouvoir créer la clé privée et le certificat de votre serveur OpenVPN, vous devez créer un répertoire local de l’infrastructure à clé publique sur votre serveur OpenVPN. Vous utiliserez ce répertoire pour gérer les demandes de certificats du serveur et des clients au lieu de les faire directement sur votre serveur AC.

      Pour créer un répertoire ICP sur votre serveur OpenVPN, vous devez remplir un fichier appelé vars avec quelques valeurs par défaut. Tout d’abord, vous allez cd dans le répertoire easy-rsa, puis vous allez créer et modifier le fichier vars avec nano ou votre éditeur de texte préféré.

      Une fois le fichier ouvert, collez les deux lignes suivantes :

      ~/easy-rsa/vars

      set_var EASYRSA_ALGO "ec"
      set_var EASYRSA_DIGEST "sha512"
      

      Ce sont les deux seules lignes dont vous avez besoin dans ce fichier vars sur votre serveur OpenVPN car il ne sera pas utilisé en tant qu’autorité de certification. Elles garantiront que vos clés privées et vos demandes de certificats sont configurées pour utiliser la cryptographie sur les courbes elliptiques (ECC) afin de générer des clés et des signatures sécurisées pour vos clients et le serveur OpenVPN.

      Configurer vos serveurs OpenVPN & AC pour utiliser l’ECC signifie que lorsqu’un client et un serveur tentent d’établir une clé symétrique partagée, ils peuvent utiliser des algorithmes de courbe elliptique pour effectuer leur échange. L’utilisation de l’ECC pour un échange de clés est nettement plus rapide que l’utilisation de la méthode de Diffie-Hellman avec l’algorithme RSA classique, car les nombres sont beaucoup plus petits et les calculs sont plus rapides.

      Contexte : Lorsque les clients se connectent à OpenVPN, ils utilisent un cryptage asymétrique (également appelé clé publique/privée) pour effectuer une poignée de main du TLS. Cependant, lors de la transmission de trafic VPN crypté, le serveur et les clients utilisent un cryptage symétrique, également connu sous le nom de cryptage à clé partagée.

      Le cryptage symétrique réduit considérablement les coûts de calcul par rapport au cryptage asymétrique : les nombres utilisés sont beaucoup plus petits et les processeurs modernes intègrent des instructions pour effectuer des opérations de cryptage symétriques optimisées. Pour passer d’un cryptage asymétrique à un cryptage symétrique, le serveur et le client OpenVPN utiliseront l’algorithme ECDH (Elliptic Curve Diffie-Hellman) pour se mettre d’accord sur une clé secrète partagée le plus rapidement possible.

      Une fois que vous avez rempli le fichier vars, vous pouvez procéder à la création du répertoire ICP. Pour ce faire, utilisez le script easyrsa avec l’option init-pki. Bien que vous ayez déjà exécuté cette commande sur le serveur de l’AC dans le cadre des prérequis, il est nécessaire de l’exécuter ici car votre serveur OpenVPN et votre serveur de l’AC ont des répertoires PKI séparés :

      Notez que sur votre serveur OpenVPN, il n’est pas nécessaire de créer une autorité de certification. Votre serveur d’AC est seul responsable de la validation et de la signature des certificats. L’ICP de votre serveur VPN n’est utilisée que comme un emplacement pratique et centralisé de stockage des demandes de certificats et des certificats publics.

      Une fois que vous avez initialisé votre ICP sur le serveur OpenVPN, vous êtes prêt à passer à l’étape suivante, qui consiste à créer une demande de certificat de serveur OpenVPN et une clé privée.

      Étape 3 – Création d’une demande de certificat de serveur OpenVPN et d’une clé privée

      Maintenant que votre serveur OpenVPN a installé toutes les conditions préalables, l’étape suivante consiste à générer une clé privée et une demande de signature de certificat (CSR) sur votre serveur OpenVPN. Ensuite, vous transférez la demande à votre AC pour qu’elle la signe, créant ainsi le certificat requis. Une fois que vous avez un certificat signé, vous le transférez à nouveau sur le serveur OpenVPN et l’installez pour que le serveur puisse l’utiliser.

      Pour commencer, naviguez vers le répertoire ~/easy-rsa sur votre serveur OpenVPN en tant qu’utilisateur non root :

      Vous allez maintenant appeler l’easyrsa avec l’option gen-req suivie d’un nom commun (CN) pour la machine. Le CN peut être tout ce que vous voulez, mais il peut être utile d’en faire quelque chose de descriptif. Tout au long de ce tutoriel, le CN du serveur OpenVPN sera server. Veillez à inclure également l’option nopass. Si vous ne le faites pas, le fichier de demande sera protégé par un mot de passe, ce qui pourrait entraîner des problèmes d’autorisation par la suite.

      Remarque : si vous choisissez un nom autre que « server » ici, vous devrez adapter certaines des instructions ci-dessous. Par exemple, en copiant les fichiers générés dans le répertoire /etc/openvpn, vous devrez substituer les noms corrects. Vous devrez également modifier le fichier /etc/openvpn/server.conf ultérieurement pour pointer vers les fichiers .crt et .key corrects.

      • ./easyrsa gen-req server nopass

      Output

      Common Name (eg: your user, host, or server name) [server]: Keypair and certificate request completed. Your files are: req: /home/sammy/easy-rsa/pki/reqs/server.req key: /home/sammy/easy-rsa/pki/private/server.key

      Cela permettra de créer une clé privée pour le serveur et un fichier de demande de certificat appelé server.req. Copiez la clé du serveur dans le répertoire /etc/openvpn/server​​​​​​ :

      • sudo cp /home/sammy/easy-rsa/pki/private/server.key /etc/openvpn/server/

      Après avoir suivi ces étapes, vous avez créé avec succès une clé privée pour votre serveur OpenVPN. Vous avez également généré une demande de signature de certificat pour le serveur OpenVPN. Le CSR est maintenant prêt à être signé par votre AC. Dans la section suivante de ce tutoriel, vous apprendrez comment signer un CSR avec la clé privée de votre serveur CA.

      Étape 4 – Signer la demande de certificat du serveur OpenVPN

      Dans l’étape précédente, vous avez créé une demande de signature de certificat (CSR) et une clé privée pour le serveur OpenVPN. Maintenant, le serveur de l’AC doit connaître le serveur et le valider. Une fois que l’AC a validé et relayé le certificat vers le serveur OpenVPN, les clients qui font confiance à votre AC pourront également faire confiance au serveur OpenVPN. 

      Sur le serveur OpenVPN, en tant qu’utilisateur non root, utilisez SCP ou une autre méthode de transfert pour copier la demande de certificat server.req vers le serveur AC pour la signature :

      • scp /home/sammy/easy-rsa/pki/reqs/server.req sammy@your_ca_server_ip:/tmp

      Si vous avez suivi le tutoriel Comment mettre en place et configurer une autorité de certification (AC) sur Ubuntu 20.04, l’étape suivante consiste à vous connecter au serveur de l’AC en tant qu’utilisateur non root que vous avez créé pour gérer votre AC. Vous allez cd dans le répertoire ~/easy-rsa où vous avez créé votre PK, puis importer la demande de certificat en utilisant le script ~/easy-rsa :

      • cd ~/easy-rsa
      • ./easyrsa import-req /tmp/server.req server

      Output

      . . . The request has been successfully imported with a short name of: server You may now use this name to perform signing operations on this request.

      Ensuite, signez la demande en exécutant le script easyrsa avec l’option sign-req, suivi du type de demande et du Common Name (Nom commun). Le type de demande peut être soit client, soit serveur. Puisque nous travaillons avec la demande de certificat du serveur OpenVPN, assurez-vous d’utiliser le type de demande du serveur :

      • ./easyrsa sign-req server server

      Dans le résultat, il vous sera demandé de vérifier que la requête provient d’une source fiable. Tapez oui puis appuyez sur ENTER (ENTRÉE) pour confirmer : 

      Output

      You are about to sign the following certificate. Please check over the details shown below for accuracy. Note that this request has not been cryptographically verified. Please be sure it came from a trusted source or that you have verified the request checksum with the sender. Request subject, to be signed as a server certificate for 3650 days: subject= commonName = server Type the word 'yes' to continue, or any other input to abort. Confirm request details: yes . . . Certificate created at: /home/sammy/easy-rsa/pki/issued/server.crt

      Veuillez noter que si vous avez crypté votre clé privée de l’AC, vous serez invité à saisir votre mot de passe à ce stade.

      Une fois ces étapes terminées, vous avez signé la demande de certificat du serveur OpenVPN en utilisant la clé privée du serveur de l’AC. Le fichier server.crt qui en résulte contient la clé de cryptage publique du serveur OpenVPN, ainsi qu’une signature du serveur AC. Le but de la signature est de dire à toute personne qui fait confiance au serveur AC qu’elle peut également faire confiance au serveur OpenVPN lorsqu’elle s’y connecte.

      Pour terminer la configuration des certificats, copiez les fichiers server.crt et ca.crt du serveur AC vers le serveur OpenVPN : 

      • scp pki/issued/server.crt sammy@your_vpn_server_ip:/tmp
      • scp pki/ca.crt sammy@your_vpn_server_ip:/tmp

      De retour sur votre serveur OpenVPN, copiez les fichiers de /tmp à /etc/openvpn/server : 

      • sudo cp /tmp/{server.crt,ca.crt} /etc/openvpn/server

      Maintenant, votre serveur OpenVPN est presque prêt à accepter des connexions. Dans l’étape suivante, vous effectuerez quelques étapes supplémentaires pour augmenter la sécurité du serveur.

      Étape 5 – Configuration du matériel cryptographique OpenVPN

      Pour un niveau de sécurité supplémentaire, nous ajouterons une clé secrète partagée supplémentaire, que le serveur et tous les clients utiliseront avec la directive OpenVPN tls-crypt. Cette option est utilisée pour obscurcir le certificat TLS qui est utilisé lorsqu’un serveur et un client se connectent l’un à l’autre au départ. Il est également utilisé par le serveur OpenVPN pour effectuer des contrôles rapides sur les paquets entrants : si un paquet est signé en utilisant la clé pré-partagée, alors le serveur le traite ; s’il n’est pas signé, alors le serveur sait qu’il provient d’une source non fiable et peut le rejeter sans avoir à effectuer un travail de décryptage supplémentaire.

      Cette option vous permettra de vous assurer que votre serveur OpenVPN est capable de gérer le trafic non authentifié, les scans de ports et les attaques par déni de service qui peuvent accaparer les ressources du serveur. Elle rend également plus difficile l’identification du trafic du réseau OpenVPN.

      Pour générer la clé tls-crypt pré-partagée, exécutez les opérations suivantes sur le serveur OpenVPN dans le répertoire ~/easy-rsa : 

      • cd ~/easy-rsa
      • openvpn --genkey --secret ta.key

      Le résultat sera un fichier appelé ta.key. Copiez-le au répertoire /etc/openvpn/server/ : 

      • sudo cp ta.key /etc/openvpn/server

      Une fois ces fichiers en place sur le serveur OpenVPN, vous êtes prêt à créer des certificats clients et des fichiers clés pour vos utilisateurs, que vous utiliserez pour vous connecter au VPN.

      Étape 6 – Génération d’un certificat de client et d’une paire de clés

      Bien que vous puissiez générer une clé privée et une demande de certificat sur votre machine cliente et l’envoyer ensuite à l’AC pour qu’elle la signe, ce guide décrit un processus de génération de la demande de certificat sur le serveur OpenVPN. L’avantage de cette approche est que nous pouvons créer un script qui générera automatiquement des fichiers de configuration du client contenant toutes les clés et tous les certificats requis. Cela vous évite d’avoir à transférer les clés, les certificats et les fichiers de configuration aux clients et rationalise le processus pour rejoindre le VPN.

      Nous générerons une seule paire certificat/clé client dans ce guide. Si vous avez plus d’un client, vous pouvez répéter ce processus pour chacun d’entre eux. Veuillez noter, cependant, que vous devrez transmettre une valeur de nom unique au script pour chaque client. Tout au long de ce tutoriel, la première paire certificat/clé est appelée client1.

      Commencez par créer une structure de répertoire dans votre répertoire d’origine pour stocker les fichiers du certificat et de la clé client :

      • mkdir -p ~/client-configs/keys

      Étant donné que vous stockerez les paires certificats/clés et les fichiers de configuration de vos clients dans ce répertoire, vous devriez verrouiller ses autorisations dès maintenant par mesure de sécurité :

      • chmod -R 700 ~/client-configs

      Ensuite, retournez dans le répertoire EasyRSA et exécutez le script easyrsa avec les options gen-req et nopass, ainsi que le nom commun du client :

      • cd ~/easy-rsa
      • ./easyrsa gen-req client1 nopass

      Appuyez sur ENTER pour confirmer le nom commun. Ensuite, copiez le fichier client1.key dans le répertoire ~/client-configs/keys/ que vous avez créé précédemment : 

      • cp pki/private/client1.key ~/client-configs/keys/

      Puis transférez le fichier client1.req à votre serveur d’autorité de certification en utilisant une méthode sécurisée : 

      • scp pki/reqs/client1.req sammy@your_ca_server_ip:/tmp

      Connectez-vous maintenant à votre serveur AC. Naviguez vers le répertoire EasyRSA, et importez la demande de certificat :

      • cd ~/easy-rsa
      • ./easyrsa import-req /tmp/client1.req client1

      Ensuite, signez la demande de la même manière que vous l’avez fait pour le serveur à l’étape précédente. Cette fois, cependant, veillez à préciser le type de demande client :

      • ./easyrsa sign-req client client1

      Lorsque vous y êtes invité, entrez oui pour confirmer que vous avez l’intention de signer la demande de certificat et qu’elle provient d’une source fiable : 

      Output

      Type the word 'yes' to continue, or any other input to abort. Confirm request details: yes

      Encore une fois, si vous avez chiffré votre clé AC, vous serez invité à entrer votre mot de passe ici.

      Cela créera un fichier de certificat client nommé client1.crt. Transférez ce fichier vers le serveur :

      • scp pki/issued/client1.crt sammy@your_server_ip:/tmp

      De retour sur votre serveur OpenVPN, copiez le certificat du client sur le répertoire ~/client-configs/keys/ : 

      • cp /tmp/client1.crt ~/client-configs/keys/

      Ensuite, copiez le fichier ca.crt et ta.key aux fichiers ~/client-configs/keys/ et définissez les permissions appropriées pour votre utilisateur sudo : 

      • cp ~/easy-rsa/ta.key ~/client-configs/keys/
      • sudo cp /etc/openvpn/server/ca.crt ~/client-configs/keys/
      • sudo chown sammy.sammy ~/client-configs/keys/*

      Avec cela, les certificats et les clés de votre serveur et de votre client ont tous été générés et sont stockés dans les répertoires appropriés sur votre serveur OpenVPN. Il reste encore quelques actions à effectuer avec ces fichiers, mais elles interviendront dans une étape ultérieure. Pour l’instant, vous pouvez passer à la configuration d’OpenVPN.

      Étape 7 – Configurer OpenVPN

      Comme de nombreux autres outils open-source largement utilisés, OpenVPN dispose de nombreuses options de configuration pour personnaliser votre serveur en fonction de vos besoins spécifiques. Dans cette section, nous fournirons des instructions sur la façon de mettre en place une configuration de serveur OpenVPN basée sur un des exemples de fichiers de configuration qui est inclus dans la documentation de ce logiciel.

      Tout d’abord, copiez l’échantillon server.conf comme point de départ pour votre propre fichier de configuration : 

      • sudo cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/server/
      • sudo gunzip /etc/openvpn/server/server.conf.gz

      Ouvrez le nouveau fichier pour l’éditer avec l’éditeur de texte de votre choix. Nous utiliserons nano dans notre exemple :

      • sudo nano /etc/openvpn/server/server.conf

      Nous devrons modifier quelques lignes dans ce fichier. Tout d’abord, trouvez la section HMAC de la configuration en recherchant la directive tls-auth. Cette ligne ne doit pas être commentée. Commenter en ajoutant un « ; » au début de la ligne. Ajoutez ensuite une nouvelle ligne contenant uniquement la valeur tls-crypt ta.key :

      /etc/openvpn/server/server.conf

      ;tls-auth ta.key 0 # This file is secret
      tls-crypt ta.key
      

      Ensuite, trouvez la section sur le chiffrement cryptographique en recherchant les lignes de cipher.  La valeur par défaut est réglée à AES-256-CBC, cependant, le chiffrement AES-256-GCM offre un meilleur niveau de cryptage, de performance, et est bien pris en charge dans les clients à jour OpenVPN. Nous commenterons la valeur par défaut en ajoutant le symbole « ; » au début de cette ligne, puis nous ajouterons une autre ligne après celle-ci contenant la valeur actualisée de AES-256-GCM :

      /etc/openvpn/server/server.conf

      ;cipher AES-256-CBC
      cipher AES-256-GCM
      

      Juste après cette ligne, ajoutez une directive auth pour sélectionner l’algorithme de digestion des messages HMAC. À cette fin, SHA256 est un bon choix :

      /etc/openvpn/server/server.conf

      auth SHA256
      

      Ensuite, trouvez la ligne contenant une directive dh qui définit les paramètres de Diffie-Hellman. Puisque nous avons configuré tous les certificats pour utiliser la cryptographie à courbe elliptique, il n’est pas nécessaire d’avoir un fichier source Diffie-Hellman. Commenter la ligne existante qui ressemble à dh dh2048.pem ou dh dh.pem. Le nom de fichier pour la clé Diffie-Hellman peut être différent de ce qui est indiqué dans le fichier de configuration du serveur d’exemple. Ensuite, ajoutez une ligne à la suite avec le contenu dh none :

      /etc/openvpn/server/server.conf

      ;dh dh2048.pem
      dh none
      

      Ensuite, nous voulons qu’OpenVPN tourne sans privilèges une fois qu’il a démarré, nous devons donc lui dire de tourner avec un utilisateur nobody et un groupe nogroup. Pour cela, trouvez et décommentez les lignes user nobody et group nogroup en supprimant le signe ; au début de chaque ligne :

      /etc/openvpn/server/server.conf

      user nobody
      group nogroup
      

      (Facultatif) Modifiez le DNS pour rediriger tout le trafic par le VPN

      Les paramètres ci-dessus créeront la connexion VPN entre votre client et votre serveur mais ne forceront aucune connexion à utiliser le tunnel. Si vous souhaitez utiliser le VPN pour acheminer tout le trafic de vos clients via le VPN, vous voudrez probablement pousser certains paramètres supplémentaires vers les ordinateurs clients.

      Pour commencer, trouvez et décommentez la ligne contenant pousser « redirect-gateway def1 bypass-dhcp ». Cela indiquera à votre client de rediriger tout son trafic via votre serveur OpenVPN. Sachez que l’activation de cette fonctionnalité peut entraîner des problèmes de connectivité avec d’autres services de réseau, comme les SSH :

      /etc/openvpn/server/server.conf

      push "redirect-gateway def1 bypass-dhcp"
      

      Juste en dessous de cette ligne, vous trouverez la section dhcp-option. Encore une fois, enlevez le symbole « ; » devant les deux lignes pour les décommenter :

      /etc/openvpn/server/server.conf

      push "dhcp-option DNS 208.67.222.222"
      push "dhcp-option DNS 208.67.220.220"
      

      Ces lignes indiqueront à votre client d’utiliser les résolveurs OpenDNS gratuits aux adresses IP indiquées. Si vous préférez d’autres résolveurs DNS, vous pouvez les substituer à la place des IP mis en évidence.

      Cela aidera les clients à reconfigurer leurs paramètres DNS pour utiliser le tunnel VPN comme passerelle par défaut.

      (Facultatif) Ajustez le port et le protocole

      Par défaut, le serveur OpenVPN utilise le port 1194 et le protocole UDP pour accepter les connexions des clients. Si vous devez utiliser un autre port en raison des environnements réseau restrictifs de vos clients, vous pouvez changer l’option port. Si vous n’hébergez pas de contenu web sur votre serveur OpenVPN, le port 443 est un choix populaire car il est généralement autorisé par les règles de pare-feu.

      Pour changer OpenVPN afin d’écouter sur le port 443, ouvrez le server.conf et trouver la ligne qui ressemble à ça : 

      /etc/openvpn/server/server.conf

      port 1194
      

      Modifiez-le de manière à ce que le port soit 443 :

      /etc/openvpn/server/server.conf

      # Optional!
      port 443
      

      Souvent, le protocole est également limité à ce port. Si c’est le cas, trouvez la ligne de proto sous la ligne de port et changez le protocole de udp à tcp :

      /etc/openvpn/server/server.conf

      # Optional!
      proto tcp
      

      Si vous modifiez le protocole en TCP, vous devrez changer la valeur de la directive explicit-exit-notify de 1 à 0, car cette directive n’est utilisée que par UDP. Si vous ne le faites pas en utilisant TCP, des erreurs se produiront lorsque vous lancerez le service OpenVPN.

      Trouvez explicit-exit-notify à la fin du fichier et changez la valeur en 0 : 

      /etc/openvpn/server/server.conf

      # Optional!
      explicit-exit-notify 0
      

      Si vous n’avez pas besoin d’utiliser un port et un protocole différents, il est préférable de laisser ces paramètres inchangés.

      (Facultatif) Pointez vers des informations d’identification autres que celles par défaut

      Si vous avez choisi un nom différent lors de la commande du serveur gen-req ./easyrsa plus tôt, modifiez les lignes cert et key dans la configuration server.conf afin qu’elles renvoient aux fichiers .crt et .key appropriés. Si vous avez utilisé le nom par défaut, server, celui-ci est déjà correctement configuré : 

      /etc/openvpn/server/server.conf

      cert server.crt
      key server.key
      

      Lorsque vous avez terminé, enregistrez et fermez le fichier.

      Vous avez maintenant fini de configurer les paramètres généraux de votre OpenVPN. Dans la prochaine étape, nous personnaliserons les options de mise en réseau du serveur.

      Étape 8 – Ajustement de la configuration réseau du serveur OpenVPN

      Certains aspects de la configuration réseau du serveur doivent être modifiés afin qu’OpenVPN puisse acheminer correctement le trafic à travers le VPN. Le premier d’entre eux est le transfert IP, une méthode permettant de déterminer où le trafic IP doit être acheminé. Ceci est essentiel pour la fonctionnalité VPN que votre serveur fournira.

      Pour ajuster le paramètre de transfert IP par défaut de votre serveur OpenVPN, ouvrez le fichier /etc/sysctl.conf en utilisant nano ou votre éditeur de texte préféré : 

      • sudo nano /etc/sysctl.conf

      Ajoutez ensuite la ligne suivante en bas du fichier :

      /etc/sysctl.conf

      net.ipv4.ip_forward = 1
      

      Enregistrez et fermez le fichier lorsque vous avez terminé.

      Pour lire le fichier et charger les nouvelles valeurs pour la session en cours, tapez :

      Output

      net.ipv4.ip_forward = 1

      Désormais, votre serveur OpenVPN sera en mesure de transférer le trafic entrant d’un appareil ethernet à un autre. Ce paramètre garantit que le serveur peut diriger le trafic des clients qui se connectent sur l’interface VPN virtuelle vers ses autres périphériques ethernet physiques. Cette configuration acheminera tout le trafic web de votre client via l’adresse IP de votre serveur, et l’adresse IP publique de votre client sera effectivement cachée.

      Dans l’étape suivante, vous devrez configurer certaines règles de pare-feu pour vous assurer que le trafic vers et depuis votre serveur OpenVPN circule correctement.

      Étape 9 – Configuration du pare-feu

      Jusqu’à présent, vous avez installé OpenVPN sur votre serveur, l’avez configuré et avez généré les clés et les certificats nécessaires pour que votre client puisse accéder au VPN. Cependant, vous n’avez encore fourni à OpenVPN aucune instruction sur l’endroit où envoyer le trafic web entrant des clients. Vous pouvez stipuler comment le serveur doit traiter le trafic des clients en établissant certaines règles de pare-feu et configurations de routage.

      En supposant que vous ayez suivi les prérequis au début de ce tutoriel, vous devriez déjà avoir installé et exécuté ufw sur votre serveur. Pour autoriser OpenVPN par le pare-feu, vous devrez activer le masquerading, un concept d’iptables qui fournit une traduction dynamique d’adresse réseau en vol (NAT) pour acheminer correctement les connexions client.

      Avant d’ouvrir le fichier de configuration du pare-feu pour ajouter les règles de masquage, vous devez d’abord trouver l’interface de réseau public de votre machine. Pour ce faire, tapez :

      Votre interface publique est la chaîne de caractères qui se trouve dans la sortie de cette commande et qui suit le mot « dev ». Par exemple, ce résultat montre l’interface nommée eth0, qui est mise en évidence ci-dessous :

      Output

      default via 159.65.160.1 dev eth0 proto static

      Lorsque l’interface est associée à votre itinéraire par défaut, ouvrez le fichier /etc/ufw/before.rules pour ajouter la configuration appropriée :

      • sudo nano /etc/ufw/before.rules

      Les règles UFW sont généralement ajoutées à l’aide de la commande ufw. Les règles énumérées dans le fichier before.rules sont toutefois lues et mises en place avant le chargement des règles UFW conventionnelles. En haut du fichier, ajoutez les lignes mises en évidence ci-dessous. Cela permettra de définir la politique par défaut pour la chaîne POSTROUTING dans la table nat et de masquer tout trafic provenant du VPN. N’oubliez pas de remplacer eth0 dans la ligne -A POSTROUTING ci-dessous avec l’interface que vous avez trouvée dans la commande ci-dessus :

      /etc/ufw/before.rules

      #
      # rules.before
      #
      # Rules that should be run before the ufw command line added rules. Custom
      # rules should be added to one of these chains:
      #   ufw-before-input
      #   ufw-before-output
      #   ufw-before-forward
      #
      
      # START OPENVPN RULES
      # NAT table rules
      *nat
      :POSTROUTING ACCEPT [0:0]
      # Allow traffic from OpenVPN client to eth0 (change to the interface you discovered!)
      -A POSTROUTING -s 10.8.0.0/8 -o eth0 -j MASQUERADE
      COMMIT
      # END OPENVPN RULES
      
      # Don't delete these required lines, otherwise there will be errors
      *filter
      . . .
      

      Enregistrez et fermez le fichier lorsque vous avez terminé.

      Ensuite, vous devez indiquer à UFW d’autoriser également les paquets transmis par défaut. Pour ce faire, ouvrez le fichier /etc/default/ufw :

      • sudo nano /etc/default/ufw

      À l’intérieur, trouvez la directive DEFAULT_FORWARD_POLICY et changez la valeur de DROP à ACCEPT :

      /etc/default/ufw

      DEFAULT_FORWARD_POLICY="ACCEPT"
      

      Enregistrez et fermez le fichier lorsque vous avez terminé.

      Ensuite, ajustez le pare-feu lui-même pour permettre le trafic vers OpenVPN. Si vous n’avez pas modifié le port et le protocole dans le fichier /etc/openvpn/server.conf, vous devrez ouvrir le trafic UDP au port 1194. Si vous avez modifié le port et/ou le protocole, utilisez ici les valeurs que vous avez sélectionnées.

      Au cas où vous auriez oublié d’ajouter le port SSH en suivant le tutoriel préalable, ajoutez-le également ici :

      • sudo ufw allow 1194/udp
      • sudo ufw allow OpenSSH

      Après avoir ajouté ces règles, désactivez et réactivez UFW pour le redémarrer et charger les modifications de tous les fichiers :

      • sudo ufw disable
      • sudo ufw enable

      Votre serveur est maintenant configuré pour gérer correctement le trafic OpenVPN. Une fois les règles du pare-feu en place, nous pouvons lancer le service OpenVPN sur le serveur.

      Étape 10 – Démarrer OpenVPN

      OpenVPN fonctionne comme un service systemd, nous pouvons donc utiliser systemctl pour le gérer. Nous configurerons OpenVPN pour qu’il se lance au démarrage afin que vous puissiez vous connecter à votre VPN à tout moment tant que votre serveur tourne. Pour ce faire, activez le service OpenVPN en l’ajoutant à systemctl : 

      Ensuite, lancez le service OpenVPN :

      Vérifiez que le service OpenVPN est actif avec la commande suivante. Vous devriez voir active (en cours) dans le résultat : 

      Output

      [email protected] - OpenVPN service for server Loaded: loaded (/lib/systemd/system/[email protected]; enabled; vendor preset: enabled) Active: active (running) since Wed 2020-04-29 15:39:59 UTC; 6s ago Docs: man:openvpn(8) https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage https://community.openvpn.net/openvpn/wiki/HOWTO Main PID: 16872 (openvpn) Status: "Initialization Sequence Completed" Tasks: 1 (limit: 1137) Memory: 1.0M CGroup: /system.slice/system-openvpnx2dserver.slice/[email protected] └─16872 /usr/sbin/openvpn --status /run/openvpn-server/status-server.log --status-version 2 --suppress-timestamps --c> . . . . . . Apr 29 15:39:59 ubuntu-20 openvpn[16872]: Initialization Sequence Completed

      Nous avons maintenant terminé la configuration côté serveur pour OpenVPN. Ensuite, vous allez configurer votre machine cliente et vous connecter au serveur OpenVPN.

      Étape 11 – Créer l’infrastructure de configuration du client

      La création de fichiers de configuration pour les clients OpenVPN peut être quelque peu compliquée, car chaque client doit avoir sa propre configuration et chacun doit s’aligner sur les paramètres décrits dans le fichier de configuration du serveur. Plutôt que d’écrire un seul fichier de configuration qui ne peut être utilisé que sur un seul client, cette étape décrit un processus de construction d’une infrastructure de configuration client que vous pouvez utiliser pour générer des fichiers de configuration à la volée. Vous créerez d’abord un fichier de configuration « de base », puis un script qui vous permettra de générer des fichiers de configuration client, des certificats et des clés uniques selon les besoins.

      Commencez par créer un nouveau répertoire dans lequel vous stockerez les fichiers de configuration du client dans le répertoire client-configs que vous avez créé précédemment :

      • mkdir -p ~/client-configs/files

      Ensuite, copiez un exemple de fichier de configuration client dans le répertoire client-configs pour l’utiliser comme configuration de base :

      • cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf ~/client-configs/base.conf

      Ouvrez ce nouveau dossier en utilisant nano ou votre éditeur de texte préféré : 

      • nano ~/client-configs/base.conf

      Dans celui-ci, localisez la directive remote. Le client est alors dirigé vers l’adresse de votre serveur OpenVPN – l’adresse IP publique de votre serveur OpenVPN. Si vous avez décidé de modifier le port sur lequel le serveur OpenVPN écoute, vous devrez également changer 1194 pour le port que vous avez sélectionné :

      ~/client-configs/base.conf

      . . .
      # The hostname/IP and port of the server.
      # You can have multiple remote entries
      # to load balance between the servers.
      remote your_server_ip 1194
      . . .
      

      Assurez-vous que le protocole correspond à la valeur que vous utilisez dans la configuration du serveur :

      ~/client-configs/base.conf

      proto udp
      

      Ensuite, décommentez les directives user et group en supprimant le symbole « ; » au début de chaque ligne :

      ~/client-configs/base.conf

      # Downgrade privileges after initialization (non-Windows only)
      user nobody
      group nogroup
      

      Trouvez les directives qui fixent ca, cert et key. Commentez ces directives, car vous ajouterez bientôt les certificats et les clés dans le dossier lui-même :

      ~/client-configs/base.conf

      # SSL/TLS parms.
      # See the server config file for more
      # description. It's best to use
      # a separate .crt/.key file pair
      # for each client. A single ca
      # file can be used for all clients.
      ;ca ca.crt
      ;cert client.crt
      ;key client.key
      

      De même, commentez la directive tls-auth, car vous ajouterezta.key directement dans le fichier de configuration client (et le serveur est configuré pour utiliser tls-crypt):

      ~/client-configs/base.conf

      # If a tls-auth key is used on the server
      # then every client must also have the key.
      ;tls-auth ta.key 1
      

      Refléter les paramètres de chiffrement et auth que vous avez définis dans le fichier /etc/openvpn/server/server.conf :

      ~/client-configs/base.conf

      cipher AES-256-GCM
      auth SHA256
      

      Ensuite, ajoutez la directive key-direction quelque part dans le fichier. Vous devez régler ce paramètre sur « 1 » pour que le VPN fonctionne correctement sur la machine cliente :

      ~/client-configs/base.conf

      key-direction 1
      

      Enfin, ajoutez quelques lignes commentées pour traiter les différentes méthodes que les clients VPN basés sur Linux utiliseront pour la résolution DNS. Vous allez ajouter deux ensembles similaires, mais distincts des lignes commentées. Le premier ensemble est celui des clients qui n’utilisent pas systemd-resolved pour gérer le DNS. Ces clients reposent sur l’utilitaire resolvconf pour mettre à jour les informations DNS pour les clients Linux.

      ~/client-configs/base.conf

      ; script-security 2
      ; up /etc/openvpn/update-resolv-conf
      ; down /etc/openvpn/update-resolv-conf
      

      Ajoutez maintenant un autre ensemble de lignes pour les clients qui utilisent systemd-resolved pour la résolution DNS :

      ~/client-configs/base.conf

      ; script-security 2
      ; up /etc/openvpn/update-systemd-resolved
      ; down /etc/openvpn/update-systemd-resolved
      ; down-pre
      ; dhcp-option DOMAIN-ROUTE .
      

      Enregistrez et fermez le fichier lorsque vous avez terminé.

      Plus tard dans l’Étape 13 – Installation de l’étape de configuration du client de ce tutoriel, vous apprendrez comment déterminer le fonctionnement de la résolution DNS sur les clients Linux et quelle section doit être décommentée.

      Ensuite, nous créerons un script qui compilera votre configuration de base avec les fichiers de certificat, de clé et de cryptage pertinents, puis nous placerons la configuration générée dans le répertoire~/client-configs/files. Ouvrez un nouveau fichier appelé make_config.sh dans le répertoire ~/client-configs :

      • nano ~/client-configs/make_config.sh

      Dans ce fichier, ajoutez le contenu suivant :

      ~/client-configs/make_config.sh

      #!/bin/bash
      
      # First argument: Client identifier
      
      KEY_DIR=~/client-configs/keys
      OUTPUT_DIR=~/client-configs/files
      BASE_CONFIG=~/client-configs/base.conf
      
      cat ${BASE_CONFIG} 
          <(echo -e '<ca>') 
          ${KEY_DIR}/ca.crt 
          <(echo -e '</ca>n<cert>') 
          ${KEY_DIR}/${1}.crt 
          <(echo -e '</cert>n<key>') 
          ${KEY_DIR}/${1}.key 
          <(echo -e '</key>n<tls-crypt>') 
          ${KEY_DIR}/ta.key 
          <(echo -e '</tls-crypt>') 
          > ${OUTPUT_DIR}/${1}.ovpn
      

      Enregistrez et fermez le fichier lorsque vous avez terminé.

      Avant de poursuivre, veillez à marquer ce fichier comme exécutable en tapant :

      • chmod 700 ~/client-configs/make_config.sh

      Ce script fera une copie du fichier base.conf que vous avez créé, rassemblera tous les fichiers de certificats et de clés que vous avez créés pour votre client, extraira leur contenu, les ajoutera à la copie du fichier de configuration de la base et exportera tout ce contenu dans un nouveau fichier de configuration du client. Cela signifie que, plutôt que de devoir gérer séparément les fichiers de configuration, de certificat et de clé du client, toutes les informations requises sont stockées en un seul endroit. L’avantage de cette méthode est que si jamais vous devez ajouter un client à l’avenir, vous pouvez exécuter ce script pour créer rapidement un nouveau fichier de configuration et vous assurer que toutes les informations importantes sont stockées dans un seul endroit facile d’accès.

      Veuillez noter qu’à chaque fois que vous ajouterez un nouveau client, vous devrez générer de nouvelles clés et de nouveaux certificats pour lui avant de pouvoir exécuter ce script et générer son fichier de configuration. Vous vous entraînerez à utiliser ce script dans la prochaine étape.

      Étape 12 – Générer les configurations client

      Si vous avez suivi le guide, vous avez créé un certificat de client et une clé nommés client1.crt et client1.keyrespectivement à l’étape 6. Vous pouvez générer un fichier de configuration pour ces informations d’identification en allant dans votre ~/client-configs et exécuter le script que vous avez fait à la fin de l’étape précédente : 

      • cd ~/client-configs
      • ./make_config.sh client1

      Cela créera un fichier nommé client1.ovpn dans votre répertoire ~/client-configs/files :

      • ls ~/client-configs/files

      Output

      client1.ovpn

      Vous devez transférer ce fichier sur l’appareil que vous prévoyez d’utiliser en tant que client. Il peut s’agir, par exemple, de votre ordinateur local ou d’un appareil mobile.

      Bien que les applications exactes utilisées pour effectuer ce transfert dépendent du système d’exploitation de votre appareil et de vos préférences personnelles, utiliser le SFTP (protocole de transfert de fichiers SSH) ou le SCP (Secure Copy) en back-end constitue une méthode fiable et sûre. Cela permettra de transporter les fichiers d’authentification VPN de votre client sur une connexion chiffrée.

      Voici un exemple de commande SFTP que vous pouvez exécuter depuis votre ordinateur local (macOS ou Linux). Cela permettra de copier le client1.ovpn que nous avons créé dans la dernière étape vers votre répertoire d’origine : 

      • sftp sammy@openvpn_server_ip:client-configs/files/client1.ovpn ~/

      Voici plusieurs outils et tutoriels qui permettent de transférer en toute sécurité des fichiers du serveur OpenVPN vers un ordinateur local :

      Étape 13 – Installer la configuration client

      Cette section explique comment installer un profil VPN client sur Windows, macOS, Linux, iOS et Android. Aucune de ces instructions du client ne dépend d’une autre, alors n’hésitez pas à passer à celle qui s’applique à votre appareil.

      La connexion OpenVPN portera le même nom que celui du fichier .ovpn. Pour ce tutoriel, cela signifie que la connexion est nommée client1.ovpn, s’alignant sur le premier fichier client que vous avez généré.

      Windows

      Installation

      Téléchargez l’application client OpenVPN pour Windows depuis la page de téléchargement d’OpenVPN. Choisissez la version d’installation appropriée pour votre version de Windows.

      Remarque : OpenVPN a besoin de privilèges administratifs pour s’installer.

      Après avoir installé OpenVPN, copiez le fichier .ovpn dans :

      C:Program FilesOpenVPNconfig
      

      Lorsque vous lancez OpenVPN, il localisera automatiquement le profil et le rendra disponible.

      Vous devez exécuter OpenVPN en tant qu’administrateur à chaque fois qu’il est utilisé, même par des comptes administratifs. Pour effectuer cette action sans avoir à cliquer sur le bouton droit de la souris et à sélectionner Exécuter en tant qu’administrateur chaque fois que vous utilisez le VPN, vous devez le pré-régler à partir d’un compte administratif. Cela signifie également que les utilisateurs standard devront entrer le mot de passe de l’administrateur pour utiliser OpenVPN. Les utilisateurs standard ne peuvent pas se connecter correctement au serveur à moins que l’application OpenVPN sur le client n’ait des droits d’administrateur, les privilèges élevés sont donc nécessaires.

      Pour que l’application OpenVPN s’exécute toujours en tant qu’administrateur, cliquez avec le bouton droit de la souris sur son icône de raccourci et allez dans Propriétés. En bas de l’onglet Compatibilité, cliquez sur le bouton Modifier les paramètres pour tous les utilisateurs. Dans la nouvelle fenêtre, cochez Exécuter ce programme en tant qu’administrateur.

      Connexion

      À chaque fois que vous lancez l’interface graphique d’OpenVPN, Windows vous demande si vous souhaitez autoriser le programme à apporter des modifications à votre ordinateur. Cliquez sur Oui. Le lancement de l’application client OpenVPN ne fait que placer l’applet dans la barre d’état système afin que vous puissiez connecter et déconnecter le VPN selon vos besoins : il n’établit pas réellement la connexion VPN.

      Une fois qu’OpenVPN est lancé, initiez une connexion en vous rendant dans l’applet de la barre d’état système et en cliquant avec le bouton droit de la souris sur l’icône de l’applet OpenVPN. Cela ouvre le menu contextuel. Sélectionnez client1 en haut du menu (c’est votre profil client1.ovpn) et choisissez Connecter.

      Une fenêtre d’état s’ouvrira, montrant la sortie du journal pendant que la connexion est établie, et un message s’affichera une fois que le client sera connecté.

      Déconnectez-vous du VPN de la même manière : allez dans l’applet de la barre d’état système, cliquez avec le bouton droit de la souris sur l’icône de l’applet OpenVPN, sélectionnez le profil du client et cliquez sur Déconnecter.

      macOS

      Installation

      Tunnelblick est un client OpenVPN gratuit et open source pour macOS. Vous pouvez télécharger la dernière image disque à partir de la page de téléchargement de Tunnelblick. Double-cliquez sur le fichier .dmg téléchargé et suivez les instructions pour l’installer.

      Vers la fin du processus d’installation, Tunnelblick vous demandera si vous avez des fichiers de configuration. Répondez J’ai des fichiers de configuration et laissez Tunnelblick finir. Ouvrez une fenêtre du Finder et double-cliquez sur client1.ovpn. Tunnelblick installera le profil du client. Des privilèges administratifs sont requis.

      Connexion

      Lancez Tunnelblick en double-cliquant sur l’icône de Tunnelblick dans le dossier Applications. Lorsque Tunnelblick est lancé, une icône Tunnelblick apparaît dans la barre de menu en haut à droite de l’écran pour contrôler les connexions. Cliquez sur l’icône, puis sur l’élément de menu Connecter client1 pour lancer la connexion VPN.

      Linux

      Installation

      Si vous utilisez Linux, vous pouvez utiliser plusieurs outils en fonction de votre distribution. Votre environnement de bureau ou votre gestionnaire de fenêtres peut également inclure des utilitaires de connexion.

      La façon la plus universelle de se connecter, cependant, est d’utiliser simplement le logiciel OpenVPN.

      Sur Ubuntu ou Debian, vous pouvez l’installer comme vous l’avez fait sur le serveur en tapant :

      • sudo apt update
      • sudo apt install openvpn

      Sur CentOS, vous pouvez activer les référentiels EPEL et les installer ensuite en tapant :

      • sudo dnf install epel-release
      • sudo dnf install openvpn

      Configuration des clients qui utilisent systemd-resolved

      Vérifiez d’abord si votre système utilise systemd-resolved pour traiter la résolution DNS en vérifiant le fichier /etc/resolv.conf :

      Output

      # This file is managed by man:systemd-resolved(8). Do not edit. . . . nameserver 127.0.0.53 options edns0

      Si votre système est configuré pour utiliser systemd-resolved pour la résolution DNS, l’adresse IP après l’option nameserver sera 127.0.0.53. Il devrait également y avoir des commentaires dans le fichier, comme le résultat qui est montré, qui expliquent comment systemd-resolved gère le fichier. Si vous avez une adresse IP différente de 127.0.0.53, il y a de fortes chances que votre système n’utilise pas systemd-resolved et vous pouvez passer à la section suivante sur la configuration des clients Linux qui ont un script update-resolv-conf.

      Pour prendre ces clients en chage, installez d’abord le package openvpn-systemd-resolved Il fournit des scripts qui forceront systemd-resolved à utiliser le serveur VPN pour la résolution DNS.

      • sudo apt install openvpn-systemd-resolved

      Une fois le package installé, configurez le client pour l’utiliser et pour envoyer toutes les requêtes DNS sur l’interface VPN. Ouvrez le fichier VPN du client :

      Décommentez maintenant les lignes suivantes que vous avez ajoutées précédemment :

      client1.ovpn

      script-security 2
      up /etc/openvpn/update-systemd-resolved
      down /etc/openvpn/update-systemd-resolved
      down-pre
      dhcp-option DOMAIN-ROUTE .
      

      Configuration des clients qui utilisent update-resolv-conf​​​

      Si votre système n’utilise pas systemd-resolved pour gérer les DNS, vérifiez si votre distribution comprend un script /etc/openvpn/update-resolv-conf :

      Output

      update-resolv-conf

      Si votre client inclut le fichier update-resolv-conf, alors modifiez le fichier de configuration du client OpenVPN que vous avez transféré précédemment :

      Décommentez les trois lignes que vous avez ajoutées pour ajuster les paramètres DNS :

      client1.ovpn

      script-security 2
      up /etc/openvpn/update-resolv-conf
      down /etc/openvpn/update-resolv-conf
      

      Si vous utilisez CentOS, changez la directive group de nogroup à nobody pour qu’elle corresponde aux groupes disponibles de la distribution :

      client1.ovpn

      group nobody
      

      Enregistrez et fermez le fichier.

      Connexion

      Maintenant, vous pouvez vous connecter au VPN en pointant simplement la commande openvpn sur le fichier de configuration client :

      • sudo openvpn --config client1.ovpn

      Cela devrait vous connecter à votre VPN.

      Remarque : si votre client utilise systemd-resolved pour gérer les DNS, vérifiez que les paramètres sont appliqués correctement en exécutant systemd-resolve --statt comme ceci :

      • systemd-resolve --status tun0

      Vous devriez voir une sortie similaire à la suivante :

      Output

      Link 22 (tun0) . . . DNS Servers: 208.67.222.222 208.67.220.220 DNS Domain: ~.

      Si vous voyez les adresses IP des serveurs DNS que vous avez configurés sur le serveur OpenVPN, avec le paramètre ~. pour DNS Domain​​ dans la sortie, alors vous avez correctement configuré votre client pour utiliser le résolveur DNS du serveur VPN. Vous pouvez également vérifier que vous envoyez des requêtes DNS sur le VPN en utilisant un site comme DNS leak test.com.

      iOS

      Installation

      Depuis l’App Store d’iTunes, recherchez et installez OpenVPN Connect, l’application client OpenVPN officielle pour iOS. Pour transférer la configuration de votre client iOS sur l’appareil, connectez-le directement à un ordinateur.

      La procédure à suivre pour effectuer le transfert avec iTunes est décrite ici. Ouvrez iTunes sur l’ordinateur et cliquez sur iPhone > apps. Faites défiler vers le bas jusqu’à la section Partage de fichiers et cliquez sur l’application OpenVPN. La fenêtre vide à droite, Documents OpenVPN, est destinée au partage de fichiers. Faites glisser le fichier .ovpn vers la fenêtre OpenVPN Documents (Documents OpenVPN). iTunes montrant le profil VPN prêt à être chargé sur l'iPhone

      Lancez maintenant l’application OpenVPN sur l’iPhone. Vous recevrez une notification vous informant qu’un nouveau profil est prêt à être importé. Appuyez sur le signe + vert pour l’importer.

      L'appli OpenVPN iOS présentant un nouveau profil prêt à être importéConnexion

      OpenVPN est maintenant prêt à être utilisé avec le nouveau profil. Démarrez la connexion en faisant glisser le bouton Connect sur la position On. Déconnectez-vous en faisant glisser le même bouton sur Off.

      Remarque : Le commutateur VPN sous Paramètres ne peut pas être utilisé pour se connecter au VPN. Si vous essayez, vous recevrez un avis vous invitant à vous connecter uniquement à l’aide de l’application OpenVPN.

      The OpenVPN iOS app connected to the VPN

      Android

      Installation

      Ouvrez le Google Play Store. Recherchez et installez Android OpenVPN Connect, l’application client officielle d’OpenVPN sur Android.

      Vous pouvez transférer le profil .ovpn en connectant l’appareil Android à votre ordinateur par USB et en copiant le fichier dessus. Sinon, si vous disposez d’un lecteur de carte SD, vous pouvez retirer la carte SD de l’appareil, y copier le profil, puis réinsérer la carte dans l’appareil Android.

      Lancez l’application OpenVPN et appuyez sur le menu FILE (FICHIER) pour importer le profil.

      The OpenVPN Android app profile import menu selection

      Ensuite, naviguez jusqu’à l’emplacement du profil enregistré (la capture d’écran utilise /storage/emulated/0/openvpn) et sélectionnez votre fichier .ovpn. Appuyez sur le bouton IMPORT (IMPORTER) pour terminer l’importation de ce profil.

      The OpenVPN Android app selecting VPN profile to import

      le profil Connecting Once (Connexion Une fois) est ajouté, vous verrez un écran comme celui-ci :

      L'application Android d'OpenVPN avec un nouveau profil ajouté 

      Pour vous connecter, appuyez sur le bouton de commutation situé à proximité du profil que vous souhaitez utiliser. Vous verrez les statistiques en temps réel de votre connexion et du trafic acheminé par votre serveur OpenVPN : L'appli OpenVPN Android connectée au VPN 

      Pour vous déconnecter, il suffit d’appuyer une nouvelle fois sur le bouton de commutation en haut à gauche. Vous serez invité à confirmer que vous souhaitez vous déconnecter de votre VPN.

      Étape 14 – Tester votre connexion VPN (facultatif)

      Remarque : Cette méthode pour tester votre connexion VPN ne fonctionnera que si vous avez choisi de faire passer tout votre trafic par le VPN à l’étape 7 lorsque vous avez modifié le fichier server.conf pour OpenVPN.

      Une fois que tout est installé, une simple vérification confirme que tout fonctionne correctement. Sans avoir activé de connexion VPN, ouvrez un navigateur et allez sur DNSLeakTest.

      Le site renvoie l’adresse IP attribuée par votre fournisseur d’accès à Internet et telle que vous apparaissez au reste du monde. Pour vérifier vos paramètres DNS sur le même site web, cliquez sur Extended Test et il vous indiquera quels serveurs DNS vous utilisez.

      Connectez maintenant le client OpenVPN au VPN de votre Droplet et rafraîchissez le navigateur. Une adresse IP complètement différente (celle de votre serveur VPN) devrait maintenant apparaître, et c’est ainsi que vous apparaissez au monde. Encore une fois, le test Extended Test de DNSLeakTest vérifiera vos paramètres DNS et confirmera que vous utilisez maintenant les résolveurs DNS poussés par votre VPN.

      Étape 15 – Révoquer les certificats clients

      Il peut arriver que vous deviez révoquer le certificat d’un client pour empêcher tout accès ultérieur au serveur OpenVPN.

      Pour ce faire, suivez l’exemple du tutoriel sur les conditions préalables Comment mettre en place et configurer une autorité de certification sur Ubuntu 20.04 dans la section Révoquer un certificat.

      Une fois que vous avez révoqué un certificat pour un client en suivant ces instructions, vous devez copier le fichiercrl.pem vers votre serveur OpenVPN dans le répertoire /etc/openvpn/server : 

      • sudo cp /tmp/crl.pem /etc/openvpn/server/

      Ensuite, ouvrez le fichier de configuration du serveur OpenVPN :

      • sudo nano /etc/openvpn/server/server.conf

      Au bas du fichier, ajoutez l’option crl-verify, qui demandera au serveur OpenVPN de vérifier la liste de révocation de certificats que nous avons créée à chaque tentative de connexion :

      /etc/openvpn/server/server.conf

      crl-verify crl.pem
      

      Enregistrez et fermez le fichier.

      Enfin, redémarrez OpenVPN pour implémenter la révocation du certificat :

      Le client ne devrait plus être en mesure de se connecter au serveur en utilisant les anciennes informations d’identification.

      Pour révoquer d’autres clients, procédez comme suit :

      1. Révoquez le certificat avec la commande ./easyrsa revoke client-name
      2. Générez un nouveau fichier CRL
      3. Transférer le nouveau fichier crl.pem vers votre serveur OpenVPN et copiez le fichier /etc/openvpn/server/ pour se substituer à l’ancienne liste.
      4. Redémarrez le service OpenVPN.

      Vous pouvez utiliser cette méthode processus pour révoquer tout certificat que vous avez précédemment émis pour votre serveur.

      Conclusion

      Vous devriez maintenant disposer d’un réseau privé virtuel pleinement opérationnel fonctionnant sur votre serveur OpenVPN. Vous pouvez naviguer sur le web et télécharger du contenu sans craindre que des utilisateurs malveillants ne suivent votre activité.

      Vous pouvez prendre plusieurs mesures pour personnaliser davantage votre installation OpenVPN, par exemple en configurant votre client pour qu’il se connecte automatiquement au VPN ou en configurant des règles et des politiques d’accès spécifiques au client. Pour ces personnalisations et d’autres personnalisations d’OpenVPN, vous devez consulter la documentation officielle d’OpenVPN. 

      Pour configurer plus de clients, il suffit de suivre les étapes 6 et 11-13 pour chaque dispositif supplémentaire. Pour révoquer l’accès aux clients, suivez l’étape 15.



      Source link

      Comment mettre en place et configurer une autorité de certification (AC) sur Ubuntu 20.04


      Introduction

      Une autorité de certification (AC) est une entité chargée d’émettre des certificats numériques pour vérifier les identités sur l’internet. Bien que les AC publiques soient un choix populaire pour vérifier l’identité des sites web et autres services qui sont fournis au grand public, les AC privées sont généralement utilisées pour les groupes fermés et les services privés.

      La création d’une autorité de certification privée vous permettra de configurer, de tester et d’exécuter des programmes qui nécessitent des connexions cryptées entre un client et un serveur. Avec une AC privée, vous pouvez émettre des certificats pour les utilisateurs, les serveurs ou les programmes et services individuels au sein de votre infrastructure.

      Quelques exemples de programmes sur Linux qui utilisent leur propre AC privée sont OpenVPN et Puppet. Vous pouvez également configurer votre serveur web pour utiliser des certificats émis par une AC privée afin de faire correspondre les environnements de développement et de simulation aux serveurs de production qui utilisent TLS pour crypter les connexions.

      Dans ce guide, nous allons apprendre comment mettre en place une autorité de certification privée sur un serveur Ubuntu 20.04 et comment générer et signer un certificat de test en utilisant votre nouvelle AC. Vous apprendrez également comment importer le certificat public du serveur de l’AC dans le magasin de certificats de votre système d’exploitation afin de pouvoir vérifier la chaîne de confiance entre l’AC et les serveurs ou utilisateurs distants. Enfin, vous apprendrez comment révoquer des certificats et distribuer une liste de révocation de certificats pour vous assurer que seuls les utilisateurs et les systèmes autorisés peuvent utiliser les services qui reposent sur votre AC.

      Conditions préalables

      Pour suivre ce tutoriel, vous devrez avoir accès à un serveur Ubuntu 20.04 pour héberger votre serveur AC. Vous devrez configurer un utilisateur non root avec privilèges sudo avant de commencer ce guide. Vous pouvez suivre notre guide de configuration initiale de serveur Ubuntu 20.04 pour configurer un utilisateur avec les permissions appropriées. Le tutoriel joint permettra également de mettre en place un pare-feu, supposé rester en place tout au long de ce guide.

      Ce serveur sera appelé Serveur AC dans ce tutoriel.

      Assurez-vous que le serveur AC est un système autonome. Il ne sera utilisé que pour importer, signer et révoquer les demandes de certificats. Il ne doit pas gérer d’autres services et, dans l’idéal, il sera hors ligne ou complètement fermé lorsque vous ne travaillerez pas activement avec votre AC.

      Remarque : la dernière section de ce tutoriel est facultative si vous souhaitez en savoir plus sur la signature et la révocation des certificats. Si vous choisissez de suivre ces étapes de pratique, vous aurez besoin d’un second serveur Ubuntu 20.04 ou vous pouvez également utiliser votre propre ordinateur Linux local fonctionnant sous Ubuntu ou Debian, ou des distributions dérivées de l’un ou l’autre.

      Étape 1 — Installation d’Easy-RSA

      La première tâche de ce tutoriel consiste à installer l’ensemble de scripts easy-rsa sur votre serveur d’AC. easy-rsa est un outil de gestion d’autorité de certification que vous utiliserez pour générer une clé privée et un certificat racine public, que vous utiliserez ensuite pour signer les demandes des clients et des serveurs qui s’appuieront sur votre AC.

      Connectez-vous à votre serveur AC en tant qu’utilisateur sudo non root que vous avez créé lors des étapes de configuration initiales et exécutez ce qui suit :

      • sudo apt update
      • sudo apt install easy-rsa

      Vous serez invité à télécharger le package et à l’installer. Appuyez sur y pour confirmer que vous souhaitez installer le package.

      À ce stade, vous disposez de tout ce dont vous avez besoin, installé et prêt pour utiliser Easy-RSA. Dans l’étape suivante, vous allez créer une infrastructure à clés publiques, puis vous commencerez à construire votre autorité de certification.

      Étape 2 — Préparation d’un répertoire d’infrastructures à clés publiques

      Maintenant que vous avez installé easy-rsa​​​, il est temps de créer un squelette de l’infrastructure de clés publiques (ICP) sur le serveur AC. Assurez-vous que vous êtes encore connecté en tant qu’utilisateur non root et créez un répertoire easy-rsa Assurez-vous que vous n’utilisez pas sudo pour exécuter l’une des commandes suivantes, puisque votre utilisateur normal doit gérer et interagir avec l’AC sans privilèges élevés.

      Cela créera un nouveau répertoire appelé easy-rsa dans votre dossier de base. Nous utiliserons ce répertoire pour créer des liens symboliques pointant vers les fichiers de packages easy-rsa que nous avons installés à l’étape précédente. Ces fichiers sont situés dans le dossier /usr/share/easy-rsa sur le serveur AC.

      Créez les liens symboliques (symlinks) avec la commande ln :

      • ln -s /usr/share/easy-rsa/* ~/easy-rsa/

      Remarque : alors que d’autres guides peuvent vous demander de copier les fichiers du package easy-rsa dans votre répertoire ICP, ce tutoriel adopte une approche par lien symbolique. Par conséquent, toute mise à jour du paquet easy-rsa sera automatiquement répercutée dans les scripts de votre ICP.

      Pour restreindre l’accès à votre nouveau répertoire ICP, assurez-vous que seul le propriétaire peut y accéder en utilisant la commande chmod :

      • chmod 700 /home/sammy/easy-rsa

      Enfin, initialisez l’ICP dans le répertoire easy-rsa :

      • cd ~/easy-rsa
      • ./easyrsa init-pki

      Output

      init-pki complete; you may now create a CA or requests. Your newly created PKI dir is: /home/sammy/easy-rsa/pki

      Après avoir terminé cette section, vous disposez d’un répertoire qui contient tous les fichiers nécessaires pour créer une autorité de certification. Dans la section suivante, vous allez créer la clé privée et le certificat public pour votre AC.

      Étape 3 — Création d’une autorité de certification

      Avant de pouvoir créer la clé et le certificat privés de votre AC, vous devez créer et alimenter un fichier appelé vars avec quelques valeurs par défaut. Tout d’abord, vous allez cd dans le répertoire easy-rsa, puis vous allez créer et modifier le fichier vars avec nano ou votre éditeur de texte préféré :

      Une fois le fichier ouvert, collez les lignes suivantes et modifiez chaque valeur mise en évidence pour refléter les informations de votre propre organisation. L’important ici est de veiller à ne laisser aucune des valeurs en blanc :

      ~/easy-rsa/vars

      set_var EASYRSA_REQ_COUNTRY "US" set_var EASYRSA_REQ_PROVINCE "NewYork" set_var EASYRSA_REQ_CITY "New York City" set_var EASYRSA_REQ_ORG "DigitalOcean" set_var EASYRSA_REQ_EMAIL "[email protected]" set_var EASYRSA_REQ_OU "Community" set_var EASYRSA_ALGO "ec" set_var EASYRSA_DIGEST "sha512"

      Lorsque vous avez terminé, enregistrez et fermez le fichier. Si vous utilisez nano, vous pouvez le faire en appuyant sur CTRL+X, puis Y et ENTER pour confirmer. Vous êtes maintenant prêt à construire votre AC.

      Pour créer la paire de clés root public et privé pour votre autorité de certification, exécutez à nouveau la commande ./easy-rsa, cette fois-ci avec l’option build-ca :

      Dans la sortie, vous verrez quelques lignes sur la version OpenSSL et vous serez invité à entrer une phrase de passe pour votre paire de clés. Assurez-vous de choisir une phrase de passe solide, et notez-le dans un endroit sûr. Vous devrez saisir la phrase de passe chaque fois vous devrez interagir avec votre AC, par exemple pour signer ou révoquer un certificat.

      Il vous sera également demandé de confirmer le Nom commun (CN) de votre AC. Le nom commun est le nom utilisé pour désigner cette machine dans le contexte de l’autorité de certification. Vous pouvez saisir n’importe quelle chaîne de caractères pour le nom commun de l’AC mais, par souci de simplicité, appuyez sur ENTER (ENTRÉE) pour accepter le nom par défaut.

      Output

      . . . Enter New CA Key Passphrase: Re-Enter New CA Key Passphrase: . . . Common Name (eg: your user, host, or server name) [Easy-RSA CA]: CA creation complete and you may now import and sign cert requests. Your new CA certificate file for publishing is at: /home/sammy/easy-rsa/pki/ca.crt

      Remarque : Si vous ne voulez pas qu’un mot de passe vous soit demandé à chaque fois que vous interagissez avec votre AC, vous pouvez exécuter la commande build-ca avec l’option nopass, comme ceci :

      • ./easyrsa build-ca nopass

      Vous disposez maintenant de deux fichiers importants – ~/easy-rsa/pki/ca.crt et ~/easy-rsa/pki/private/ca.key – qui constituent les composants publics et privés d’une autorité de certification.

      • ca.crt est le fichier de certificats public de l’AC. Les utilisateurs, les serveurs et les clients utiliseront ce certificat pour vérifier qu’ils font partie du même réseau de confiance. Chaque utilisateur et serveur qui utilise votre AC devront avoir une copie de ce fichier. Toutes les parties s’appuieront sur le certificat public pour s’assurer qu’une personne ne se fait pas passer pour un système et n’effectue pas une attaque de type Man-in-the-middle.

      • ca.key est la clé privée que l’AC utilise pour signer les clés et les certificats des serveurs et des clients. Si un intrus accède à votre AC et, à son tour, à votre fichier ca.key, vous devrez détruire votre AC. C’est pourquoi votre fichier ca.key ne doit se trouver que sur votre machine AC et votre machine AC doit idéalement être maintenue hors ligne lorsqu’elle ne signe pas de demandes de certificat, par mesure de sécurité supplémentaire.

      Avec cela, votre AC est en place et elle est prête à être utilisée pour signer des demandes de certificats et pour révoquer des certificats.

      Étape 4 — Distribuer le certificat public de votre autorité de certification

      Votre AC est maintenant configurée et prête à agir comme une racine de confiance pour tous les systèmes que vous voulez configurer en vue de son utilisation. Vous pouvez ajouter le certificat de l’AC à vos serveurs OpenVPN, serveurs web, serveurs de messagerie, etc. Tout utilisateur ou serveur qui doit vérifier l’identité d’un autre utilisateur ou serveur de votre réseau devrait avoir une copie du fichier ca.crt importé dans le magasin de certificats de son système d’exploitation.

      Pour importer le certificat public de l’AC dans un deuxième système Linux comme un autre serveur ou un ordinateur local, obtenez d’abord une copie du fichier ca.crt de votre serveur AC. Vous pouvez utiliser la commande cat pour le sortir dans un terminal, puis le copier et le coller dans un fichier sur le deuxième ordinateur qui importe le certificat. Vous pouvez également utiliser des outils comme scp, rsync pour transférer le fichier entre les systèmes. Cependant, nous utiliserons un copier-coller avec nano dans cette étape car cela fonctionne sur tous les systèmes.

      En tant qu’utilisateur non root sur le serveur AC, exécutez la commande suivante :

      • cat ~/easy-rsa/pki/ca.crt

      Il y aura une sortie dans votre terminal qui ressemblera à ce qui suit :

      Output

      -----BEGIN CERTIFICATE----- MIIDSzCCAjOgAwIBAgIUcR9Crsv3FBEujrPZnZnU4nSb5TMwDQYJKoZIhvcNAQEL BQAwFjEUMBIGA1UEAwwLRWFzeS1SU0EgQ0EwHhcNMjAwMzE4MDMxNjI2WhcNMzAw . . . . . . -----END CERTIFICATE-----

      Copiez tout, y compris les lignes -----BEGIN CERTIFICATE-----​​​ et –-----END CERTIFICATE----- et les tirets.

      Sur votre deuxième système Linux, utilisez nano ou votre éditeur de texte préféré pour ouvrir un fichier appelé /tmp/ca.crt :

      Collez le contenu que vous venez de copier du serveur AC dans l’éditeur. Lorsque vous avez terminé, enregistrez et fermez le fichier. Si vous utilisez nano, vous pouvez le faire en appuyant sur CTRL+X, puis Y et ENTER pour confirmer.

      Maintenant que vous disposez d’une copie du fichier ca.crt sur votre deuxième système Linux,il est temps d’importer le certificat dans le magasin de certificats de son système d’exploitation.

      Sur les systèmes basés sur Ubuntu et Debian, exécutez les commandes suivantes en tant qu’utilisateur non root pour importer le certificat :

      Ubuntu and Debian derived distributions

      • sudo cp /tmp/ca.crt /usr/local/share/ca-certificates/
      • sudo update-ca-certificates

      Pour importer le certificat du serveur AC sur un système basé sur CentOS, Fedora ou RedHat, copiez et collez le contenu du fichier sur le système tout comme dans l’exemple précédent dans un fichier appelé /tmp/ca.crt. Ensuite, vous copierez le certificat dans /etc/pki/ca-trust/source/anchors/, puis vous exécuterez la commande update-ca-trust.

      CentOS, Fedora, RedHat distributions

      • sudo cp /tmp/ca.crt /etc/pki/ca-trust/source/anchors/
      • sudo update-ca-trust

      Votre deuxième système Linux fera maintenant confiance à tout certificat qui a été signé par le serveur AC.

      Remarque : si vous utilisez votre AC avec des serveurs web et si vous utilisez le navigateur Firefox, vous devrez importer directement le certificat ca.crt public dans Firefox. Firefox n’utilise pas le magasin de certificats du système d’exploitation local. Pour plus de détails sur la façon d’ajouter le certificat de votre AC à Firefox, veuillez consulter cet article de Mozilla sur la configuration des autorités de certification (AC) dans Firefox.

      Si vous utilisez votre AC pour intégrer un environnement Windows ou des ordinateurs de bureau, veuillez consulter la documentation sur la façon d’utiliser certutil.exe pour installer un certificat d’AC.

      Si vous utilisez ce tutoriel comme condition préalable à un autre tutoriel, ou si vous savez comment signer et révoquer des certificats, vous pouvez vous arrêter ici. Si vous souhaitez en savoir plus sur la façon de signer et de révoquer des certificats, la section facultative suivante vous expliquera chaque processus en détail.

      (Facultatif) — Création de demandes de signature de certificats et révocation des certificats

      Les sections suivantes du tutoriel sont facultatives. Si vous avez effectué toutes les étapes précédentes, vous disposez d’une autorité de certification entièrement configurée et opérationnelle que vous pouvez utiliser comme condition préalable pour d’autres tutoriels. Vous pouvez importer le fichier ca.crt de votre AC et vérifier dans votre réseau les certificats qui ont été signés par votre AC.

      Si vous souhaitez vous entraîner et en savoir plus sur la manière de signer des demandes de certificat et sur la manière de révoquer des certificats, ces sections facultatives vous expliqueront comment fonctionnent les deux processus.

      (Facultatif) — Création et signature d’une demande de certificat de pratique

      Maintenant que vous avez une AC prête à l’emploi, vous pouvez vous entraîner à générer une clé privée et une demande de certificat pour vous familiariser avec le processus de signature et de distribution.

      Une demande de signature de certificat (CSR) se compose de trois parties : une clé publique, des informations d’identification sur le système requérant, et une signature de la requête elle-même, qui est créée en utilisant la clé privée de la partie requérante. La clé privée sera gardée secrète et sera utilisée pour chiffrer les informations que toute personne possédant le certificat public signé pourra ensuite déchiffrer.

      Les étapes suivantes seront exécutées sur votre second système Ubuntu ou Debian ou une distribution dérivée de l’un de ces systèmes. Il peut s’agir d’un autre serveur distant, ou d’une machine Linux locale comme un ordinateur portable ou un ordinateur de bureau. Comme easy-rsa n’est pas disponible par défaut sur tous les systèmes, nous utiliserons l’outil openssl pour créer une clé privée et un certificat de pratique.

      openssl est généralement installé par défaut sur la plupart des distributions Linux, mais juste pour en être certain, exécutez ce qui suit sur votre système

      • sudo apt update
      • sudo apt install openssl

      Lorsque vous êtes invité à installer openssl, entrez y pour poursuivre les étapes d’installation.  Maintenant, vous êtes prêt à créer une pratique CSR avec openssl.

      La première étape que vous devez suivre pour créer une CSR est la génération d’une clé privée. Pour créer une clé privée en utilisant openssl, créez un répertoire “practice-csr” et générez ensuite une clé à l’intérieur de celui-ci. Nous allons faire cette requête pour un serveur fictif appelé sammy-server, par opposition à la création d’un certificat qui est utilisé pour identifier un utilisateur ou une autre AC.

      • mkdir ~/practice-csr
      • cd ~/practice-csr
      • openssl genrsa -out sammy-server.key

      Output

      Generating RSA private key, 2048 bit long modulus (2 primes) . . . . . . e is 65537 (0x010001)

      Maintenant que vous avez une clé privée, vous pouvez créer une CSR correspondante, à nouveau en utilisant l’utilitaire openssl. Vous serez invité à remplir un certain nombre de champs comme Pays, État et Ville. Vous pouvez saisir un . si vous souhaitez laisser un champ vide, mais sachez que s’il s’agit d’une véritable CSR, il est préférable d’utiliser les valeurs correctes de votre localisation et votre organisation :

      • openssl req -new -key sammy-server.key -out sammy-server.req

      Output

      . . . ----- Country Name (2 letter code) [XX]:US State or Province Name (full name) []:New York Locality Name (eg, city) [Default City]:New York City Organization Name (eg, company) [Default Company Ltd]:DigitalOcean Organizational Unit Name (eg, section) []:Community Common Name (eg, your name or your server's hostname) []:sammy-server Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:

      Si vous souhaitez ajouter automatiquement ces valeurs dans le cadre de l’invocation openssl plutôt que via l’invite interactive, vous pouvez passer l’argument -subj à OpenSSL. Veillez à modifier les valeurs mises en évidence pour qu’elles correspondent à votre lieu d’exercice, à votre organisation et au nom de votre serveur :

      • openssl req -new -key sammy-server.key -out server.req -subj
      • /C=US/ST=New York/L=New York City/O=DigitalOcean/OU=Community/CN=sammy-server

      Pour vérifier le contenu d’une CSR, vous pouvez lire dans un fichier de requête avec openssl et examiner les champs à l’intérieur

      • openssl req -in sammy-server.req -noout -subject

      Output

      subject=C = US, ST = New York, L = New York City, O = DigitalOcean, OU = Community, CN = sammy-server

      Une fois que vous êtes satisfait de l’objet de votre demande de certificat de pratique, copiez le fichier sammy-server.req sur votre serveur AC en utilisant scp

      • scp sammy-server.req sammy@your_ca_server_ip:/tmp/sammy-server.req

      Au cours de cette étape, vous avez généré une demande de signature de certificat pour un serveur fictif appelé sammy-server. Dans un scénario réel, la demande peut provenir d’un serveur web de développement ou de simulation qui a besoin d’un certificat TLS pour des tests, ou d’un serveur OpenVPN qui demande un certificat pour que les utilisateurs puissent se connecter à un VPN. Au cours de l’étape suivante, nous allons passer à la signature de la demande de signature de certificat en utilisant la clé privée du serveur AC.

      (Facultatif) – Signature d’une CSR

      Dans l’étape précédente, vous avez créé une demande de certificat de pratique et une clé pour un serveur fictif. Vous l’avez copiée dans le répertoire /tmp de votre serveur AC, en émulant le processus que vous utiliseriez si vous aviez de vrais clients ou serveurs vous envoyant des demandes de CSR à signer.

      Poursuivant le scénario fictif, le serveur AC doit maintenant importer le certificat de pratique et le signer. Une fois qu’une demande de certificat est validée par l’AC et relayée à un serveur, les clients qui font confiance à l’autorité de certification pourront également faire confiance au certificat nouvellement émis.

      Comme nous opérerons au sein de l’ICP de l’AC où l’utilitaire easy-rsa est disponible, les étapes de signature utiliseront l’utilitaire easy-rsa pour faciliter les choses, au lieu d’utiliser directement openssl comme nous l’avons fait dans l’exemple précédent.

      La première étape pour signer la CSR fictive est d’importer la demande de certificat en utilisant le script easy-rsa

      • cd ~/easy-rsa
      • ./easyrsa import-req /tmp/sammy-server.req sammy-server

      Output

      . . . The request has been successfully imported with a short name of: sammy-server You may now use this name to perform signing operations on this request.

      Maintenant, vous pouvez signer la demande en exécutant le script easyrsa avec l’option sign-req suivi du type de requête et du nom commun qui est inclus dans la CSR. Le type de requête peut soit être client, server, ou ca. Comme nous nous entraînons avec un certificat pour un serveur fictif, assurez-vous d’utiliser le type de requête du serveur :

      • ./easyrsa sign-req server sammy-server

      Dans la sortie, il vous sera demandé de vérifier que la requête provient d’une source fiable. Tapez yes puis appuyez sur ENTER pour confirmer :

      Output

      You are about to sign the following certificate. Please check over the details shown below for accuracy. Note that this request has not been cryptographically verified. Please be sure it came from a trusted source or that you have verified the request checksum with the sender. Request subject, to be signed as a server certificate for 3650 days: subject= commonName = sammy-server Type the word 'yes' to continue, or any other input to abort. Confirm request details: yes . . . Certificate created at: /home/sammy/easy-rsa/pki/issued/sammy-server.crt

      Si vous avez crypté votre clé AC, on vous demandera votre mot de passe à ce stade.

      Une fois ces étapes terminées, vous avez signé la CSR sammy-server.req en utilisant la clé privée du serveur AC dans /home/sammy/easy-rsa/pki/private/ca.key. Le fichier sammy-server.crt qui en résulte contient la clé de chiffrement publique du serveur de pratique, ainsi qu’une nouvelle signature du serveur AC. Le but de la signature est de dire à toute personne qui fait confiance à l’AC qu’elle peut également faire confiance au certificat du sammy-server.

      Si cette requête concerne un vrai serveur comme un serveur web ou un serveur VPN, la dernière étape sur le serveur AC serait de distribuer les nouveaux fichiers sammy-server.crt et ca.crt du serveur AC au serveur distant qui a fait la requête CSR :

      • scp pki/issued/sammy-server.crt sammy@your_server_ip:/tmp
      • scp pki/ca.crt sammy@your_server_ip:/tmp

      À ce stade, vous pourrez utiliser le certificat délivré avec un serveur web, un VPN, un outil de gestion de la configuration, un système de base de données ou à des fins d’authentification des clients.

      (Facultatif) — Révocation d’un certificat

      Il peut arriver que vous deviez révoquer un certificat pour empêcher un utilisateur ou un serveur de l’utiliser. Il se peut que l’ordinateur portable de quelqu’un ait été volé, qu’un serveur web ait été compromis, ou qu’un employé ou un contractant ait quitté votre organisation.

      Pour révoquer un certificat, la procédure générale suit les étapes suivantes :

      1. Révoquez le certificat avec la commande ./easyrsa revoke client_name
      2. Générez une nouvelle LRC avec la commande ./easyrsa gen-crl
      3. Transférez le fichier crl.pem mis à jour vers le ou les serveurs qui dépendent de votre AC, et sur ces systèmes, copiez le fichier dans le ou les répertoires requis pour les programmes qui s’y réfèrent.
      4. Redémarrez tous les services qui utilisent votre AC et le fichier LRC.

      Vous pouvez utiliser ce processus pour révoquer à tout moment les certificats que vous avez précédemment émis. Nous allons passer en détail chaque étape dans les sections suivantes, en commençant par la commande revoke

      Révoquer un certificat

      Pour révoquer un certificat, naviguez vers le répertoire easy-rsa sur votre serveur AC :

      Ensuite, lancez le script easyrsa avec l’option revoke, suivi du nom du client que vous souhaitez révoquer : En suivant l’exemple de pratique ci-dessus, le nom commun du certificat est sammy-server :

      • ./easyrsa revoke sammy-server

      Il vous sera demandé de confirmer la révocation en entrant yes :

      Output

      Please confirm you wish to revoke the certificate with the following subject: subject= commonName = sammy-server Type the word 'yes' to continue, or any other input to abort. Continue with revocation: yes . . . Revoking Certificate 8348B3F146A765581946040D5C4D590A . . .

      Notez la valeur mise en évidence sur la ligne Revoking Certificate Cette valeur est le numéro de série unique du certificat qui est en cours de révocation. Si vous voulez examiner la liste de révocation à la dernière étape de cette section pour vérifier que le certificat y figure, vous aurez besoin de cette valeur.

      Après avoir confirmé l’action, l’AC va révoquer le certificat. Cependant, les systèmes distants qui dépendent de l’AC n’ont aucun moyen de vérifier si des certificats ont été révoqués. Les utilisateurs et les serveurs pourront toujours utiliser le certificat jusqu’à ce que la liste des certificats révoqués (LCR) de l’AC soit distribuée à tous les systèmes qui dépendent de l’AC.

      Dans l’étape suivante, vous allez générer une LCR ou mettre à jour un fichier crl.pem existant.

      Générer une liste de révocation de certificats

      Maintenant que vous avez révoqué un certificat, il est important de mettre à jour la liste des certificats révoqués sur votre serveur AC. Une fois que vous aurez mis à jour la liste des révocations, vous serez en mesure de savoir quels utilisateurs et quels systèmes ont des certificats valides dans votre AC.

      Pour générer une LRC, exécutez la commande easy-rsa avec l’option gen-crl tout en restant dans le répertoire ~/easy-rsa :

      Si vous avez utilisé une phrase de passe lors de la création de votre fichier ca.key, vous serez invité à l’entrer. La commande gen-crl générera un fichier appelé crl.pem, contenant la liste actualisée des certificats révoqués pour cette AC.

      Ensuite, vous devrez transférer le fichier crl.pem mis à jour à tous les serveurs et clients qui dépendent de cette AC chaque fois que vous exécuterez la commande gen-crl. Sinon, les clients et les systèmes pourront toujours accéder aux services et aux systèmes qui utilisent votre AC, puisque ces services doivent connaître le statut de révocation du certificat.

      Transférer une liste de révocation de certificats

      Maintenant que vous avez généré une LCR sur le serveur de votre AC, vous devez la transférer vers les systèmes distants qui dépendent de votre AC. Pour transférer ce fichier à vos serveurs, vous pouvez utiliser la commande scp.

      Remarque : ce tutoriel explique comment générer et distribuer manuellement une LCR. Bien qu’il existe des méthodes plus solides et automatisées pour distribuer et vérifier les listes de révocation, comme l’agrafage OCSP, la configuration de ces méthodes dépasse le cadre de cet article.

      Assurez-vous que vous êtes connecté à votre serveur AC en tant qu’utilisateur non racine et exécutez les opérations suivantes, en substituant l’IP ou le nom DNS de votre propre serveur à la place de your_server_ip :

      • scp ~/easy-rsa/pki/crl.pem sammy@your_server_ip:/tmp

      Maintenant que le fichier est sur le système distant, la dernière étape consiste à mettre à jour tous les services avec la nouvelle copie de la liste de révocation.

      Mise à jour des services qui prennent en charge une LCR

      L’énumération des étapes à suivre pour mettre à jour les services qui utilisent le fichier crl.pem dépasse la portée de ce tutoriel. En général, vous devrez copier le fichier crl.pem à l’emplacement prévu par le service, puis le redémarrer à l’aide de systemctl.

      Une fois que vous aurez mis à jour vos services avec le nouveau fichier crl.pem, vos services pourront rejeter les connexions des clients ou des serveurs qui utilisent un certificat révoqué.

      Examen et vérification du contenu d’une LCR

      Si vous souhaitez examiner un fichier CRL, par exemple pour confirmer une liste de certificats révoqués, utilisez la commande openssl suivante à partir de votre répertoire easy-rsa sur votre serveur AC :

      • cd ~/easy-rsa
      • openssl crl -in pki/crl.pem -noout -text

      Vous pouvez également exécuter cette commande sur tout serveur ou système qui dispose de l’outil openssl installé avec une copie du fichier crl.pem. Par exemple, si vous avez transféré le fichier crl.pem sur votre second système et que vous souhaitez vérifier que le certificat de sammy-server est révoqué, vous pouvez utiliser une commande openssl comme celle qui suit, en introduisant le numéro de série que vous avez noté précédemment lorsque vous avez révoqué le certificat à la place de numéro mis en évidence ici :

      • openssl crl -in /tmp/crl.pem -noout -text |grep -A 1 8348B3F146A765581946040D5C4D590A

      Output

      Serial Number: 8348B3F146A765581946040D5C4D590A Revocation Date: Apr 1 20:48:02 2020 GMT

      Remarquez comment la commande grep est utilisée pour vérifier le numéro de série unique que vous avez noté dans l’étape de révocation. Vous pouvez maintenant vérifier le contenu de votre liste de révocation de certificat sur tout système qui s’appuie sur elle pour restreindre l’accès aux utilisateurs et aux services.

      Conclusion

      Dans ce tutoriel, vous avez créé une autorité de certification privée en utilisant le package Easy-RSA sur un serveur Ubuntu 20.04 autonome. Vous avez appris comment fonctionne le modèle de confiance entre les parties qui s’appuient sur l’autorité de certification. Vous avez également créé et signé une demande de signature de certificat (CSR) pour un serveur de pratique, puis appris à révoquer un certificat. Enfin, vous avez appris comment générer et distribuer une liste de révocation de certificats (LRC) pour tout système qui dépend de votre AC afin de s’assurer que les utilisateurs ou les serveurs qui ne devraient pas accéder aux services en soient empêchés.

      Vous pouvez maintenant délivrer des certificats pour les utilisateurs et les utiliser avec des services comme OpenVPN. Vous pouvez également utiliser votre AC pour configurer des serveurs web de développement et de simulation avec des certificats, afin de sécuriser vos environnements hors production. L’utilisation d’une AC avec des certificats TLS pendant le développement peut contribuer à garantir que votre code et vos environnements correspondent autant que possible à votre environnement de production.

      Si vous souhaitez en savoir plus sur l’utilisation d’OpenSSL, consultez notre page sur les principes essentiels d’OpenSSL : Travailler avec les certificats SSL, les clés privées et les CSR contient de nombreuses informations supplémentaires pour vous aider à vous familiariser avec les principes fondamentaux d’OpenSSL.



      Source link