Getting a Let's Encrypt SSL on a Nextcloud Box w/ port 80 ISP block

I’m trying to get my nextcloud box (RPi3) set up with a Let’s Encrypt SSL, however I get a timeout error.

It turns out that my ISP blocks port 80 for us residential customers, and since the DCV challenge used when I run $ sudo nextcloud.enable-https lets-encrypt uses http://, it understandably times out. I’ve confirmed this block is the issue since I reproduce this time out when trying http:// from WAN on my domain, https:// works fine after I accept the self-signed, so they don’t block 443 which my ISP has also confirmed.

My ISP doesn’t want to unblock port 80. Am I doomed to remain with a self-signed, or is there a way to DCV with just port 443 with our without Let’s Encrypt?

You can use a different port. for http e.g. 8080 and for https: 443.

letsencrypt will “soon” use a dns TXT field …

That’s great to hear, that would solve this DCV issue. I guess I’ll wait it out.

I did just try putting http:// on 8080, yet still the let’s encypt DCV challenge tries using the standard port 80. Using this port works fine for normal insecure usage, but again the real issue at hand is getting this SSL validated.

That’s right. The LE ACME challenge demands port 80/tcp for the HTTP-01 challenge.
As TLS-SNI is still disabled, your only option left is the DNS01-challenge.

AFAIK it’s already implemented and functional in all current certbots.
You have to be able to create a subdomain for the one you’re trying to get validated, and create a TXT record for that subdomain as well.

1 Like

Good to hear! The DNS challenge would work with the domain I do own, but not the subdomain I like using. By the way for the record, is there anyway to get nextcloud.enable-https lets-encrypt to use said challenge? I didn’t see any flags in the -h output and it would be nice not having to use certbot manually and install it too that way.

I’m also going to try pointing my subdomain instead to a VPS I have, then set Nginx on it to reverse-proxy to my nextcloud using 8080, which might be the best way I have left to make the http challenge succeed.

At my work I use on our NAS as I can’t get certbot working not to mention I find the documentation simpler and it has more DNS services out of the box.

Here is how to use it for TLS verification

*Edit: Also it lists nsupdate API in the DNS update list


Sorry. I’ve completely overread the fact you’re using snap.
I can’t really help you with premade containers, as I’ve never bothered using one. I’ve just mindlessly clicked through the new topics and thought “Hey! Maybe I can help.”

IMHO that approach will introduce more problems than it’ll fix.
At very least make sure that Nextcloud will not be available on said port, if possible try to only expose requests to /.well-known/acme-challenge/ that way.

It might be worth checking our hlandaus acmetool for that job instead of nginx.

1 Like

Thanks to all of the help, I managed to manually get a cert, without resorting to a reverse-proxy:

  1. Install ubuntu classic snap: $ snap install classic --edge --devmode
  2. Enter ubuntu classic: $ sudo classic
  3. Install curl: $ sudo apt install curl
  4. Install $ curl | sh
  5. Get the TXT record to add: $ sudo /home/myuser/ --issue --dns -d mydomain.tld
  6. Add the TXT record, test with dig on any computer: $ dig txt _acme-challenge.mydomain.tld +short, result should be the TXT value
  7. Test and if good, recieve signed cert: $ sudo /home/myuser/ --renew -d mydomain.tld, note paths that the cert, private key, and fullchain CA bundle end up.
  8. Install the SSL that was generated: $ sudo nextcloud.enable-https custom -s $cert $private-key $fullchain

Restarted the RPi for good measure, https://mydomain.tld works like a charm now, looks like I’m doing this every 3 months now, and now that I know how this done, pretty painless all things considered. Thanks again for the help guys!