Disclaimer: This is coincidental with a NextCloud install - not caused by it - but I hope that some kind person can advise anyway.
We are currently evaluating NextCloud to see if we can adopt it and migrate away from some other products.
Wanting to use Docker containers as much as possible, I followed a tutorial here to install the components in five separate containers and everything went (mostly) to plan.
Unfortunately when I started up the containers and tried to access the site I realised that it was not going to work. Browser returns an SSL_ERROR_INTERNAL_ERROR_ALERT. When I look in the Caddy docker log I can see that it is trying to automatically get a cert from acme.zerossl.com which is failing because the machine is on a private network and is not DNS addressable from the outside world. The reason for this is that this instance of NextCloud will be internal to employees. When they are on the road they reach our internal network via a CloudFlare tunnel and a Warp client.
Open to suggestions as to how I can solve this issue. I would like a minimal change solutions so we can move on with our eval. We do not want to use port forwarding and would prefer to solve the issue at the caddy certificate level making as few changes as possible.
Finally, another option that might work for you - if you did want a real certificate but without enabling external access - is using a DNS Challenge for the ACME challenge.
I have zero idea the implications of using the third-party Caddy Docker image that the third party tutorial you’ve chosen has suggested
Make sure you understand the difference between running Office (via CODE) using the built-in “sidecar” app versus in its own container. For that matter, make sure you understand what CODE (Collabora Online Development Edition) is versus Collabora for Business/Enterprise
Your situation sounds a lot like a good scenario to reach out to Nextcloud GmbH about (Enterprise - Nextcloud) to get some general guidance.
It’s more of a network architecture related question rather than NextCloud related.
Solution depends on your “Private” network setup. Like for example, are you self-hosting the DNS? In that case, or even if you have a router supporting static routing or such DNS related feature, ensure nextcloud.yourdomain.com resolves to that local nextcloud server or your local reverse proxy.
In this case, any client within your private network will resolve that URL to local IP only.
CloudFlare tunnel or any outside access will have public DNS, in that case, the same domain will resolve to your external Public IP address.
Second question is your plan of handling the SSL.
In case of complex setup, wouldn’t it be better to allow your reverse proxy handle the SSL termination and allow traffic between your reverse proxy and nextcloud server stay unencrypted? Since it is within your private network?
We have an external web presence with a .com.au TLD and we also have an internal AD with a .lan TLD.
The external DNS is done via CloudFlare and the internal one is using a Windows Server box for the DNS and three domain controllers running Znetyal. There are around 60 or so machines on the internal lan.
Our external machines (at our ISP) that are public facing are really only mail server and web server.
The CloudFlare tunnel that we have set up does not have an external address per se but uses CloudFlare’s Warp Client and a CloudFlare Tunnel so that any one of your guys can (once they are connected to the Warp client) get automatic split tunneling - only machines that refer to our internal network “pfs.lan” get pushed through the tunnel we have opened - the rest just goes through CloudFlare.
I’m going to go look at Caddy (not a technology I am familiar with TBH) and see if we can drop the requirement for a “real” SSL certificate.
