Hello,
On Fri, 17 May 2019 at 16:42, Aleksandar Lazic <[email protected]> wrote: > After some reading and testing I have created that config file. > > https://gist.github.com/git001/73d1b7bcc3813ba40028c887e4f3e7f6 > > From my understanding is the workflow like this, it this right. > > ``` > client -> tcp listener reads req.ssl_sni. NO TLS handling -> > -> req.ssl_sni MyDomain.im -> go to be_sni_xmpp/fe_sn_xmpp -> > -> handle tls from client => connect to server handle server TLS > -> default backend -> go to be_sni/fe_sni -> > -> handle tls from client => talk to backends > ``` > > The requirement is to run haproxy on 443 and route to http backends (nextcould > and mod_upload of ejaberd) and tcp backend (xmpp tls direct). Ok, that's correct, except for the use of ssl_fc_has_sni, which I'd advise to not use. Instead, when you terminate SSL, just use the Host header for any HTTP routing decisions. ssl_fc_sni is almost always misused, you can see that the current ML thread "Host header and sni extension differ" (which also has links to older discussions). When you can, please *DO* use the host header. Make sure you certificates don't overlap, at least between those that passthrough via TCP and those that you terminate at haproxy. > I wanted to use in `frontend https-in` `alpn h2,http/1.1` but the nextcloud > apache uses http/1 and therefore the server in `backend nextcloud-backend` > failed to serve the http traffic. I don't understand why this would be a problem. Using h2 in the frontend and h1 in the backend is perfectly supported, you server does not need to know h2. Maybe don't use httpclose in the backend and consider enabling htx. (if removing httpclose fixes this than you probably hit a bug we never quite figured out [1]). Lukas [1] https://github.com/haproxy/haproxy/issues/15
