How to overcome Certbot none renewal of expired certificate

How does one renew a certbot certificate on Ubuntu 20.04 that has expired but certbot renew says isn't due for renewal.
A dry run returns:
Congratulations, all renewals succeeded. The following certs have been renewed: /etc/letsencrypt/live/ (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates above have not been saved.)

no renewal failures
But when a certbot -v renew command is issued the return is:
The following certs are not due for renewal yet:
/etc/letsencrypt/live/ expires on 2021-10-30 (skipped)
No renewals were attempted.
No hooks were run.

no renewal failure


If certbot says it's not due for renewal, that's almost certainly true. Why do you assume it needs renewal anyway?


Thanks for your response.
I cannot access Roundmail anymore( it warned me prior to the certificate expiring) and Thunderbird mail likewise warned that the certificate had expired.

Should I attempt a forced renewal as suggested by


For now then, @greatl-lancer will likely want to use the --force-renewal parameter along with a --deploy-hook "nginx -s reload" or possibly -i nginx (but be careful with that one if you've modified your port 443 server block).

If certbot says renewal is not necessary and services are still using an older, expired certificate, this is probably due to incorrect installation of the certificate into those services or the relevant services need to be reloaded to make use of the newly renewed certificate.


No, you should NOT!

If certbot says renewal is not yet due, forcing a renewal will do NOTHING except adding load to the Let's Encrypt servers.

The main point from @griffin s post you're quoting is adding a nginx reload command. But we're not even sure if that's applicable to your situation (yet).

Maybe in the end you should use the force renewal option once but that's only necessary to store the other options provided on the command line and it should NOT be used to renew a certificate unnecessarily if that's the sole purpose.


OK, perhaps you can point me in the direction i.e. a research topic that adresses this particular error. I have tried restarting the nginx as suggested by one post. The dry run renew came back with: Dry run: skipping deploy hook command: systemctl reload nginx
Skipping renewal deployer in dry-run mode.

That reload command should have been run (and probably did run) when you previously renewed on August 8.

It depends on how your nginx is configured if that actually was useful or not. The same goes for your Dovecot and Postfix. If you could show us the relevant configuration files, that would be most helpful.


No, the reload command was entered by me after the certificate error raised it's ugly head, in an attempt to fix the problem.

1 Like

Ah yes, good attempt though! There is a feature request for a --dry-run-and-save option, so you can actually save stuff like those reload commands without actually renewing the certificate. Unfortunately, that new option is not implemented yet.

Currently your ngix/Postfix/Dovecot is down, correct?


It would save time if you could specify the specific files you are referring to. I am very new to mail server administration.

No I am still able to receive some emails in Thunderbird by setting exceptions

I'm currently getting "Connection refused" errors when trying to connect to your nginx/Dovecot/Postfix. That's why I'm thinking the services are down.

The certificate configuration in Dovecot is by using the ssl_cert and ssl_key options, in Postfix it's by using the smtpd_tls_cert_file and smtpd_tls_key_file options and in nginx it's with the ssl_certificate and ssl_certificate_key options.

Those should point to /etc/letsencrypt/live/ and /etc/letsencrypt/live/ respectively.


I am puzzled...... My email accounts were working 100% and I don't understand why the pointers from Dovecot, Nginx and Postfix would/could/should be affected by the certificate expiration.

"the pointers"?

1 Like

Did I misunderstand the use of point in your post ?
Those should point to /etc/letsencrypt/live/ and /etc/letsencrypt/live/ respectively.

1 Like

I was using "point to" as a verb, as in, the verb "to point your finger towards something".

In any case, I think your main concern currently is the connection refused error I'm getting when trying to connect to nginx/Postfix/Dovecot:

osiris@erazer ~ $ telnet 443
telnet: connect to address Connection refused
osiris@erazer ~ $ 

You should make sure the services are actually running.


I have just requested a friend to verify that my mail server is still running by sending an email to my address. I reason that if it gets through that the services are running correctly, and that the only problem is with how they interact with cerbot and it's funtioning. As I was typing, (not my first languige) the email arrived.

1 Like

Maybe a dynamic firewall (fail2ban?) has banned me from your server. In any case that unfortunately also means I can't debug it remotely, so I'm not really able to help you further from my end. Maybe someone else who hasn't been banned can help you.


Thank you for your time sofar and verifying that my system is reasonably secure. It seems a reinstall or a force renew is needed as there was no deploy-hook = systemctl reload nginx , or a cron job to reload nnginx after an update. A force reload seems to be the least drastic possible remedy at this point in time.

1 Like