I’m trying to get nextcloud up and running and I’m having much difficulty with HTTPS (I’m far from an expert in this stuff). I previously had a Snap installation up and running and that worked OK for a while, but not having HTTPS was becoming a problem. So I switched to Docker, but I’m still having issues.
The critical pieces of information are that my ISP blocks port 80 (but not 443) and that I’m using afraid.org as a DDNS.
Some people mentioned using a reverse proxy to get around the port blocking, but that’s a little over my head. I’d appreciate if somebody could help me out. Thanks
I have a similar issue I think. I have another service listening on ports 80 and 443, so I had to change my Nextcloud Snap instance listening ports to 81 and 444.
My install is working fine, but my HTTPS certificate is now not trusted (I use Firefox).
Am I right in thinking this isn’t an issue for personal use? It’s still HTTPS in address bar (just not seemingly trustworthy according to browsers because not 80 and 443).
Appreciate any suggestions on how I can properly secure my connection on these ports.
EDIT / SOLUTION: I have now solved my own issue by simply rededicating ports 80 and 443 for Nextcloud and enabling Let’s Encrypt. Now I just need to set cert to auto renew… Thanks to all for suggestions etc. @japs3r@Schmu
I guess the other service listening on port 80 and 443 is also using the http/https protocol? Then you could use a reverse proxy to serve multiple domains for the same ip and port pair since the requested host is conatined in the http header. SSL termination can also be handled by the reverse proxy for both services (your other service and nextcloud).
I have no tutorial at hand but a google search for “nginx reverse proxy” should give you a good starting point to get familiar with the concept. At first I would start without SSL and then if everything is working as expected add it later.
Thanks for your response. I don’t mind what type of certificate it is, whether self-signed or LE, I just want to know the connection to my VPS is secure.
I have my own domain, which I’ve pointed to my server’s IP.
By the way, that other service I mentioned, which listens on 80 and 443, I may soon purge from my VPS entirely, so hopefully that should help.
I have now uninstalled Sandstorm service which was listening on ports 80 and 443. Should this ease the process of securing connection for Nextcloud? (I’ll need to change Nextcloud listening ports back to 80 and 443 too I presume.)
I do not have my own domain, just a subdomain from afraid.org
I’d like to use Let’s Encrypt or similar because I’d like to use my Nexcloud installation to share files with less tech savvy people. They’ll undoubtedly freak out when they see “not trusted site” or similar in their browsers.
Being that my thread was kinda hijacked (no worries, I’m learning more), I do not have any other services running on my machine. I won’t rule that out in the future as I want to dabble with web technologies and doing other things with my server, but, for now, assume it’s a bare-bones, fresh installation of Ubuntu 18.04. It’s sole purpose right now is Nextcloud, if I ever get it up and running properly.
@audifanatic518
I just looked into your problem. Since port 80 is blocked by your provider you can’t use certbot to issue a Let’s Encrypt certificate. But with the acme.sh client you should be able to issue a certificate from Let’s Encrypt even without the need to stop the nginx server every time renewing the cert. Here is the guide describing your usecase.
The only reason you would need or want port 80 open is for certbot. I wouldn’t even open the port in your firewall in your case.
I would encourage you to buy a real domain. It doesn’t cost much. This will also allow you to do Let’s Encrypt DNS verification and still get a good cert, although you will have to update it manually every 80-90 days.
If you really want to open HTTP, then you’ll need to change the port. There are several ways you could go about this, including:
Changing the web server or docker listening port
Using a reverse proxy
Doing a local port forward on the server using iptables or even SSH
Using NAT port translation in your firewall (this would result in a different port when accessing via LAN)
Those are listed in roughly the order I would recommend them.
I’m not against getting my own domain. I actually do have one I use for my own website, both of which are through Namecheap. But with that said I’d rather not update it manually. I keep reading about using acme.sh instead of certbot, not sure if that’s of any help. But again, I really don’t know what I’m doing here, Nextcloud is the most I’ve ever done with server-side stuff. I’m an embedded systems guy, so very far removed from web stuff. explain it to me like I’m your grandma lol.
So here’s the deal with Let’s Encrypt. In order to get a cert signed, you have to verify control of the domain. They allow two methods. Those are HTTP verification and DNS verification. With HTTP, LE has you put a file on the web server and reads it back. With DNS it has you put in a TXT record and reads it back.
What certbot does is automate the HTTP method.
The reason I mention manually doing DNS verification is that you can do it without port 80.
Sorry for the late-ish response, I was in the hospital over the weekend (just having some tests done, no emergency thankfully). But anyway, I think I’m getting you now.
I did some more research on using DNS verification with FreeDNS (afraid.org) and (correct me if I’m wrong) I think I can do DNS verification with it, automatically as well assuming I use acme.sh instead of certbot. See the URL’s below
EDIT:
Looks like I cannot do so with public domains, I need to subscribe to their premium service, in which case, I may as well buy a cheap domain name. I got the following error message. Note that you cannot use automatic DNS validation for FreeDNS public domains
I’m not familiar with acme.sh. I use certbot with the Apache plugin on mine. Theoretically it would be possible to automate DNS verification and potentially even get a wildcard cert out of it, if you could script DNS changes. That’s the part where automatic DNS verification usually hits a snag. Many DNS providers don’t provide a mechanism for scripting record changes.