I’ve set up Nextcloud with the fantastic AIO docker solution.
I think it’s a great tool.
In front of Nextcloud there is a Caddy reverse proxy. I can access “cloud.mycooldomain.com” with https just fine from the browser and from the WebDAV.
My only concern now is this: when Internet is down I can’t access Nextcloud even from machines in the same LAN.
My solution was adding “[my LAN server ip address] cloud.mycooldomain.com” in “C:\Windows\System32\drivers\etc\hosts”, but https fails if Internet is down (for obvious reasons). It works only if Caddy equips “cloud.mycooldomain.com” with a self-signed certificate. But at that point WebDAV access fails (Windows doesn’t accept self signed certs?).
But running a local DNS isn’t like editing “C:\Windows\System32\drivers\etc\hosts”? Even if my machine can correctly translate “cloud.mycooldomain.com” into an IP address, if the Internet is down then the https will fail, right?
Editing the hosts file is an alternative to running a local dns server. It should actually work automatically if the correct header is set as the certificate will keep working for your domain even without public internet.
If I don’t edit “C:\Windows\System32\drivers\etc\hosts” and Internet is up, everything is perfect (a lock is show in the chrome address bar).
If I edit “C:\Windows\System32\drivers\etc\hosts” and Internet is up, I get a warning in chrome (a red exclamation mark is shown in the address bar), but everything runs ok, even WebDAV.
If I edit “C:\Windows\System32\drivers\etc\hosts” and Internet is down, chrome throws “NET::ERR_CERT_AUTHORITY_INVALID” and WebDAV kicks me out. I’m positive this is happening because my machine doesn’t have the ability to check if the Let’s Encrypt cert set up by Caddy reverse proxy is valid or not.
I’m pretty sure the DNS isn’t the issue here: the domain name is correctly translated to the correct ip.
I’ve added the ability to reach nextcloud from 2 separate domains: “cloud.mydomain.com” and “cloud.local”.
Users will always use “cloud.mydomain.com”, but they will fallback to “cloud.local” when the Internet connection is down. The “cloud.local” will work only if nextcloud server is in the same LAN of the clients (of course).
Step 1: make it possible for the client(s) to correctly translate “cloud.local” to the IP of the local server.
The translation source and failing HTTPS are going to be unrelated issues triggered by the same event (loss of internet connectivity).
Loss of upstream connectivity would not directly impact HTTPS under normal circumstances.
It’s not the same thing at all, but both should work. The difference is running split-horizon DNS is a professional working solution, and editing the hosts file is just putting a bandaid on the problem.
Is Caddy providing the intermediate certificate? If so then it should still be able to verify it without internet access.
Is it the IP of Nextcloud or Caddy?
I would discourage this as a solution because it will probably come with other unintended consequences later, such as problems with sync clients. It would be better to find out why your cert won’t verify.