Everything looks fine until a visitor sends you a screenshot of a red browser warning that says your site is not secure. Certbot not renewing is one of the quietest problems in web hosting, because the failure happens in the background and shows up only when the certificate expires. The good news is that the cause is usually simple and the fix takes a few minutes.
This guide walks you through seven checks in a sensible order. Run the commands on your own server, replace the values in angle brackets, and test with a dry run before you change anything.
Table of contents
Certbot is a free tool that gets and renews certificates from Let’s Encrypt. Those certificates last 90 days today. Let’s Encrypt has announced that the default will move to 64 days from 10 February 2027 and to 45 days in 2028, so renewal has to be automatic. You can read the plan in the Let’s Encrypt announcement.
Certbot normally installs a timer or a scheduled job that runs the certbot renew command regularly. The command renews only certificates that are close to expiry, so running it often is safe, as the Certbot documentation explains. When that scheduled job stops or fails, certbot not renewing becomes a countdown to an outage. A small gap like this is exactly what our business data security checks help you catch.
The typical signs of certbot not renewing are a browser message such as “Your connection is not private”, an error code like NET::ERR_CERT_DATE_INVALID, or an API client that suddenly refuses to connect. Because renewal runs in the background, you often learn about it from a visitor, not from your server. If that has just happened, do not panic. Most cases come down to one of the seven checks below.

sudo certbot certificates
echo | openssl s_client -connect <your-domain>:443 -servername <your-domain> 2>/dev/null | openssl x509 -noout -dates
If the first command shows a new expiry date but the second shows an old one, skip ahead to step 6.
certbot.timer or snap.certbot.renew.timer. If nothing is listed, renewal is not scheduled.
systemctl list-timers | grep -i certbot
sudo systemctl enable --now certbot.timer
sudo certbot renew --dry-run
sudo ufw status
curl -I http://<your-domain>
sudo cat /etc/letsencrypt/renewal/<your-domain>.conf
Make sure the authenticator and any webroot path still match your current setup.
sudo certbot renew --deploy-hook "systemctl reload nginx"
Use apache2 instead of nginx if that is your server. Once this works, place the same command in a script under /etc/letsencrypt/renewal-hooks/deploy/.
sudo apt update && sudo apt install --only-upgrade certbot
sudo snap refresh certbot
Use only the line that matches your installation.

Monitoring is the habit that saves you next time. Our Kubernetes observability guide explains the idea of watching signals before users notice a problem, and it applies equally to a single small server.
--dry-run for testing instead of --force-renewal.Treating certificates as part of everyday engineering, not a one-time task, is the heart of DevSecOps. If you run containers, our Docker security best practices give you a similar set of repeatable checks.
In most cases of certbot not renewing, the usual causes are a stopped timer, a blocked port 80, a changed web server or folder path, or an outdated Certbot. The dry run in step 3 normally points to the exact reason.
Run sudo certbot renew. If the certificate is not yet due, Certbot says so and does nothing, which is safe. It is the quickest way to rule out certbot not renewing as a one-off glitch.
Currently 90 days. The plan is 64 days by default from February 2027 and 45 days in 2028, so automation matters more every year.
--force-renewal?Only occasionally. Repeated use can hit rate limits and leave you unable to issue a certificate for a few days.
A certificate that renews quietly is a sign of a healthy setup, and fixing certbot not renewing is mostly a matter of patient checking. Check the timer, test with a dry run, reload the server and keep an eye on expiry. Ten calm minutes now can spare you a stressful evening later.
What caused your renewal to fail, and which fix finally worked? Tell us in the comments so other readers can learn from it.
The Nandan Sinha newsletter
Get new articles on technology, practical guides, wellbeing and spirituality, delivered to your inbox.
Subscribe by email. Confirm your address to join. Unsubscribe anytime. Privacy policy.
We use essential cookies to run this website and optional cookies for analytics and advertising. Choose Accept All, Reject, or Preferences to manage optional cookies. You can change your choice at any time.
Manage your cookie preferences below:
Essential cookies enable basic functions and are necessary for the proper function of the website.
These cookies are needed for adding comments on this website.
Google's current Sign in with Google client library. It renders the Google sign-in button, or the One Tap prompt, so visitors can log in to your site with their Google account. It replaces the older Google Sign-In platform library.
Service URL: policies.google.com (opens in a new window)
Google Tag Manager simplifies the management of marketing tags on your website without code changes.
Statistics cookies collect information anonymously. This information helps us understand how visitors use our website.
Google Analytics is a powerful tool that tracks and analyzes website traffic for informed marketing decisions.
Service URL: policies.google.com (opens in a new window)
Marketing cookies are used to follow visitors to websites. The intention is to show ads that are relevant and engaging to the individual user.
AddToAny provides share and follow buttons that let visitors post your pages to social networks, messaging apps, and bookmarking services.
Service URL: www.addtoany.com (opens in a new window)
You can find more information in our Privacy Policy and Privacy Policy.





Leave a Reply