Stubborn Snappy Certificate Renewal Puzzler

All,

I have read the earlier questions and solutions for getting certificate renewal working. Unfortunately, after several iterations, I’m still stuck:

# cd /var/snap/nextcloud/current
# mv certs certs.1
# reboot now

After reboot:

# nextcloud.enable-https lets-encrypt -d

Attempting to obtain certificates... error running certbot:

Saving debug log to /var/snap/nextcloud/current/certs/certbot/logs/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for db1.ddoherty.net
Using the webroot path /var/snap/nextcloud/current/certs/certbot for all 
unmatched domains.
Waiting for verification...
Challenge failed for domain db1.ddoherty.net
http-01 challenge for db1.ddoherty.net
Cleaning up challenges
Some challenges have failed.
IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: db1.ddoherty.net
   Type:   connection
   Detail: Fetching
   http://db1.ddoherty.net/.well-known/acme-challenge/2e3uVpkWxdg0FEahycsMu3S9X_83D8LRk-3B13XBpe0:
   Timeout during connect (likely firewall problem)

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.
 - Your account credentials have been saved in your Certbot
   configuration directory at
   /var/snap/nextcloud/current/certs/certbot/config. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.

I verified that my DNS and firewall are working with:

# nc -zv db1.ddoherty.net 80
Connection to db1.ddoherty.net 80 port [tcp/http] succeeded!

# nc -zv db1.ddoherty.net 443
Connection to db1.ddoherty.net 443 port [tcp/https] succeeded!

I edited /etc/hosts to include my domain (ddoherty.net) in the FQDN of the nextcloud host, so that

# hostname -f
db1.ddoherty.net

works (it was reporting db1.lan earlier, which I thought might be the problem).

I am at a loss to figure out what is going wrong.

Any guru-isms would be most welcome.

Is that your actual domain? Because it’s timing out for me as well.

I administer 4 linux servers remotely, 2 of which are Nextcloud. In the last month or so, I’ve suddenly
experienced really bad connectivity to all of them (over SSH, but not HTTPS, which is still OK). My cellular provider has some new harsh QOS rules now which don’t just throttle down bandwidth, they flat out tackle my SSH connections (which used to work fine over a month ago, albeit slowly).

Then when I try those same SSH connections through a VPN tunnel (sometimes Wireguard, sometimes Zerotier), then BOOM, I get the decent behaviour I’m used to having over a month ago. And it proves my ISP is who is being a jerk, and who are QOS’ing the SSH connections into the dirt.

So I guess I encourage you to ask yourself if there are QOS rules which have changed somewhere for you (probably your ISP cranking up their evil dials a few notches on their routers, and seeing if they can get away with it).

How do you solve your SSL problem at hand? Not sure. But your routing between your Nextcloud server and Let’s Encrypt must work decently, is all I’m saying (and maybe don’t just assume it should work fine).

Yes. I have temporarily set it up on a self-signed certificate. Try again, that might not have been in place when I posted.

Thanks. I use VOIP phone service, so that might be a factor. I’l check it out.

OK. I tried to do the nc command to port 443 from a remote system, and it succeeded really quickly. So I don’t think I’m getting hammered by QoS.

Still not working for me, neither http or https.

Hmm. You don’t just get a warning about an untrusted certificate? You get something like “IP address not found”?

No, it times out. Looks an awful lot like a firewall problem, like Let’s Encrypt is saying. You sure you have ports open on your external-facing router, for example? It’s possible that your network-internal tests using db1.ddoherty.net don’t leave the network.

@kryofa. Many thanks for taking the time to check this out. I’m going to do some checking with someone outside my domain to see if that’s the issue. I’ll report back.

@kyrofa. That did it. I had totally forgotten that I had ufw running on the host, in addition to the firewall on the router. Fixed that, and now it worked.

BTW, I had to leave off the -d flag on the nextcloud.enable-https command. That apparently makes it a dry run and doesn’t actually update the certificate. I misread the instructions from another thread.

Thanks for your help.

1 Like