Struggling to use HTTPS / Enable HAPROXY_SSL

[sllabres]

Hello,

We've been able to run the platform without issue using HTTP only. However, we're looking to run all our services / web apps over https. We've enabled the flag "HAPROXY_SSL" as per readme and mapped pem file. Subsequent requests are rejected by haproxy.

We've spent a fair bit of time looking through a number of scripts (haproxy.cfg, haproxy.cfg.ctmpl, haproxy_reload.sh). We've learned that haproxy.cfg uses an environment variable "PORT_HTTP" to set the port binding (line 37).

We removed that variable and manually set it to "443" we're able to access the application.

We put the variable back in the haproxy.cfg file and set the PORT_HTTP variable ourselves to 443 and then ran haproxy_reload.sh. This stopped the application working. We've seen that line 63 in haproxy_reload.sh sets the variable that the haproxy.cfg file uses, which appears to set it to a blank value in its default state.

My bash isn't up to much so I'm not clear on what's stupposed to happen and if we've missed a setting elsewhere in our configuration / application setup.

Would anyone be able to offer some help / guidance?

Thank you,

Seb

[sielaq]

I suspect that you have first tried with no SSL (port 80) and then you have enabled ( port 443)
and that cleanup of previous iptables mapping did work.
Seems like we have missed the fix that was already mentioned in some issue before.

[sielaq]

please wait till latest image is build and try again (pull the latest and re-tag it for 0.3.3 version)

[sielaq]

docker pull panteras/paas-in-a-box:latest
docker tag panteras/paas-in-a-box:latest panteras/paas-in-a-box:0.3.3
docker-compose rm -f
docker-compose up -d
docker exec -ti <name> bash
supervisotctl restart consul-template_haproxy

the last command should stop and do the cleanup up of your current iptables , and start ( set up a new with 443 port)

[sielaq]

any update on this ?

[sllabres]

Apologies for the slow reply. I've been away. My team picked it up in my absence and it worked perfectly.

Thank you!

We're still struggling to get HTTPS working in full as our marathon health checks are failing. I suspect we're missing something daft!