Certificat SSL Lets Encrypt valide, signé - WebGUI Pfsense non sécurisé ?!!
-
Bonjour à tous,
Tout est dans le titre, mais avant cela :Architecture :
Avant propos :
Site web schoolDom.com est hébergé chez infodémoniak.
Nom de domaine sur le LAN : myschool.localRemarque : sur la pfsense, dans General Setup la config était :
-
hostname : pfsense
-
Domaine : myschool
J’ai effectué la modification suivante avant installation du package Let’s Encrypt.
Domaine : schoolDom.com.
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.
Objectif : Console PfSense en HTTPS sur browser avec certificat valide.
Solution envisagée :
Installation package Let's Encrypt pour génération certificat via protocole ACME auprès du registrar. Enregistrement de type TXT dans le fichier de zone DNS chez Infomaniak.Procédure :
1. Installation du package ACME sur PfSense.
2. Création de l'Account Key.
3. Création du Certificat par méthode DNS-Manuel, et avec une Action List : /etc/rc.restart_webgui Shell Command
4. Enregistrement de type TXT dans le fichier de zone DNS chez le registrar.
5. Un petit renew avec comme résultat des courses :[Sun May 13 10:21:09 CEST 2018] Renew: 'pfsense.schoolDom.com'
[Sun May 13 10:21:10 CEST 2018] Single domain='pfsense.schoolDom.com '
[Sun May 13 10:21:10 CEST 2018] Getting domain auth token for each domain
[Sun May 13 10:21:10 CEST 2018] Verifying:pfsense. schoolDom.com
[Sun May 13 10:21:17 CEST 2018] Success
[Sun May 13 10:21:17 CEST 2018] Verify finished, start to sign.
[Sun May 13 10:21:19 CEST 2018] Cert success. 8)
–---BEGIN CERTIFICATE-----
………………………..
-----END CERTIFICATE-----
[Sun May 13 10:21:19 CEST 2018] Your cert is in /tmp/acme/pfsense-
LetsEncryptCertificat//pfsense.schoolDom.com/pfsense.schoolDom.com.cer
[Sun May 13 10:21:19 CEST 2018] Your cert key is in /tmp/acme/pfsense-
LetsEncryptCertificat//pfsense.schoolDom.com/pfsense.schoolDom.com.key
[Sun May 13 10:21:20 CEST 2018] The intermediate CA cert is in /tmp/acme/pfsense-
LetsEncryptCertificat//pfsense.schoolDom.com/ca.cer
[Sun May 13 10:21:20 CEST 2018] And the full chain certs is there: /tmp/acme/pfsense-
LetsEncryptCertificat//pfsense.schoolDom.com/fullchain.cer
[Sun May 13 10:21:20 CEST 2018] It seems that you are using dns manual mode. please take care: The dns manual mode can not renew …
[Sun May 13 10:21:20 CEST 2018] Call hook error.6. Modification dans Admin Access : protocole HTTPS, avec nouveau SSL certificat.
7. Résultat : nouvelle connexion à la pfsense via console « Non sécurisé » !!! Pourtant le certificat est valide, signé. >:(
Toutefois, dans le Certificat, deux champs sont avec point d’exclamation : « Utilisation de la clé », et « Contraite de base ». ???
Là, un coup de main plus que bienfaiteur ou une tarte à la fraise, j'suis pas contre. ;)
Merci à vous. -
-
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)
