I did, but I wasn't aware that 1.30 and 1.31.0 were that massive of a difference that would cause this issue.
No, but 0.31. vs 1.3x.x is a BIG difference.
Well, I wasn't aware it wasn't auto updating as I did set that up.
Only thing was I forgot --dry-run while testing, so, now have to wait for it to actually allow me to do a proper update manually before the automatic one kicks in via cron.
1.31.0 doesn't normally upgrade of 0.31.0.
It is (usually) a completely separate install.
You may need to manually remove 0.31.0.
You should review your cron renewal. Looks like it is forcing a renew every weekday.
Check your cert history at a site like this:
That daily sequence was last seen in July .
They may have corrected that problem 
Oops. My bad. Thanks (and, in 2021 !)
So, why the concern about having to wait? Oh well
I'm wondering if there is a version for the Raspberry Pi4B or not, hmm, not sure, seems Windows only at the moment, I'll delve in to see if there are earlier versions I can upgrade it to.
What operating system is it running?
Well, I thought it was fixed, I did a --dry-run and it succeeded, but doing it without the --dry-run it failed. I did some more work on the firewall, but I got another error this time:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Obtaining a new certificate
An unexpected error occurred:
There were too many requests of a given type :: Service busy; retry later.
Please see the logfiles in /var/log/letsencrypt for more details.
Ah, still rate limited, guess I'll try tomorrow.
Information on Rate Limits can be found here: Rate Limits - Let's Encrypt
Here are a few links to articles on Certbot with Raspberry Pi
- Raspberry Pi SSL Certificates using Let's Encrypt - Pi My Life Up
- Install certbot on Raspberry Pi using the Snap Store | Snapcraft
I was able to finally get it to update, just guessing I have to restart all the servers because it is still showing the old versions, yet, they're all linked to the ones in /etc/letsencrypt/... which doesn't make much sense. I didn't think they'd cache that information.
@Bruce5051 I did your #4 originally a while ago, when I did the upgrade I used the original code I downloaded, it re-evaluated the changes to the git and updated what was needed to the latest.
My next chore is to use curl to validate the certificate against the current date and if necessary ask certbot for a renew, not sure if that is the best way to do that.
Are you into reinventing perfectly good/working wheels?
certbot will only attempt to renew a cert when it is nearing expiry.
will not force it to renew anything.
It only asks
certbot to look for certs that need to be renewed [and renew those (only)].
No, not looking to reinvent the wheel, was just not sure if the traffic was necessary or not, since the cron I have does it every 12 hours.
I set it to the 12 day of each month at midnight, so I presume that won't be overkill.
0 0 12 * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew
Why only once a month?
[that's underkill - lol]
The least I would do is once a week.
Well, the Pi it is running on, is somewhat loaded with services and server code, so it is almost always pinned at max CPU speed and anything that does anything important, spikes it up into the 50% range at that cap, so the more I can reduce, the better for overall performance. I mean I could add another one on the 27th, then 2 days a month should be sufficient.
A renewal "check" is not expensive. A cert renewal will be more so.
A renewal check looks at the expiration date in the cert on your local machine. Certbot also does one comms request to the OCSP server to ensure it has not been revoked. If not revoked and not due for expiry the check is done.
The problem with running the renew so rarely is if there is a problem getting the fresh cert. It could be temp comms issue, or Let's Encrypt servers down, or various other reasons. Running it more frequently (like every day) will be sure to renew your cert regardless of temp error. Ideally these would be random times but at minimum do not run at :00 of any hour (a very busy time for Let's Encrypt). See HERE