Hi all,
We have a test haproxy instance that is using a letscrypt certificate, and is
in a DMZ zone. We have internal network servers delivering an application via
https using an internal CA certificate, and all works fine - the client
connects, sees the letscrypt cert and since the load balancer o/s has the
internal CA in its trusted root certs, the verification works there too.
The query I have is where we fail both backend servers we're using and have the
client redirect to an internal website errorloc directive via https to deliver
a "sorry the service isn't available" :
Here's the config:
frontend ft_web_ssl
bind 0.0.0.0:443 name https ssl crt
/usr/local/bin/dehydrated/certs/portal.fqdn/concat.pem
mode http
option httplog
option forwardfor
tcp-request connection track-sc0 src table connections
default_backend bk_portal_ssl
backend bk_portal_ssl
mode http
option httplog
option httpchk GET /Login/Heartbeat HTTP/1.0\r\nHost:\
portal.sath.nhs.uk
http-check expect rstatus 200
balance roundrobin
stick on src table connections
cookie SERVERID insert nocache indirect
default-server inter 2s rise 10 fall 20 on-marked-down
shutdown-sessions
errorloc 503 https://intranet/clinicalportal/clinicalportalholding.htm
server RSH-CP-IIS1 192.168.176.175:443 cookie 1 check ssl
server RSH-CP-IIS2 192.168.176.176:443 cookie 2 check ssl
First of all, the errorloc "redirection" from a 503 works fine but since this
intranet page is configured using an internal CA certificate and for some
reason the client doesn't see the letscrypt certificate, rather the one from
the website itself, it therefore warns on the client browser if they don't have
the internal CA root cert installed as trusted.
I would have thought that the client should get the letscrypt frontend
certificate in this case? How come not, and is there any way of fixing this?
I'd rather keep ssl between DMZ and intranet zone if possible; obviously using
plain http for the errorloc 503 is one way around, but would rather not do this.
Thanks
Andy
