Not sure where to post this, please move if there’s a better category!
HSTS is a really powerful tool for preventing a man-in-the-middle attack. & I’d love to take advantage of it. However, I’ve more than once had HTTPS issues that prevent me from getting to NC (I know, in theory, this should not be the case–and maybe one day it won’t be?).
I have my NC behind a reverse proxy on a DMZ. I’ve also got the database on a limited access config, so I can’t easily move my NC VM to my LAN & debug locally. The reverse proxy makes navigating to NC impossible via IP address, so I need to use a URL. This URL needs to be defined in the config, and will be tagged with HSTS as soon as I visit!
Is there any way I can create a specific URL, even if it’s only local, for debugging that HSTS will not apply to?
What do you mean by DMZ? Sorry if that the question might sound silly, but DMZ is nowdays more of a buzzword on gaming routers than a specific concept. Normally you have external facing services in their own network segment and then put corresponding firewall rules in place. I guess you could call such a network segment DMZ.
To your actual question. If you have to move the Nextcloud anyway, it should not be too much additional effort to change the config.php so that you can acces the Nextcloud without ReverseProxy and change it back again after you finished the “debugging” . Unless the problem you are trying to debug occurs only with the reverse proxy, but then at least that is obvious after the “debugging”
If you simply want to access your Nextcloud internally via domain name, you need a local DNS server or a host override entry in the hosts file of the computer with which you want to access your Nextcloud. Then the connection from the local network via reverse proxy with HSTS enabled shouldn’t be a problem anymore because you can use the external domain name then.
But maybe you can give us some more information about your network setup. I’m sure there is a solution how you can “debug” your Nextcloud (whatever that means) without “moving around” your installation.
No worries, it’s a good point. It’s a separate VLAN firewalled off from my LAN. Not some “default DMZ” setting.
Sorry if I was unclear there. The problem is that I cannot easily move my Nextcloud VM–that seems like the “easy” solution and it would avoid this whole problem. But I would have to move the database & change IP addresses to resolve (or create a new environment?). Either solution introduces new variables which is exactly what I’m trying to minimize.
The complication really comes from the fact that I have 2 firewalls. The 1st is the main router which forwards all web traffic to the 2nd router on the “server” VLAN. It routes web traffic via HAProxy Reverse Proxy. Within the 2nd router, I have a separate HAProxy listener for LAN & web traffic so I already have a number of subdomains that only resolve on LAN. So adding the domain is trivial, I just need to know how to configure NC/apache so that URL #1 is HSTS but domain #2 is not.
But why using diffrent domains for the same service? I get that not every service should be accessable from the web. But I see no advantage in using a seperate internal domain to access a service which is publicly available anyways. Just put all public facing services on one proxy and allow access from LAN and all internal services on the other proxy without access from WAN. But maybe I’m missing something here…
Yes. But why do you even need that second domain? You can’t debug HSTS / HTTPS problems from one connection with another connection via another domain name. But you could use another browser, the incocnito mode of your browser or another subdomain… All this assuming that you didn’t summit your domain to the preloaded lists, and didn’t use the “all subdomains” parameter…
But even if you did pass all subdomains and preload, it is not really a problem on a server over which you have full control. At worst, you temporary bypass the proxy and use the IP address or cloud.localdomain to access the webgui… which leads us to the answer of your question. Yes of course, you can use multiple domains with Nextcloud. Just enter the second domain as a trusted domain to the config.php. And as long as there is no public DNS record, no one will be able to use this domain from the Internet to access your Nextcloud.
I was unaware there was an option for that! I thought HSTS was all or nothing! How does one do this? That is an EVEN BETTER solution than what I was asking for
The question is for what exactley you plan to use the additional domain…?
If it is only for yourself in an emergency situation, it is imho justifiable to to a dirty workarround like bypassing the proxy. But that’s just me. Unless of course you need it once a week because HTTPS doesn’t work on your main domain that many times. But then you have a problem somewhere else that you need to address.
If you have many users and they need to use this as a fallback, it’s a pain for those users Especially if they use mobile clients, sync clients etc. Because these would have to be reconfigured to the other domain while you are temperuing with the main domain. Not really practical imho.
See here… It’s done by the “includeSubDomains” and “preload” parameters. But I don’t see how this is gonna to help you either. HSTS only blocks the connection if HTTPS fails, but HTTPS simply must not fail! …and if it does, it’s most likley because of a expired certificate or a misconfiguration of the webserver / Proxy. How does a less strict HSTS policy or a second domain help you to debug such a thing? But maybe I don’t see the hole picture here.
I think the questions you have to ask yourself are:
Q: Why is HSTS failing?
A: Because HTTPS is failing!
Q: Why does that happen so often that I start thinking about it and even about a second domain name?
A: …
Anyways… as I already said, multiple domains are doable. Nextcloud must simply be aware of the domain respective proxy via the “trusted domains” or the “trusted proxy” parameter in config.php. The rest is handled by the webserver / proxy. You can use 10 different domains if you want. And as long as there is no public DNS record for a certain domain pointing to your public IP address, nobody outside your network can connect to it via this domain.
