Certificat SSL Lets Encrypt valide, signé - WebGUI Pfsense non sécurisé ?!!
-
Malgré tes efforts évidents pour documenter le problème, je ne vois pas où tu montres que l'accès à pfSense est "non sécurisé" :( d'auant que tu montres qu'un certificat est bien installé.
De plus, il me semble, si il y a effectivement un problème de certificat, que tu devrais vérifier à minima que celui-ci a bien, dans les "extended key usage", le rôle de "serveur"En marge de ces points, je ne comprends pas ça:
Pourquoi ? Afin que le nom de domaine de la pfsense soit un sous-domaine du nom de domaine créé chez hébergeur. Supposition : éviter les problèmes (ou pas) lors de la signature du certificat par le registrar
Ce n'est pas le registrar qui signe le certificat mais Let'sEncrypt. Bien sûr il faut que le domaine auquel appartient pfSense soit publique, mais c'est la seule contrainte. Si ton seul domaine publique est SchoolDom, pourquoi pas, mais il ne faut pas te tromper sur la raison de la convergence vers ce domaine unique.
Enfin, rien à voir avec le sujet de ce fil, mais je ne comprends pas non plus le positionnement du proxy transparent avec une flèche depuis internet vers le LAN. Tu veux dire "reverse proxy" ou alors c'est bien un proxy (pas reverse) mais en mode transparent, auquel cas ta flèche est à l'envers :-)
-
On ne sait pas pourquoi le navigateur indique que la connexion n'est pas sécurisée. Il y a de nombreux motifs potentiels.
-
Merci tout d'abord pour votre aide,
je ne vois pas où tu montres que l'accès à pfSense est "non sécurisé" :( d'auant que tu montres qu'un certificat est bien installé.
De plus, il me semble, si il y a effectivement un problème de certificat, que tu devrais vérifier à minima que celui-ci a bien, dans les "extended key usage", le rôle de "serveur"Voici pour les infos :
Chris, Y a-t-il d'autres choses à vérifier au niveau du certificat ?Ce n'est pas le registrar qui signe le certificat mais Let'sEncrypt. Bien sûr il faut que le domaine auquel appartient pfSense soit publique, mais c'est la seule contrainte. Si ton seul domaine publique est SchoolDom, pourquoi pas, mais il ne faut pas te tromper sur la raison de la convergence vers ce domaine unique.
Enfin, rien à voir avec le sujet de ce fil, mais je ne comprends pas non plus le positionnement du proxy transparent avec une flèche depuis internet vers le LAN. Tu veux dire "reverse proxy" ou alors c'est bien un proxy (pas reverse) mais en mode transparent, auquel cas ta flèche est à l'envers :-)-
Ok pour la remise dans le bon ordre concernant l'articulation Let's Encrypt et le Registrar. ;)
-
Et concernant le proxy en mode transparent Oups !, je viens de voir ça ! :P
On ne sait pas pourquoi le navigateur indique que la connexion n'est pas sécurisée. Il y a de nombreux motifs potentiels.
ccnet, si tu veux te faire plaisir, et m'en faire une tartine, je suis preneur ! Je suis insomniaque ! ;D
Plus sérieusement, la réponse de Firefox est :
x.x.1.2 (IP Lan pfsense) utilise un certificat de sécurité invalide. Le certificat n’est valide que pour pfsense.schoolDom.com. Code d’erreur : SSL_ERROR_BAD_CERT_DOMAINDu coup, je reviens sur les propos de Chris en rappelant ma config :
-
Nom de domaine chez infodémoniak : schoolDom.com
-
Sur PfSense : Hostname : pfsense ; Domain : schoolDom.com
-
Nom de domaine de mon infrastructure côté LAN : myschool.local
Si sur l'un de mes postes clients appartenant au domaine myschool.local côté LAN, je souhaite ouvrir une com' sécurisé en HTTPS, mon navigateur se fiche pas mal de savoir a quel nom de domaine appartient la pfsense du moment que l'un et l'autre puisse faire ami-ami après transmission et validation d'un certificat. Non ?
-
-
x.x.1.2 (IP Lan pfsense) utilise un certificat de sécurité invalide. Le certificat n’est valide que pour pfsense.schoolDom.com. Code d’erreur : SSL_ERROR_BAD_CERT_DOMAIN
C'est normal si vous tentez de vous connecter avec l'ip qui ne fait pas partie du certificat. Il faut paramétrer votre résolution dns interne et vous connecter avec pfsense.schoolDom.com.
-
C'est normal si vous tentez de vous connecter avec l'ip qui ne fait pas partie du certificat. Il faut paramétrer votre résolution dns interne et vous connecter avec pfsense.schoolDom.com.
En effet, ou configurer des "alternate names" dans le certificat ;)
-
Une adresse ip surtout privée dans "alternate names", c'est plutôt à éviter.
-
Merci tout d'abord pour vos réponses. ;)
Je vais plancher sur le paramétrage de la résolution DNS interne, plutôt que sur un "Alternate Name" (sécurité oblige).
Sur mon DC j'ai fait le test, et ça marche. :D2 dernières questions, et la boucle est bouclée :
-
Nous avons validé la mise en place dans notre infrastructure d'un filtrage via Squid/SquidGuard du flux en HTTPS par un MITM. En l'état, et même sans paramétrage du DNS interne, ce certificat sera-t-il reconnu comme valide par les navigateurs de mes clients souhaitant surfer sur le web. Je dirais que oui. La pfsense qui transmettra au client le certificat public fait au nom de pfsense.schoolDom.com est effectivement pfsense.schoolDom.com. Vous validez ?
-
Je dois aussi créer d'autres certificats à partir du nom de domaine schoolDom.com, notamment pour la diffusion de certificats valides pour le portail captif Alcasar, et serverWeb intranet présent sur LAN. Je me demande s'il serait pas au final cohérent de changer mon nom de domaine de mon infrastructure, et le faire passer de myschool.local en schoolDom.com ; avec tous les risques que cela comporte… (scories de l'ancien domaine, etc.). Bonne idée, ou Mauvaise bonne idée ?
-
-
Alors d'un côté, on veut ajouter des certificats valides sur certains services web,
Et de l'autre, on veut casser HTTPS avec Squid/SquidGuard + SSLBump ?C'est très illogique.
(Et sans espoir avec le développement de HSTS, sans compter le caractère illégal de casser certains sites HTTPS …) -
:o
Hors sujet !! Sans compter le reste…
Élément utile à la réflexion : nom de domaine de la structure "myschool.local"...
Ah ! C'était une blague ?! Me voilà rassuré ! (sinon, Cf. Directives, recommandations, obligations ministérielles, de l'ANSSI et de l'EN. Bonne lecture) -
Une adresse ip surtout privée dans "alternate names", c'est plutôt à éviter.
Ce n'est pas extraordinaire, j'en conviens, ni très utile au quotidien, mais je veux bien que tu expliques le "surtout privé" ;) d'autant que là, l'objectif est d'accéder à un site qui n'est supposé être accédé que depuis le LAN.
-
@NicoPesto : vous m'avez mal lu/compris, et, de plus, je ne porte pas de jugement de valeur.
Vous avez lu les documents de l'ANSSI.
Très bien, moi aussi, et d'ailleurs, je les cite, cf @jdh:Se pose la question du déchiffrement des sessions HTTPS.
Les bonnes recommandations (pour la France) :- CNIL : (mars 2015) https://www.cnil.fr/fr/analyse-de-flux-https-bonnes-pratiques-et-questions
- ANSSI : (juin 2012) https://www.ssi.gouv.fr/agence/publication/ssltls-etat-des-lieux-et-recommandations/
- ANSSI : (octobre 2014) https://www.ssi.gouv.fr/guide/recommandations-de-securite-concernant-lanalyse-des-flux-https/
Dans ce dernier document, l'aspect juridique est (esquissé) à partir de la page 26 …
(Lisez ce qu'écrit ccnet dans ce fil …)
Le déchiffrement pose des problèmes techniques et juridiques, en particulier d'informations des utilisateurs ! (C'est factuel)
Un erreur de compréhension est faite très généralement (quand on méconnait les détails précis) :
- si le besoin est de blacklister, nul besoin de déchiffrer,
- si le besoin est d'analyser l'intérieur, par exemple téléchargement en HTTPS d'un fichier de type virus, alors le déchiffrage est nécessaire ( … mais le poste client a forcément un antivirus !).
De plus, si la majorité des sites passant en HTTPS, inéluctablement HSTS va aussi s'accroitre et il met en échec SSL Bump ...
Je ne crois pas que pfSense + les packages Squid/SquidGuard fassent aussi analyse antivirus, donc cette solution ne fait que blacklister, d'où l'inutilité de SSL Bump ! (C'est mon analyse)
NB : pour un site en blacklist, si le site est en HTTP, la page renvoyée sera celle définie par le 'redirect' de SquidGuard, et si le site est en HTTPS, la page renvoyée est blanche et il n'est pas possible de faire mieux.
Donc, dans votre cas
- un certificat valide pour un site web en DMZ est intéressant pour les users depuis Internet,
- un certificat valide pour administrer pfSense n'a d'intérêt que pour un ... administrateur (forcément interne),
- un proxy avec cassage HTTPS pour les utilisateurs internes va (forcément) changer le certificat (=remplacement de TOUS les certificats de TOUS les sites !)
Donc l'utilisateur interne ne verra pas le même certificat que l'utilisateur sur Internet , alors que vous faites l'effort de fournir un certificat valide !
Vous constatez, comme moi, que c'est illogique.A titre perso, je ne peux que vous encouragez à fournir un site web
- avec un certificat valide (vous l'avez fait)
- et avec HSTS actif (reste à faire)
