Once you know it it’s actually pretty simple and also a little bit stupid.

So, this is a shory mystery story about a redirect that goes wrong in 90% of the cases and how I finally fixed it.

One of my users had the issue, that whenever being connected from a certain University network and wanted to go to our Nextcloud instance, the only thing that was returned was a certificate error. Huh? What the heck is your firewall doing there and how is this even possible?!?? What baffles me even more is that about 90% of the requests went wrong, but the rest was fine. What the heck?!?

On that server I use sslh for multiplexing of different TLS domains. I’m running a IPv6-first approach (almost) all of my machines, and sslh is my way to go to reverse proxy different servers from one public IPv4 address. (Did I already mentioned that one should not use legacy IP anymore?)

After banging my head against a wall for some time, and some fruitless debugging sessions, I suddenly got a revelation. The domain the user is being redirected is the default domain (that was clear) and it was not a misredirect, but a simple timeout. And it only happens on that particular network because who knows what the heck they are doing there.
sslh accepts a new connection and determines where the request should be redirected based on the first packet(s) on that request. For some reason on that University network has a latency of more than 2 seconds between establishing a connection and the first data packets.

So … I increased the timeout for sslh and suddenly all the wrong redirects are gone and the user is happy again 😃

So, another lesson learned: When using sslh and you find yourself in the situation that Nextcloud (or any other service) is being misdirected to the wrong host (Sympton: wrong SSL/TLS certificate), then check if you are encountering timeout issues. You will see them when verbose: 1 is set in your config.

And that’s it for now. Happy hacking!