question sur certificat dans PfSense
-
@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.
-
@zeverybest said in question sur certificat dans PfSense:
dans mon cas de Lab pour apprendre
pour apprendre quoi ?
Si c'est pour apprendre le fonctionnement d'une PKI, pfSense n'est pas le bon cheval, trop limité.
Si c'est pour avoir un certificat afin de faire des tests sur un serveur, non il n'est pas nécessaire d'avoir une CA intermédiaire. -
@chris4916
merci de cette info
si je passe par XCA, je ne suis pas obligé de l'avoir en fonction en permanence sur une machine?
Un fois mes certificats générés, il n'est pas nécessaire de le garder en cours d'exécution.
C'est bien ça?
mais le certificat de la CA racine devra être accessible sur une machine?
j'ai encore bon? -
le certificat de la root CA ne sert qu'à signer d'autres certificats. si tu n'as pas besoin de signer, tu n'a pas besoin de la clé privée.
Avec une PKI normalement constituée, ces clés privées ne sont même pas "sur une machine" mais dans un conteur de type HSM mais c'est un autre sujet, loin de tes préoccupations -
@chris4916
justement, je voudrais comprendre le principe de création et signature de certificat.pour le moment, j'ai commencé avec PfSense (je sais que ce n'est pas top, mais je l'ai sous la main et puis c'est mieux d'etre a l'aise avec plusieurs solutions, c'est comme ceci que l'on progresse)
j'ai créé une CA root
ensuite, si j'ai bien compris, je crée un cetrificat, puis je le signe avec le certificat de ma CA root. C'est bien ça?donc, sous PfSense, la procedure est elle la suivante :
- création d'un certificat interne
- création d'une demande de signature
- signature de cette demande
mais c'est là que ça se complique (pour moi)
a chacune de ces étapes, j'ai une nouvelle ligne dans la liste des certificat, et je ne comprend pas bien quoi faire avec tout çalorsque je crée une demande de signature, je me retrouve avec une ligne : "signature en attente"
et lorsque je signe cette demande, la ligne "signature en attente" existe toujours et j'ai une nouvelle ligneje suis un peu perdu dans les étapes.
Je suis désolé de tous vous ennuyer avec ceci, mais j'ai besoin de comprendre
-
Keep cool : vous donnez l'impression d'être angoissé : faites vous confiance en lisant les bonnes docs et en 'maturant' ce que vous lisez !
La doc sur la gestion de certificat intégrée : https://docs.netgate.com/pfsense/en/latest/certificates/index.html (en anglais)
La doc sur X509 : https://fr.wikipedia.org/wiki/X.509 (en français)
J'ai déjà écrit ce qui peut être fait : une AC, 2 certificats serveur (pour l'interface web, pour le serveur OpenVPN), 1 certificat utilisateur (pour un client OpenVPN).
-
je n'utilise pas l'interface de gestion des certificats de pfSense et donc j'ai un peu du mal à voir ce que sont les "lignes en attente" que tu évoques.
dans le process, tu commences par créer un premier certificat qui va être ton certificat "racine", et donc autorité de certification pour la suite de ton arbre (car au final, l'organisation des certificats va ressembler à un arbre, et là on parle de la racine ^^)
Ce root CA est self-signed.
A partir de là, si touts les certificats suivant peuvent être organisés en rateau, donc tous au même niveau, à plat, tu n'as pas besoin de CA intermédiaire.donc tu peux commencer à signer des CSR pur tes différents serveurs directement avec le root CA.
Un CSR, c'est quoi ? c'est une clé privée + une clé publique. Cette paire de clé est normalement générée sur le serveur qui va utiliser (présenter) ce certificat.
lorsque tu fais signer ton CSR, c'est la clé publique (uniquement) que tu envoies à la PKI pour signature. La clé privée, dans le meilleur des cas, ne quitte pas le serveur.Mais, et ce doit être le cas avec pfSense, assez souvent tu peux générer au travers de l'interface graphique de ta PKI directement la paire de clé, privé+publique: la CSR est générée à la volée au sein de la PKI, tu récupères un fichier qui contient les deux clés que tu installes ensuite sur le serveur.
Petit point d'attention, il faut que le serveur fasse confiance à la root CA. donc il est nécessaire, le plus souvent, d'ajouter dans ton keystore ou autre conteneur la clé publique ayant signé le certificat que ton serveur expose.
-
@jdh
je ne suis pas angoissé, mais, meme si je m'investi ennormement sur d'autres forum (4x4) pour aider, j'ai toujours l'impression de déranger et de faire perdre du temps.
de plus, je souhaite vraiment comprendre le principe, donc, je vous remercie du temps que vous m'accordé (je trouve que l'on progresse plus en cherchant qu'en trouvant une solution toute faite), mais je ne voudrais pas passer pour un boulet.je vais aller lire ces docs
j'ai chercher pas mal de tuto sur le net également.Je pense avoir (a peu pret) compris le principe du certificat et des validation par les autorités, mais je coince un peu avec le step by step de PfSense
-
@chris4916 said in question sur certificat dans PfSense:
donc tu peux commencer à signer des CSR pur tes différents serveurs directement avec le root CA.
Un CSR, c'est quoi ? c'est une clé privée + une clé publique. Cette paire de clé est normalement générée sur le serveur qui va utiliser (présenter) ce certificat.
lorsque tu fais signer ton CSR, c'est la clé publique (uniquement) que tu envoies à la PKI pour signature. La clé privée, dans le meilleur des cas, ne quitte pas le serveur.le certificat non signé doit etre generé par le serveur Web? Pas par PfSense?
Et PfSense doit le signer c'est ça?
si dc'est bien ça, je n'avais pas compris comme ça et je pensais avoir compris que PfSens generait les certificat, les signait et ensuite on les exportait sur le serveur web
un peu perdu sur le coup
-
@zeverybest
J'ai joué avec le GUI de pfSense et je comprends maintenant ton problème, du moins je le crois.
Je suppose que tu t'attends, lorsque ta CSR est signée, que cette CSR se transforme en certificat.
Il n'est est rien.
La demande de signature reste une demande. Si tu ne la supprimes pas, une fois la demande signée, tu vas avoir d'un coté la demande, qui reste en état et de l'autre un certificat.
ce n'est pas un problème -
@zeverybest said in question sur certificat dans PfSense:
le certificat non signé doit etre generé par le serveur Web? Pas par PfSense?
Et PfSense doit le signer c'est ça?
si dc'est bien ça, je n'avais pas compris comme ça et je pensais avoir compris que PfSens generait les certificat, les signait et ensuite on les exportait sur le serveur web
un peu perdu sur le couptout ça fonctionne. Soit tu fais ta CSR sur le serveur et tu l'importe dans pfSense, soit tu la fais sur pfsense et tu exportes le certificat signé en t'assurant qu'il contient bien la clé privée, vers ton serveur
-
Ce fil est bien long : franchement BEAUCOUP a été écrit, tant sur les outils que sur les concepts. Il reste la lecture de bons liens : les tutos ne sont utiles que si on connait les principes, et un tuto 'ça s'adapte'. Il reste à 'maturer' : moi, je lis plusieurs fois, puis série de chapitre après série, ... Il reste à se lancer.
Je préconise la gestion intégrée : c'est (très) simple (pas de CSR, .....).
Quand vous serez en responsabilité, ...