I have SNAP version of certbot installed with auto renew on ubuntu 22.04 LTS. Due to some issues with systemd / init, i'm running nginx as process, due to this "snap application certbot.renew" have crashed/failed to renew certificates automatically.
When running "certbot certonly --force-renew" it is asking "Are you trying to change the key type of the certificate named <<removed-domain>>-0001 from ECDSA to RSA? Please provide both --cert-name and --key-type on the command line to confirm the change you are trying to make."
Question.
1, Is there anyway to re-enable auto-renew for expired certs ?.
2, If only manual renewal is possible, what additional commands i need to pass for successful renewal.
Sure, but not sure what problem you had originally. First, does the snap version of Certbot work? Why do you also have the apt version? Anyway, what does this show:
Based on the above it looks like you removed the snap version (5.5). Or, do you mean you now also removed v1.21 ? In the end you should be using only the snap version.
As for what to do ... the error message saying "timeout" is pretty clear that Let's Encrypt's servers cannot reach your server.
You will need to find out why those HTTP requests from LE to you are timing out. Two tools we commonly use for testing connections are https://letsdebug.net and the HTTP test at Check website performance and response : Check host - online website monitoring (not its ping and not udp, the http test). Both of those sites should show successful connections if your locals comms and server are setup right. Right now both of those probably fail just like Let's Encrypt.
The most common reason is that a firewall is blocking connections. But, many other things can cause that. Without your actual domain name or more details of your setup there isn't much more specific that we can say. Keep using those testing tools until you get successful connections and retry the cert --dry-run. If that works then try getting a fresh production cert.
Can you even reach your domain from outside your local network? Like a mobile phone with wifi disabled?
Yes, it can. Let's Encrypt checks from (currently) 5 different locations around the world. You are using the --nginx option of Certbot which uses the HTTP Challenge. Can you change your firewall to allow inbound requests using HTTP on port 80 with this format: http://(domain)/.well-known/acme-challenge/(token)
Other options include using the Cerbot --pre-hook and --post-hook to open/close your firewall for port 80 when a cert request is made. Or, switch to using a DNS Challenge. Your DNS Servers still need to be accessed from all Let's Encrypt locations but at least it is not your nginx web server. See: https://letsencrypt.org/docs/challenge-types/
Your system and Certbot are not the ones used to perform the validation. As noted above, it is the Let's Encrypt ACME Servers that perform the validation and issue the cert once proven valid. Certbot is the ACME Client which makes the cert request and retrieves the cert when issued.
It's all bit strange, after uninstalling APT version(not purged), above is the output !!!. Now, i don't have /etc/letsencrypt/live/ and the .pem files have vanished.
I'm certain the auto-rewals were triggered by the SNAP version as i don't have crontab entry for auto-renewals.
That is very strange. Are you using containers or VMs? Because normally the /etc/letsencrypt directory is not affected by install/uninstall
Your nginx config may now also be damaged. Your nginx config refers to the certificate files which now appear missing. If you try to stop/start/restart nginx it will likely fail.
Show result of this. It won't affect your running nginx but will identify this error, if true. sudo nginx -t
If you use a different nginx command then use that. I wasn't sure what you meant in your first post by running nginx as "process" because of systemd troubles.
It is a VM. It is very strange and have looked whether anyone have ran "apt purge" in history.
~$ sudo nginx -t
nginx: [emerg] open() "/etc/letsencrypt/options-ssl-nginx.conf" failed (2: No such file or directory) in /etc/nginx/sites-enabled/<<removed>>.conf:19
nginx: configuration file /etc/nginx/nginx.conf test failed
What would be the correct method ?
Retrieve certificates from crt.sh and place it in /etc/letsencrypt/live/ and run Renew commands ?.
or
Reissue the certificates with sudo certbot --nginx -d yourdomain.com ?.
Yes, your nginx is now broken. You will need to manually update its config to remove all references to the non-existent files. Restoring the missing /etc/letsencrypt from backup (or your entire system) would be easiest. Or review this section of docs: User Guide — Certbot 5.6.0.dev0 documentation
No, that won't work. While you can retrieve the cert from there you cannot retrieve the private key which was only ever on your system. Plus, recreating the /etc/letsencrypt directories by hand is very difficult and involves symlinks and coordinating with the renewal config file. You should not try to do that manually.
That will not work either. That method requires a working nginx server but yours is currently broken. We may be able to create a cert using a different method. Then, if that works we then reconfigure your system to use a method that is automated properly. But, this takes a fair amount of time and effort. Your system does not behave in the usual way so I don't have high confidence this would even work for you.
Your best approach is to fix your broken nginx so that sudo nginx -t works and then get fresh cert using sudo certbot --nginx ...
After restoring missing files(certbot related) from github and commenting out previous certbot references in nginix configuration, it downloaded certs for the domain.
Question - Can i re-enable geo-restriction ?. or need to disable it for cert renewal ?.
There is a new type of challenge called dns-persist-01. It allows you to set a TXT record in your DNS once and satisfy challenges as long as you wish. It is currently in Staging for Let's Encrypt with hoped for production this quarter. I have not seen any announcement on how quickly the EFF will update Certbot to support this challenge though.
Like the existing dns-01 challenge this new challenge does not require HTTP requests from LE to your server. However, if your authoritative DNS servers are behind this same firewall this new challenge won't help. Often DNS Servers are available worldwide anyway though.