Issue (apparently) after upgrading certbot/ubuntu

Help
1

I recently migrated a website from a server running Ubuntu 18.04LTS+certbot 0.31.0 to Ubuntu 24.04LTS+certbot 5.5.0 (via snap). I copied over the old /etc/letsencrypt directory to the new server and assumed everything would continue on as it had in the past. Unfortunately, it seems that certbot on the new server is skipping over the certificate renewal. It claims "The following certificates are not due for renewal yet" despite noting the expiration date is quickly approaching in 11 days: "expires on 2026-04-19 (skipped)"

Running "certbot renew --dry-run" succeeds and running "certbot renew --force-renwal" also succeeds so I am at a loss as to why "certbot renew" fails to recognize it is (past) time to renew the certificate and skips the renewal process.

For reference, here is what the renewal configuration file for the certificate looked like prior to me forcing the update:

#renew_before_expiry = 30 days
version = 0.31.0
archive_dir = /etc/letsencrypt/archive/www.REDACTEDDOMAINNAME.com
cert = /etc/letsencrypt/live/www.REDACTEDDOMAINNAME.com/cert.pem
privkey = /etc/letsencrypt/live/www.REDACTEDDOMAINNAME.com/privkey.pem
chain = /etc/letsencrypt/live/www.REDACTEDDOMAINNAME.com/chain.pem
fullchain = /etc/letsencrypt/live/www.REDACTEDDOMAINNAME.com/fullchain.pem

#Options used in the renewal process
[renewalparams]
account = REDACTED_ACCOUNT_ID
authenticator = nginx
server = https://acme-v02.api.letsencrypt.org/directory
#autorenew handled via script
autorenew = false
[acme_renewal_info]
ari_retry_after = 2026-02-23T21:26:23

After the forced renewal, the only changes I see in the above file contents are:

version = 5.5.0
autorenew = False
key_type = rsa

That all seems reasonable, though it is curious why the explicit key_type line was added and that the ari_retry_after value did not change from the previous data in February.

Can anyone shed some light on what might be wrong here and/or what I might need to do to enable renewals to go through smoothly in the future without having to be forced?

Thanks in advance

2

This disables the renewal unless --force-renewal/--renewal-by-default or --dry-run are used. Why was it disabled?

2 Likes
3

Well that would explain the behavior, though I wish the log message would mention a different reason in this case vs. saying the certificate isn't due for renewal.

Based on the comment above it I think it was meant to prevent something other than an external script from calling certbot for renewal. My guess is the certbot systemctl timer and the behavior changed between 0.31.0 and 5.5.0 causing it to no longer renew without force. I should migrate the pre/post logic out of the legacy external script and into the certbot hooks and then re-enable it before the next schedule renewal.

Thanks for the pointer.

3 Likes