HAproxy me renvoi une erreur 503 sur l'HTTPS
-
Bonjour tout le monde!
J'utilise actuellement HAproxy pour publier les appli de 2 serveurs web.
Celà parfaitement bien en HTTP, mais dès que j'essaie d'accéder à un de ces serveurs en HTTPS, je rencontre directement une erreur 503….
Pour information, j'ai généré le certificat letsencrypt de mon appli via ACME.Voici la configuration de mon frontend et backend https
Merci pour votre aide!
 -
salut salut
un petit tour par ici
https://forum.pfsense.org/index.php?topic=79600.0 pour présenter sont problème.
meme si pour vous cela semble claire votre explication pour d'autre qui n'ont pas votre logique ou approche ne comprendrons ou ne chercherons pas a comprendre.
donc appliquer ceci https://forum.pfsense.org/index.php?topic=79600.0
si vous n'avez pas compris, référez vous à https://forum.pfsense.org/index.php?topic=79600.0merci
-
Bonjour, Au temps pour moi, voici les informations suivant le schéma présenté dans votre lien :
Contexte : Milieu Perso, administration avancée, firewall installé il y a quelques semaines.
Besoin : Je souhaite pouvoir accéder à une application web HTTPS hébergée sur un serveur derrière mon PFsense via HAproxy afin de pouvoir utiliser la même IP publique pour ce serveur ainsi que d'autres.
Schéma : Image jointe 1
WAN : Un Hyperviseur ESXI connecté directement via une patte WAN chez OVH.
LAN : Une patte LAN sur le PFsense avec l'adresse 10.10.10.1 ainsi que deux serveur Web afin les IP fixes respectives 10.10.10.51 et 10.10.10.52.
Règles NAT : Pas de règles NAT
Règles Firewall : Ports 80 et 443 en ANY-ANY, port 1194 pour OpenVPN sur la Patte WAN
Packages ajoutés : ACME 0.1.20, haproxy-devel 0.53_1, Open-VM-Tools 10.1.0,1, openvpn-client-export 1.4.14
Autres fonctions assignées au pfSense : VPN via OpenVPN, ACME
Question : J'ai actuellement 2 serveurs web hébergeant respectivement, pour le moment, 1 application web chacun. Un de ces deux serveur est joignable en HTTP sur un frontend HTTP dans HAproxy. Le deuxième serveur doit être joignable en HTTP et en HTTPS (Avec un certificat Letsencrypt généré par ACME) sur un frontend HTTPS HAproxy. Malgré la configuration de ce frontend HTTPS, le site demeure inaccessible via HTTPS et mon navigateur me renvoi instantanément une erreur 503.
Pistes imaginées : Je pense que mon PFsense n'arrive pas à joindre mon serveur, comme le prouve la page de stats (capture d'écran 2).
Recherches : Ouverture des ports sur le serveur, tentative de modifications de paramétrage PFsense (Désactivation du Forward IP client vers le serveur).
Logs et tests : Voir troisième capture d'écran.
Je vous remercie par avance pour votre aide !
 -
Un bon projet peut-être à terre par une foule d'imprécisions …
- Utiliser un package n'est pas à recommander avec un firewall !
- HA Proxy gere-t-il parfaitement SSL, en particulier au niveau du package : au fait, qui décrypte/crypte la liaison HTTPS ?
- si HA Proxy écoute sur 80 et 443, il faut que ... pfSense n'écoute pas sur ces ports.
- HA Proxy peut fonctionner en 'répartiteur' (HA) et en 'reverse proxy' : il est bien plus simple si c'est juste la fonction 'reverse-proxy' qui est utilisé d'utiliser le serveur web du serveur le plus important en reverse-proxy.
-
Tu devrais donc avoir quelque part sur ton serveur HTTP une trace de ce refus d’acceptation du handcheck SSL.
Si la version HAproxy de pfSense supporte de termner la session HTTPS à son niveau, en gros, tu as 2 choix:
- stocker au niveau du reverse proxy (donc de pfSense) la clé publique du CA qui a signé le certificat du serveur
- activer au niveau du reverse proxy une option "check ssl verify none" ou optional (note bien que je ne suis pas certain que ce soit faisable avec la version HAproxy de pfSense)
Comme tu l'as probablement compris, en mode reverse proxy avec terminaison de la session HTTPS, il y a 2 sessions HTTPS différentes: celle entre le client et le proxy et celle entre le proxy et le serveur web (et le proxy se comporte là comme un client web, en quelque sorte)
-
stocker au niveau du reverse proxy (donc de pfSense) la clé publique du CA qui a signé le certificat du serveur
Ne pas oublier non plus les clés du serveur, les certificats intermédiaires pour la première solution. Je ne vois pas l'intérêt de la seconde.
-
Ne pas oublier non plus les clés du serveur, les certificats intermédiaires pour la première solution.
A mon tour de ne pas comprendre ???
Le reverse proxy se comporte ici comme "client" se connectant au serveur web qui lui présente un certificat, lequel a 2 objectif:
- prouver que le serveur est bien celui qu'il prétend être (SSL hand-check)
- encrypter le flux HTTP.
Dans une implémentation "normale" de X509 qui est ce dont nous parlons ici, le client, si il vérifie la validité du certificat serveur présenté, le fait en utilisant la partie publique du CA (certificate authority) qui a signé le certificat serveur. Techniquement, comme la partie publique du certificat serveur contient l'identifiant de l'autorité qui a signé ce certificat, on peut imaginer utiliser celui-ci mais adopter cette approche reviendrait un stocker sur HAproxy un certificat par serveur accédé.
c'est exactement ce qui se passe avec ton navigateur lorsque tu accèdes des serveurs en HTTPS sur le web:
- un certain nombre de CA viennent "pré-trusté" avec le déploiement de ton navigateur, ce qui fait que tu peux accéder sans message d'erreur ou de warning tous les serveurs dont le certificat est signé soit par ces CA, soit, le plus souvent, par des issuers intermédiaires.
Lorsque le certificat est "self signed" ou vient d'un CA privé, un message de warning s'affiche et propose d'importer la partie publique du certificat serveur.
Voila pour le principe autour de X509
Si on l'applique au cas discuté ici et au reverse proxy en général, c'est à dire un proxy qui permet d'accéder à des serveurs internes, il est beaucoup plus simple de n'importer qu'une seule fois le CA qui signe les certificats de ses propres serveurs internes plutôt que le certificat de chacun des serveurs, sauf si c'est systématiquement du self-signed…. bien sûr :P
Je ne vois pas l'intérêt de la seconde.
Nous discutons ici de certificats générés très probablement en interne, avec un CA privé, voire des self-signed.
Si il y a un risque que soit le serveur accédé ne soit pas le bon (rogue web server) alors bien sûr il faut laisser l'option par défaut qui consiste à vérifier la validité du certificat présenté mais HAproxy permet d'ignorer cette fonctionnalité et c'est très pratique pour celui qui est intéressé uniquement par la fonctionnalité d'encryption du flux HTTP et confiant que le serveur auquel il accède est le bon.https://www.haproxy.com/documentation/aloha/7-0/haproxy/tls/
-
Mon "point de vue" est celui e l'internaute qui accède au serveur depuis l'extérieur.
-
Mon "point de vue" est celui e l'internaute qui accède au serveur depuis l'extérieur.
Ah en effet. Mais dans ce cas, je ne pense pas que le code erreur soit lié à un problème de certificat (et de hand-check) entre le client (l’utilisateur internaute) et le serveur (le reverse proxy)
La mise en œuvre de HTTPS au niveau de HAproxy demande de bien comprendre la notion de "passthrough" et de "SSL termination" ("bridging" ou "re-encryption" dans le vocabulaire HAproxy)
La doc de HAproxy consacre une section complète à décrire les différents modes.
