I guess I need to put my title here too. “How to install Nextcloud on an internal network”
I can install the Snap Nexcloud with no problem but everything needs SSL to sign on. For browsers, you can click past the warnings most of the time. But the windows app won’t connect. My phone won’t connect when on the same wifi it used to with no problems. Is there something I can do to shut off the SSL demands?
Hi,
A better way is to make your certificate signed by an external service. SSL on HTTP server is highly recommended nowadays.
Based on this page :Home · nextcloud-snap/nextcloud-snap Wiki · GitHub
you only need to use : sudo nextcloud.enable-https lets-encrypt
But you must open port 80 (and 443 but I’m not entirely sure).
OR
You can just type http://nextcloud.domain.com instead of https://nextcloud.domain.com if the snap does not comes with https redirection.
Hello,
Snap Nextcloud works fine with HTTP only. I dont see it needing or asking for SSL to operate.
Thanks.
Although you can disable SSL, you really shouldn’t.
You could set up your clients to trust the self signed certificate, and that should resolve the issues.
Alternatively, perhaps a much easier solution in the long term… You could still run certbot, even if you don’t allow access to the Nextcloud virtual host from the internet. Then your cert would actually be valid.
1 Like
The process of using certbot without online confirmation, is tricky. You will need a public reachable DNS server where you can add a record which LetsEncrypt can read. However if you do happens to have that, you can make subdomain certificates after registering one wildcard certificate using this method.
If using on internal network only, I agree that you still should use HTTPS. However unless you are an organization with own internal CA and the power to push policies to all devices (adding trusted certificates using device management), there is really only two feasible options:
-
Reverse proxy with manually maintained certificates
-
Do not use HTTPS
Option 1
You can generate, buy, use and deploy, any certificate of your choice and ensure https using a trusted certificate.
Option 2
When on an internal network only, then you are at risk of leaking authentication information for anyone on your local network. Worse if using wifi (unles WPA2/3-Enterprise with certificates), someone inside range can easily sniff your trafic as the WIFI security is easily cracked, and your files are not secure any longer. However this risk is serious IF someone would find at interesting to target you, but the probability shoudl be considered minor (I do not know you. You could be an interesting target, hence raising the probability significantly).
I would strongly recommend you to use HTTPS no matter the circumstances. I know that it is possible to manually add any certificate to mobile devices trust store, but this has to be done manually, always. Only way to avoid that, is a certificate signed by a public, recognized international, trusted CA.
You can use automatic http verification and not have the Nextcloud virtual host available to the internet. Just serve some other site like the default site, or a redirect to bing.com, for connections coming from the internet.
Or, even simpler, enforce redirect to HTTPS but don’t forward port 443. Certbot only needs port 80.
Yeah but that still exposes the web server to the internet. If you don’t want that, DNS verification is the way to go. Most bigger domain registrars / DNS providers and afaik even some DynamicDNS Providers, like e.g. no-ip do provide APIs, which makes it relatively easy to rollout certificates, without exposing your server or any ports to the internet. When using the API of the DNS provider, the certificates will also get renewed automatically.
Yes it does expose the web server itself, but the port 80 site can consist of nothing but a redirect. Not even an actual HTML page. If that’s a security risk, then the web server isn’t suitable to be used on the internet.
Just putting it forward as a relatively easy permanent solution to the certificate problem.
If you don’t expose it, it doesn’t have to be. 
Yeah this is certainly a way to get your certificates relatively easy. Nevertheless, the web server and the sub domain are still accessible from the Internet, which leads to people and bots poking at it. On the other hand it’s definitely more secure than exposing your Nextcloud. Which, by the way, is what I do. But I have other services and servers running that I don’t want to expose to the Internet in any way.
Also, I wouldn’t say the DNS challenge via API is significantly more complicated. Yes it isn’t covered in most “Install Nextcloud in 20 mins” tutorials, and yes there are a few prerequisites that need to be met, such as a DNS provider with API access. And yes the free plan of most DynDNS providers probably does not offer an API, and yes without API access it gets complicated. But other than that…?
Oh! …and In return you can get nice things like wildcard certificates. 