Hello Andy,
2017-11-03 13:44 GMT+01:00 Franks Andy (IT Technical Architecture Manager) <[email protected]>: > 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. Its is a redirection. Not sure why you put it in quotes, this is a proper redirection which means the browser will close the connection to haproxy and opens a direct connection to your intranet page, which then, of course will serve the internal certificate. If you open the intranet page in your browser: https://intranet/clinicalportal/clinicalportalholding.htm it won't use the letsencrypt certificate either, because the request does not go through haproxy. > 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? You need to figure out what you would like haproxy to do. Clealry a redirect is not what you want. > 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. So no redirect, no plain http error either. Seems like you need to handle it in a different backend then. Something like this (first line in the frontend before default_backend): use_backend bk_clinicalportalholding if nbsrv(bk_portal_ssl) eq 0 backend bk_clinicalportalholding mode http http-request set-uri /clinicalportal/clinicalportalholding.htm server intranet intranet:443 ssl verify none Lukas
