question sur certificat dans PfSense
-
bonjour a tous
j'aurai besoin de quelques infos sur la partie "Certificats" de PfSense :
est il possible de générer un certificat afin de faire un serveur web (local) en HTTPS?
par exemple, mon reseau est sur un domaine local maison.chezmoi
les organismes officiels ne peuvent pas délivrer de certificat pour ce type de nom de domaine.
PfSens en est il capable?
si oui, existe t il une doc sur cette fonctionnalité ?Merci de vos lumières
-
Bonjour,
La gestion de certificats de pfSense est assez complète :
- création d'une AC (CA),
- création de certificats pour serveurs et utilisateurs,
- révocation de certificats et génération de CRL (qu'il reste à diffuser).
L'export de certificats permet de créer des fichiers de différents types.
Qu'avez vous essayer, et avec quels résultats ?
-
@jdh
pour le moment, je n'ai rien essayé.
Je pense ne pas maitriser assez lz sujet pour me lancer comme ça dans des essais
c'est pour ceci que je commence par des questions, pour en savoir plus.mon but serai de pouvoir acceder, localement, en HTTPS a mon serveur web (mais pas avec un certificat auto signé afin de ne pas obtenir la page de mise en garde du navigateur disant que le site est potentiellement dangereux)
-
@zeverybest
C'est possible comme expliqué plus haut. Toutefois vous devrez intégrer votre AC dans les magasins de certificats locaux pour que celle-ci puisse ensuite valider le certificat de votre serveur. C'est que l'on appelle une autorité de certification interne. -
Merci d'avoir complété mon post.
Quand on gère un ensemble de ressources que l'on veut valider via des certificats, la méthode est la suivante ;
- on créé une Autorité de Certification (AC = CA en anglais)
- on créé ensuite des certificats qui vont être signés par l'AC : certificats pour serveurs ou pour clients
Quand le serveur est un serveur web on va fournir le certificat serveur au serveur web.
Le navigateur client doit donc nécessairement disposer de l'AC : typiquement le certificat public de l'AC doit être ajouté aux AC interne : cela va permettre de vérifier que le certificat (serveur) présenté par le serveur web a bien été signé par l'AC. CQFD.
NB : un certificat, y compris l'AC comporte une partie privée et une partie publique. La clé privée de l'AC doit absolument être protégée et non diffusé, au contraire de la partie publique.
-
interessant
il faut clairement que je travaille sur ce sujet pour mieux le comprendre
je vais essayer de trouver de la doc (pour un debutant comme moi dans ce domaine)
d'ailleurs, si vous connaissez des site ou je peux lire des choses interssante, ...encore merci de votre aide
-
Je vous recommande de commencer par regarder quelques bases de cryptographie. Algorithme à clé secrète, à clé publique (fonctionnement de RSA), algorithmes de calcul d'empreinte (MD5, SHA256, ....) A défaut vous ne pourrez pas comprendre comment fonctionnent les mécanismes de vérification d'un certificat.
-
@ccnet
je vais faire ceci
merci
je n'hésiterais pas a revenir quand j'en saurai un peu plus -
Dans le n° de ce mois de Linux Pratique, un article sur les 'certificats SSL/TLS' : l'article est technique et comporte les instructions de mise en oeuvre, donc les principes sont décrits.
-
@jdh
Quelques heures d'attente cette semaine dans des salle d'embarquement d'aeroport, donc j'ai eu le temps de lire cet article
TRES interessant.
Bon, je ne suis pas sur d'avoir (deja) tout compris, mais je suis perceverant.
Pour résumer, il faut que je crée sur mon routeur :
une CA racine
une CA intermédiaire
et que je genere un certificat a installer sur mon serveur Webc'est bien ça (dans les grandes lignes
tout ceci me permetra de signer (en interne uniquement) mes certificat.j'ai bon?
-
Cet article est destiné à
- comprendre ce qu'est une PKI,
- comprendre le rôle des certificats (dans la sécurisation d'une liaison via SSL/TLS),
- mettre en oeuvre les certificats nécessaires, avec les instructions 'openssl' idoines.
En alternative, on peut s'intéresser à 'Easy-Rsa' ensemble de (shell) scripts permettant de créer simplement une PKI qui peut être utilisé pour les accès VPN via OpenVPN. Cela fait partie de l'installation d'OpenVPN. Avec 'Easy-Rsa' les instructions openssl sont à l'intérieur des scripts.
2 liens sur Easy-Rsa (howto non officiels) :
- https://mycelium-fai.org/wiki/travaux/technique/creation_certificat
- https://www.howtoforge.com/tutorial/how-to-install-openvpn-server-and-client-with-easy-rsa-3-on-centos-8/
NB : le paramétrage initial est fondamental ! j'ai fait moi-même des erreurs ici !
L'article et 'Easy-Rsa' permettent de comprendre la démarche.
Avec pfSense, il y a une interface web encore plus simple, mais la démarche doit être comprise avant !
-
@jdh
merci de toutes ces infos
c'est effectivement mon but.
faire pour faire en suivant un tuto sans comprendre n'a aucun intérêt pour moi
c'est d'ailleurs pour ceci que je souhaite le déployer sur mon reseau : pour maitriser ce sujetje vais lire ces 2 articles et ne manquerai pas de revenir ici apres
-
Et ensuite, c'est probablement mieux de gérer cette mini PKI ailleurs que sur pfSense.
Sans prétendre que OpenSSL fait ça très bien, une solution comme XCA remplacera avantageusement pfSense pour cet usage.De mon point de vue, la CA de pfSense, c'est juste acceptable lorsque le besoin se limite aux services qui tournent sur pfSense.
En plus, XCA te permettra de jouer d'une manière conviviale avec plusieurs root CA et de modifier les valeurs avancées des certificats comme les SAN, les fonctions étendues etc...
-
@chris4916
merci de cette info, je vais me pencher sur XCA
mais, pour m'aider a comprendre : une CA (racine ou intermédiaire) a t elle besoin de fonctionner en permanence pour être contacter lors de la vérification, ou doit elle fonctionner uniquement lors de la création du certificat?
savoir si je l'installe sur une machine au hasard et l'utilise lorsque j'ai besoin d'un certificat, ou si je doit lui monter un VM sur mon reseau? (dans ce cas là, PfSense devient intéressant, car c'est déjà une machine qui tourne H24)
merci de vos infos -
Une très bonne page sur les certificats est https://fr.wikipedia.org/wiki/X.509
Créer une PKI, c'est
- créer une AC,
- créer des certificats pour serveur (ou service) (signés pas la AC),
- créer des certificats pour utilisateur (toujours signés par la AC),
- renouveler un certificat (serveur ou utilisateur, et probablement l'AC),
- révoquer un certificat.
On voit donc qu'il doit y avoir
- une 'base' de tous les certificats,
- des opérations (ponctuelles) de création/renouvellement/révocation,
- un service OCSP, interrogeable, qui peut informer sur la validité réelle d'un certificat.
(La seule tâche qui doit tourner est le service OCSP, le reste sont des opérations manuelles de l'admin.)
La gestion de certificats incluse dans pfsense
- a le mérite d'être (très) simple, fonctionnelle et intuitive (web),
- ne comporte pas un service OCSP,
- a le défaut d'être sur le firewall (ce qui n'est pas secure).
L'absence de service OCSP peut être compensée par une rigueur de procédure : à chaque révocation, bien générer la CRL (Certificat Revokation List) et bien l'installer dans chaque service utilisant les certificats. (Je le faisais pour 4 sites utilisant du VPN depuis un firewall pfSense.)
Le programme XCA (qui tourne sous Windows) permet aussi de créer une PKI. On peut même importer la PKI de pfSense dans XCA (certificat par certificat, après export), et je l'ai fait. Mais
- il faudra bien sécuriser la 'base' (=les répertoires),
- elle est notablement moins simple et moins intuitive (exemple : créer un user puis un certificat),
- elle a plus de possibilités dans la personnalisation des certificats
- il n'y a pas de service OCSP.
J'ai été confronté à la situation :
- je gérais 4 sites avec 4 pfSense,
- j'avais utilisé le premier pour créer des certificats pour l'accès OpenVPN (les users peuvent accéder aux 4 sites),
- on a choisi de déployer un autre firewall,
- la question était comment passer d'un firewall à l'autre avec la moindre interruption.
J'ai donc procédé de la façon suivante :
- j'ai importé les certificats dans XCA,
- j'ai ajouté OpenVPN sur un serveur Linux (par site), et configuré avec les certificats,
- (plus une règle iptable sur chaque serveur),
- j'ai désactivé OpenVPN sur pfSense et ajouté un NAT port forward vers le serveur Linux avec OpenVPN.
La seule interruption a été la dernière action, et je ne suis pas passé sur chaque micro avec un accès VPN !!
Toutefois, la solution est moins parfaite : peu de possibilité de filtrer l'accès VPN (limiter l'accès à certains serveurs, ...), les logs sont à rechercher, ...
-
@jdh
Tres intéressant tout ceci
ça m'aide énormément a comprendre le processus (c'est le but de ma démarche)
je vais me pencher sur XCA, mais probablement que, afin de ne pas rajouter une machine supplémentaire, et comme le but est de faire du lab, je vais rester sur la solution de PfSense.
Mais en tout cas, ça m'aide a progresser
je lit encore avant de me lance dans du testEn tout cas, merci a tous pour vos lumières
-
mais, pour résumer et voir si j'ai bien compris, les étapes sont, dans l'ordre, les suivantes :
création d'une CA root sur PfSense
création d'une CA intermédiaire sur PfSense
génération d'un certificat "root" pour la CA intermédiaire
génération d'un certificat par la CA racine pour le serveur Webc'est bien ça?
-
J'ai écrit ce qu'il y avait à dire sur la gestion de certificats intégrée à pfSense :
- elle est simple (voire très simple),
- elle est fonctionnelle,
- elle est intégrée (dans l'interface pfSense et pour les services proposés),
- elle ne contient pas de service OCSP.
A l'utilisation,
- on créé une AC,
- on créé des certificats serveur (pour l'interface web, pour le service OpenVPN, ...),
- on créé des certificats utilisateur (pour le service OpenVPN)
-
un certificat, c'est la partie publique d'une paire de clé (paire constituée d'une partie privé et une publique) qui est signé par une autorité de confiance.
Sans entrer dans le détail des différents usages d'un certificat (signature, encryption etc...) , dans le mode le plus répandu ici, on va parler d'un certificat serveur, lequel serveur est accédé par un client qui est supposé valider qu'il fait confiance à ce certificat (tout le concept est basé ici sur la confiance)
Et pour que cette confiance soit établie, il faut que le client trust l'autorité de certification qui a signé le certificat serveur.Une fois que tu as compris ça:
- tu comprends pourquoi tu peux te contenter techniquement (je ne dis pas que c'est la bonne solution) d'avoir un certificat self-signed (celui qui génère la clé privée et le CSR signe lui même son propre certificate (i.e. je suis ma propre autorité de certification)
- tu comprends que dans certains cas, il est utile d'avoir des "subCA" qui vont permettre de différencier les certificats signés car il est possible, lors de la signature, d'imposer des contraintes, et notamment des contraintes d'usage des-dits certificats (par exemple un certificat peut être utilisé pour identifier un serveur mais pas signer du code ou chiffrer un document.
- pour faire du test/lab, une chaine de certification à plus de un niveau n'est en aucun cas nécessaire
-
donc, je n'ai pas besoin de créer une CA root et une CA intermédiaire?
une CA root suffit? (dans mon cas de Lab pour apprendre)c'est bien ça.