Public SSL/TLS certificates are getting much shorter lives. The maximum is already down from 398 to 200 days, and by March 2029 it will be just 47 days. If anything about your certificates is still renewed by hand, from a calendar reminder or a ticket, now is the time to change that.
This guide explains what's changing and when, why, and gives a practical checklist to get every certificate you depend on ready.
What's changing, and when
In April 2025 the CA/Browser Forum, the body of certificate authorities and browser makers that sets the rules for public certificates, approved a phased reduction. Two limits shrink:
- Certificate lifetime: how long a certificate can be valid.
- Domain validation reuse: how long a certificate authority may rely on an earlier check that you control the domain before checking again.
| From | Maximum certificate lifetime | Domain validation reused for up to |
|---|---|---|
| Before 15 March 2026 | 398 days | 398 days |
| 15 March 2026 (in effect now) | 200 days | 200 days |
| 15 March 2027 | 100 days | 100 days |
| 15 March 2029 | 47 days | 10 days |
These rules apply to publicly trusted TLS certificates, the ones browsers accept. Certificates from your own private certificate authority, for internal systems, aren't affected.
Why lifetimes are shrinking
- Less damage from a stolen key. A leaked private key is useful to an attacker only until the certificate expires.
- Revocation doesn't work well enough. Browsers can't reliably check whether every certificate has been revoked, so expiry is the dependable safety net. Shorter lifetimes make it a tighter one.
- Fresher information. Domain ownership changes; frequent validation keeps certificates in step with who really controls a domain.
- Faster change. When the industry needs to replace an algorithm or an authority, short-lived certificates turn over in weeks, not years.
What it means in practice
At 47 days, each certificate needs replacing about eight times a year, and in practice more often, because renewal should happen well before the last day. Ten-day domain validation means even organisation-validated (OV and EV) certificates will need validation that runs automatically.
For a handful of certificates renewed by hand, that's a steady stream of chores; for dozens, it's an outage waiting to happen. The answer is the same for everyone: automate issuance, automate installation, and monitor the result.
The checklist
1. Build an inventory of every certificate
You can't automate what you don't know about. List every certificate your organisation depends on, including the ones that aren't on a web server:
- Websites and every subdomain
- APIs and webhooks
- Load balancers, CDNs and reverse proxies
- Mail servers (SMTP, IMAP), VPNs and remote-access gateways
- Appliances, firewalls and anything on a non-standard port
Tip: public Certificate Transparency logs record every public certificate issued. Searching your domain at crt.sh lists certificates issued for it, a quick way to find forgotten subdomains and certificates other teams requested.
2. Note how each one is renewed today
For each certificate, record who issues it and how it gets renewed: fully automatic (ACME, a cloud provider's managed certificates, your CDN), partly manual, or entirely manual. The manual ones are your to-do list.
3. Switch to automated issuance with ACME
ACME is the standard protocol for requesting and renewing certificates automatically. It's free with Let's Encrypt, and most commercial certificate authorities offer ACME too, including for OV certificates.
Common ACME clients:
| Where the certificate lives | Client to look at |
|---|---|
| Linux web server (Nginx, Apache) | Certbot, acme.sh |
| Web server that manages its own certificates | Caddy (built in), Traefik |
| Kubernetes | cert-manager |
| Windows / IIS | win-acme |
Managed platforms (AWS Certificate Manager, Cloudflare, most hosting providers) renew automatically, but only while their validation still works. Check that the DNS records or settings they rely on are still in place.
4. Renew early, not on the last day
Schedule renewal when about a third of the lifetime remains. Certbot, for example, renews 90-day certificates when 30 days are left. That leaves time for retries and for someone to notice if renewal keeps failing.
Better still, use an ACME client that supports ACME Renewal Information (ARI), a newer standard that lets the certificate authority tell your client when to renew, including early if a certificate has to be replaced.
5. Make installation part of renewal
A new certificate on disk changes nothing until the server loads it. Make reloading part of the renewal itself, for example with a Certbot deploy hook:
sudo certbot renew --deploy-hook "systemctl reload nginx"
If the same certificate is used on several servers, or on a load balancer or appliance, automate copying it there too, usually through the device's API.
6. Use DNS validation for wildcards and internal hosts
Wildcard certificates and hosts that aren't reachable from the internet need DNS-based validation (the ACME dns-01 challenge), which needs API access to your DNS.
To avoid giving every server full control of your DNS, delegate just the validation record: point _acme-challenge.example.com with a CNAME at a separate zone that only your ACME client can update.
7. Plan for the hard cases
Some certificates can't simply be automated. Find them now, while you have time:
- Appliances and older software without ACME support: check for firmware updates or vendor APIs, or put an automated proxy in front.
- Certificate pinning in mobile apps or devices: pinned certificates break when they change every few weeks. Pin to the certificate authority's key, or stop pinning.
- Certificates uploaded by hand to third-party services: look for an API, or move the endpoint behind infrastructure you control.
8. Test renewals before you rely on them
Run your renewal end to end without waiting for the real date. With Certbot:
sudo certbot renew --dry-run
This uses Let's Encrypt's test environment, so it doesn't count against rate limits. Repeat it after server, DNS or firewall changes; these are what usually break renewals.
9. Monitor certificates from the outside
Automation reports that it ran; it can't tell you whether visitors are actually getting the new certificate. A renewal can succeed while the server still serves the old certificate, or a load balancer still holds last month's.
An outside check looks at what your sites really serve and warns you while there's still time to act. With 47-day certificates, the margin for a missed renewal shrinks to days, so this becomes the safety net for everything above.
10. Repeat the inventory regularly
New subdomains and services appear all the time. Re-run step 1 every quarter, or let monitoring do it continuously: add each new hostname to your monitoring as it goes live.
What to do by when
| By | Goal |
|---|---|
| Now (200-day maximum) | Inventory done; every manual renewal identified; monitoring in place |
| 15 March 2027 (100 days) | Most certificates on ACME or managed renewal; installation automated |
| 15 March 2029 (47 days) | No manual renewals left; domain validation automated; hard cases solved |
Key takeaways
- Maximum certificate lifetime: 200 days now, 100 days from March 2027, 47 days from March 2029.
- Domain validation will need repeating every 10 days by 2029, so it must be automated too.
- Inventory, automate with ACME, automate installation, test, and monitor. In that order.
- The certificates most likely to cause an outage are the ones nobody knew about.
CertHalo does step 9 for you: it checks your certificates on a schedule and emails you before they expire, and the moment one changes, stops matching its name or is revoked. Monitor 3 certificates free, or run a one-off check with the free SSL checker.