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 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).
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.