Certificate renewal: when it should happen and what to check
When a certificate should renew, why short-lived certificates are normal, and what to check when one is close to expiring.
Every certificate has an end date. Renewing means getting a new certificate and installing it before then, and today that should happen automatically, well before the old one expires.
When renewal works, you never notice it. When it stops, nothing looks wrong until the day the certificate expires and visitors see a warning. This page explains when SignalDNS flags a certificate as close to expiry, why lifetimes keep getting shorter, and how to keep renewal working.
What SignalDNS checks
We read the certificate’s start and end dates and compare them with our server’s clock. The answer says when it expires and how many days are left. When less than a sixth of its lifetime is left, at most 30 days, it needs attention, because renewal should already have happened. An expired certificate is a problem, covered in SSL certificate errors.
We can’t see your renewal setup, only the certificate the server sends now. Its dates are how we tell whether renewal is working.
The certificate expires soon
The certificate is valid, trusted, and matches the name, but less than a sixth of its lifetime is left, capped at 30 days. This needs attention. For example, a certificate issued for:
- a year or 200 days is flagged with fewer than 30 days left;
- 90 days, with fewer than 15;
- 47 days, with fewer than 7;
- 6 days, with less than a day.
Why not a flat 30 days? Renewal usually happens with about a third of the lifetime left. Let’s Encrypt recommends that, or halfway through for certificates under 10 days, and Certbot has done the same since version 4.0. So a healthy 90-day certificate has about 30 days left when it renews, and a flat 30-day warning would fire just as routine renewal is due, every cycle. A 47-day certificate would look late for most of its life, and a 6-day one all the time. A sixth is half the usual margin: if that point passes with no new certificate, renewal has probably failed at least once, and there’s still time to fix it.
How to fix it:
- If your host or CDN manages the certificate, check its status in the dashboard. Renewal stops when the provider can no longer confirm you control the domain, such as after a DNS change.
- If you run Certbot, test renewal with
sudo certbot renew --dry-runand read its log in/var/log/letsencrypt/. - If a newer certificate exists but we still see the old one, reload the web server, and check every server behind the name.
- Check your CAA records still allow your certificate authority.
Short-lived certificates are normal
Certificates used to last a year or more. 90 days is now common, and the maximum is coming down for every public authority. The CA/Browser Forum’s Baseline Requirements, which public authorities follow, cap the lifetime of certificates issued:
- from March 15, 2026, at 200 days;
- from March 15, 2027, at 100 days;
- from March 15, 2029, at 47 days.
Let’s Encrypt issues 90-day certificates by default and plans to cut that to 45 days by 2028. It also offers 6-day certificates to anyone who opts in.
Shorter lifetimes limit how long a stolen key or a wrongly issued certificate stays usable. Revocation, the way to cancel a certificate early, is unreliable, so expiry is the dependable limit. Short lifetimes also push everyone to automate, which Let’s Encrypt gives as a main reason for its 90-day lifetime.
A short lifetime isn’t a problem in itself. It only matters when renewal depends on a person remembering.
Automate renewal
Most certificates are now issued through ACME, the protocol Let’s Encrypt has used since it launched, standardised by the IETF as RFC 8555. An ACME client proves to the authority that you control the name, gets a new certificate, and installs it, with no one involved.
- Your host or CDN. Cloudflare, AWS Certificate Manager, Google Cloud, and Azure App Service renew the certificates they issue. Each has conditions: AWS renews automatically when the certificate is DNS-validated and in use with another AWS service, Google needs the load balancer listening on port 443, and Azure needs the app reachable from the internet to renew a certificate for a root domain.
- Certbot or another ACME client on your server. Most Certbot installs add a scheduled task that runs
certbot renew. Check it exists withsystemctl list-timersor in your crontab. Certificates made with Certbot’s manual plugin don’t renew on their own unless you add hook scripts. - A web server with ACME built in, such as nginx with its ACME module.
Make sure the web server loads the new certificate. With Certbot, a deploy hook runs only after a successful renewal:
sudo certbot renew --deploy-hook "systemctl reload nginx"
Newer clients also support ACME Renewal Information (ARI, RFC 9773). With it, the authority suggests when to renew, such as before it has to revoke many certificates at once. Let’s Encrypt recommends checking it at least twice a day.
Calendar reminders
Automation can fail quietly, and Let’s Encrypt’s expiry warning emails ended on June 4, 2025. A calendar reminder is a simple backstop.
The certificate answer in the report, and the certificate inspector, offer “Add a calendar reminder”. It makes an .ics file in your browser, dated for when the certificate should already have renewed: the point at which we’d flag it. Open the file in your calendar app. Nothing about it is sent to us or kept. The inspector can also check a list of names and make one calendar file with a reminder for each valid certificate.
When the reminder comes up, check the name again. If the expiry date has moved later, renewal worked.
CAA records can block renewal
CAA records in DNS list which certificate authorities may issue for a name. If they don’t include the one you renew with, renewal fails, even though the current certificate works. This can happen after a move to a host or CDN that uses a different authority.
When the name has CAA records and we recognise the certificate’s authority, the report checks the records still allow it. CAA records explains how to fix one that doesn’t.
Your provider’s guides
- Certbot: user guide, including automated renewal and hooks
- Let’s Encrypt: ACME client implementations
- Cloudflare: validity periods and renewal
- AWS: managed certificate renewal in ACM
- Google Cloud: use Google-managed SSL certificates
- Microsoft Azure: add and manage TLS/SSL certificates in App Service
- Let’s Encrypt: native ACME support comes to nginx
What we can’t tell from outside
We see the certificate the server sends now, not your renewal setup, schedule, or logs. A certificate with plenty of time left can still have a broken renewal job; it shows here once the threshold passes. We check the first public address only, so another server behind the same name might still have an older certificate. Days left are counted in whole days by our server’s clock.
Sources
- CA/Browser Forum: Ballot SC081v3, the schedule for shorter lifetimes
- CA/Browser Forum: Baseline Requirements, section 6.3.2
- Let’s Encrypt: integration guide, on when to renew
- Let’s Encrypt: decreasing certificate lifetimes to 45 days
- Let’s Encrypt: 6-day and IP address certificates are generally available
- Let’s Encrypt: why ninety-day lifetimes for certificates?
- Let’s Encrypt: expiration notification service has ended
- RFC 8555: Automatic Certificate Management Environment (ACME)
- RFC 9773: ACME Renewal Information (ARI) Extension
Last reviewed .