47-day SSL certificates: what changes and how to prepare
Public TLS certificates are getting much shorter lives: 200 days now, 100 days from March 2027 and 47 days from March 2029. Here’s the schedule, what it means for your team, and how to make it a non-event.
The schedule
In April 2025 the CA/Browser Forum, where certificate authorities and browser makers set the rules for publicly trusted certificates, passed Ballot SC-081. It shortens the longest a TLS certificate may be valid in three steps:
| Certificates issued from | Longest validity |
|---|---|
| before 15 March 2026 | 398 days |
| 15 March 2026 (in force now) | 200 days |
| 15 March 2027 | 100 days |
| 15 March 2029 | 47 days |
How long a CA may reuse a past domain validation shrinks on the same dates, down to just 10 days in 2029. In practice, almost every renewal will have to prove domain control again.
What changes for you
- Renewals become constant. At 47 days, each certificate renews about eight times a year. A team with 100 certificates would handle around 800 renewals a year.
- Validation has to be automated too. With validation reuse at 10 days, “we validated the domain last month” no longer helps. DNS records or HTTP challenges have to be answered automatically each time.
- Installing is the real work. Getting a certificate issued is easy; getting it into every web server, load balancer, Windows store, PFX folder and appliance on time is where outages come from.
- You need to know what you have. Certificates nobody remembers, on servers nobody owns, are the ones that expire.
This isn’t only about free certificates: the limits apply to every publicly trusted TLS certificate, paid ones included. A “one-year certificate” you buy becomes a subscription you reissue during the year.
A checklist
- Find every certificate you depend on, including on Windows servers and appliances.
- Automate validation for each domain: a DNS provider API, a CNAME record pointing to a validation service, or an HTTP redirect.
- Automate installation everywhere a certificate lives, and check afterwards that the new certificate is actually being served.
- Get alerts that matter: failures and certificates close to expiry, not routine success.
- Don’t depend on one certificate authority. A backup CA keeps renewals going if your main CA has an outage or rate-limits you.
- Use ACME Renewal Information (ARI) where your CA offers it, so renewals happen when the CA suggests, including early during a mass revocation.
How EverTLS handles it
EverTLS was built for short lifetimes. It renews on the CA’s recommended schedule (ARI where available), validates with DNS APIs, CNAME delegation or HTTP redirects every time, installs with agents on Linux (nginx, Apache, HAProxy) and Windows (IIS, the certificate store, PFX files and IIS Centralized Certificate Store), verifies what’s served, and falls back to a backup CA such as Google Trust Services or ZeroSSL when the main one fails. Whether certificates last 200 days or 47, there’s nothing to change on your side.
Is there any way to keep longer certificates?
Not for publicly trusted certificates: every public CA follows these rules. For internal systems that only your own devices need to trust, a private CA (Active Directory Certificate Services, step-ca, HashiCorp Vault) can issue longer certificates; EverTLS can manage those too through any ACME-compatible private CA.