Certificate Authority avec EasyRSA et implémentation sous pfSense

Certificate Authority avec EasyRSA et implémentation sous pfSense

Création d’une CA avec Easy-RSA et ajout de certificats sur pfSense pour tunnels OpenVPN.

Pour ce énième article nous allons voir comment mettre en place une autorité de certification (CA) et comment ensuite rajouter des certificats sur un routeur/pare-feu pfSense, dans le but des les utiliser pour une liaison VPN OpenVPN.

Tout d’abord, voici notre schéma :

Nous aurons donc deux machines virtuelles pfSense (fw-paris-01, et fw-bxl-01) ainsi qu’une VM sous Debian 10 pour le CA-Server, mais aussi une Debian 10 pour le serveur LAMP, et enfin une VM Ubuntu 21.04 qui fera simplement office de client de test.

Le client de Paris sera donc un client OpenVPN de type Client-to-Site à destination du LAN de Bruxelles. Si ce dernier arrive à joindre le serveur web, c’est que la liaison est fonctionnelle et les règles de pare-feu adéquates.

Ensuite, et c’est là le plus important, qu’est-ce qu’une autorité de certification ? Quel intérêt ? Qu’est-ce qu’Easy-RSA ?

Nous allons détailler tout cela !

I) L’autorité de certification

Une autorité de certification, ou Certificate Authority est donc comme son nom l’indique est une entité permettant de dispenser des certificats et d’ensuite prouver leur authenticité. La plupart du temps il s’agit de certificats X509, même si d’autres types de certificats sont disponibles.

Un bon exemple est celui des sites web: chacun est libre de commander en ligne un certificat auprès d’une CA, pour ensuite l’appliquer à son site web et bénéficier de l’HTTPS avec un certificat conforme.

Ici, nous allons voir comment mettre en place une CA locale, et nous l’utiliserons donc pour générer des certificats pour notre liaison VPN Client-to-Site. Mais on peut aussi utiliser nos propres certificats pour des liaisons VPNs Client-à-Site, ou encore pour les appliquer à certains serveurs web locaux… la liste est longue.

Sur le schéma en début d’article, on peut voir que la CA est placée en DMZ avec la mention « not connected« , et cela pour une bonne raison: une autorité de certification étant un point très sensible de l’infrastructure informatique, il est toujours recommandé de générer son certificat racine offline, sans aucune liaison LAN/WAN. De cette manière, on isole entièrement la machine et l’on peut (presque) être sûr qu’elle ne sera jamais comprise.

Pour rebondir maintenant sur pfSense, il faut savoir que bien souvent on créer sa CA sur le pfSense lui-même, ce qui fonctionne parfaitement mais peut poser quelques soucis, le premier étant que si ce dernier est compromis ou défaillant, il faut tout simplement re-créer une CA de zéro, et/ou révoquer plusieurs dizaines voir centaines de certificats…

A noter qu’il est aussi possible (voir même recommandé) de créer une ou plusieurs CA Intermédiaires, pour plus de sécurité, mais cela dépasse le cadre de cet article qui reste une introduction 😅

II) Installation d’Easy-RSA et création des certificats

Passons donc à l’installation de l’utilitaire Easy-RSA. Par défaut sous Debian, ce dernier est présent dans les repos de base :

A l’heure où j’écris l’article, la version 3.0.8 est disponible sur le repo Github officiel de l’utilitaire, c’est donc à vous de voir la méthode d’installation souhtaitée, étant donné le peu de retard par rapport aux dépôts de chez Debian. Pour mon cas je vais tout de même me rendre sur Github pour télécharger et extraire l’utilitaire :

wget https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.8/EasyRSA-3.0.8.tgz
tar xvf EasyRSA-3.0.8.tgz && rm EasyRSA-3.0.8.tgz
cd EasyRSA-3.0.8

Une fois fait, nous allons (enfin !) pouvoir comment à créer notre CA !

*A noter que comme dit précédemment, n’oubliez pas la bonne pratique de couper l’accès LAN/WAN à votre machine, ici nous avons téléchargé l’utilitaire donc plus besoin de connectivité.

La première commande va nous permettre d’initialiser notre PKI, pour Public Key Infrastructure, ou Infrastructure à clés publiques en français. Ce terme englobe notre CA root, les éventuels CA Intermediate, les certificats générés…

On se place donc dans notre dossier EasyRSA si ce n’est pas déjà fait, et on peut exécuter la commande suivante :

./easyrsa init-pki

On créer ensuite notre CA, où nous devrons renseigner sa passphrase ainsi que renseigner le Common Name du certificat, ici nous laisserons simplement le nom d’hôte de notre machine :

./easyrsa build-ca

Et c’est tout ! Notre certificat est désormais créé dans le dossier pki !

III) Ajout de la CA sur pfSense

Nous nous rendons sur le fw-bxl-01 et nous naviguons jusqu’à la section System, puis Cert. Manager et enfin cliquer sur Add :

Ici nous renseignons donc un nom pour notre CA, nous choisissons la méthode Import an existing CA, et puis l’on colle notre ca.crt généré précédemment dans le dossier PKI.

Concernant la clé privée, celle-ci se trouve toujours dans le dossier PKI mais à l’intérieur du sous-dossier private, et se nomme ca.key. Enfin, concernant le Serial for next certificate, libre à vous de rentrer n’importe quel nombre, il ne servira qu’à être incrémenté pour le sprochains certificats créés via cette CA.

Dépendant de la version de pfSense utilisée, vous pourriez obtenir cette erreur :

Dans ce cas là, il faut déchiffrer la clé pour pouvoir la passer à pfSense, rassurez-vous, en une ligne de commande le tour est joué !

openssl rsa -in private/ca.key -out private/ca-decrypted.key

Et l’on peut la coller à nouveau, et valider le tout :

Voici ce que vous devriez obtenir si vous avez suivi pas à pas mes explications 😛

Désormais, grâce à notre CA, nous allons pouvoir générer les certificats pour notre liaison VPN voir même pour d’autres services ou appareils. A noter que, comme déjà dit un peu au-dessus, la meilleure pratique consiste à créer une CA Intermediate et à importer celle-ci sur le pfSense, mais je ferai sûrement un article dédié à cela. Ici, l’idée est vraiment de cerner les principes de base.

IV) Création de la liaison OpenVPN Client-to-Site

J’ai déjà réalisé plusieurs articles traitant de VPN via OpenVPN, donc je ne vais pas tout ré-expliquer en détails ici, veillez simplement à vérifier la marche à suivre.

En premier lieu, sur le pfSense de Bruxelles on se rend sur VPN puis OpenVPN et enfin Servers puis Add :

Ici rien de très compliqué, on poursuit !

Ici j’ai déjà réalisé ma configuration OpenVPN, c’est pourquoi j’ai déjà une clé TLS d’affichée, mais il vous suffit donc de choisir la CA nouvellement importée (ca-server-bxl.man) et de choisir un certificat serveur créé pour l’occasion (fw-bxl-01-lan-openvpn). Pour ce faire, rendez-vous dans la partie Cert. Manager et créez un certificat de type serveur pour le pare-feux.

Le reste est assez classique, on choisi un réseau pour le tunnel VPN, et on renseigne le réseau LAN de Bruxelles.

Une fois fait, il nous faut créer un utilisateur et créer un certificat pour ce dernier :

*Petite note, il se peut que même en cochant la case Click to create a user certificate ce dernier ne se créé pas, dans ce cas il faut créer un certificat de type utilisateur de la même manière que l’on a créé un certificat serveur pour notre pare-feux, dans la partie Users et en cliquant sur Add en dessous de User Certificates :

Une fois le certificat créé, vous devriez obtenir ceci :

Courage, nous touchons au but !

Passez maintenant à la partie Package Manager et installez le paquet openvpn-client-export pour pouvoir exporter le client OpenVPN pour notre utilisateur nouvellement créé :

On télécharge donc la version Inline Configurations et on l’installe sur notre client Ubuntu, de manière classique. Une fois fait, on renseigne l’utilisateur et le mot de passe :

Pour la partie User key password, cochez la case The password is not required, et le tour est joué ! Nous pouvons à présent avoir accès à notre serveur LAMP !

V) Conclusion

Cet article touche désormais à sa fin ! J’espère comme à mon habitude vous avoir appris quelques bricoles, astuces, ou plus encore, et vous donne rendez-vous pour le prochain qui risque de vous plaire ! Nous y parlerons à nouveau de EasyRSA mais de manière plus poussée (avec CA Intermediate), VLANs dynamiques, et Mac Addresss !

Bien-entendu comme dit plusieurs fois dans cet article, ce lab n’est pas à répliquer en production, il faut pour bien faire créer une CA Intermédiaire et je n’ai pas abordé la partie CRL, mais nous verrons tout ça plus tard. L’important est que notre liaison VPN Client-to-Site via certificat TLS délivré par notre propre CA est fonctionnel ! Un sacré bon point en soit haha.

Sur ce, je vous souhaite une bonne journée/soirée !

2 comments

comments user
Gabriel

Pour info, quand TLS v1.2 est utilisé, le certificat passe en clair sur le réseau. Comme il contient ici le nom de l’utilisateur (dans cet exemple en tout cas), ce n’est pas forcément idéal.

Ce soucis est résolu avec TLS v1.3 (cette version du protocole envoie le certificat client dans le tunnel et après avoir authentifié le serveur). Cependant, si le client accepte TLS v1.2, un attaquant peut tenter un downgrade vers TLS v1.2 pour le forcer à révéler son certificat.

    comments user
    Mairien Anthony

    Merci à toi Gabriel, je t’avoue que je ne savais pas !

Laisser un commentaire