47-day SSL certificates: what changes in 2026, 2027 and 2029

In April 2025 the CA/Browser Forum, the body of certificate authorities and browser makers that sets the rules for public TLS certificates, approved ballot SC-081. It cuts the maximum validity of a publicly trusted certificate in three steps, from 398 days to 47 days by 2029. Apple proposed it and no certificate authority voted against it.

The ballot also shortens how long a certificate authority may reuse an earlier domain validation. Today a CA can reuse proof that you control a domain for many months; by 2029 that proof is good for only 10 days, so nearly every renewal needs a fresh validation.

This step is already in effect. Any certificate a public CA issues today lasts at most 200 days, so a team that bought one-year certificates now renews twice a year. For most teams the visible change is the second renewal date, but it is also the first time a once-a-year manual process has to run twice.

Check what you have with the certificate lifetime readiness check: it shows a host's certificate against each upcoming limit.

From March 15, 2027 a certificate lasts at most 100 days, about four renewals a year. This is the point where manual renewal stops being practical for anything beyond a handful of hosts. Every certificate that is still renewed by hand, or by a script someone set up once and forgot, has to be found before then.

From March 15, 2029 the limit is 47 days. Teams that renew around two thirds of the way through a certificate's life will replace each one roughly every month. Because domain validation can only be reused for 10 days, the renewal also has to prove domain control again almost every time, through DNS or HTTP challenges your automation must be able to answer.

Manual tracking, such as a spreadsheet, a calendar reminder or a quarterly audit, worked when certificates lasted a year. It fails on short lifetimes for a simple reason: the reminder fires on every cycle, whether or not anything is wrong.

A "30 days before expiry" alert on a 47-day certificate fires 17 days after the certificate was issued, every single time. People learn to ignore it, and then the one renewal that really failed goes unnoticed. The useful question is not "how many days are left?" but "should this certificate have been replaced by now, and has it been?"

1. List every public certificate. Include load balancers, CDNs, mail servers and anything on a non-standard port. The bulk SSL expiry checker checks up to 20 hosts at once.
2. Automate issuance with ACME. Let's Encrypt, ZeroSSL, Google Trust Services and most commercial CAs support the ACME protocol, so tools such as certbot, acme.sh, cert-manager or your cloud provider can renew without a person. Let's Encrypt certificates already last 90 days.
3. Make sure renewals can validate. With 10-day validation reuse, DNS-01 or HTTP-01 challenges run on almost every renewal. Check that the automation has API access to your DNS provider, and that a CAA record does not block the CA you use (see the CAA checker).
4. Deploy, do not just issue. A renewed certificate sitting on disk does not help. Reload the web server, push to the load balancer and confirm the new certificate is the one served.
5. Alert on renewal failure. Watch each host for a new certificate once it passes its expected renewal point, with a final 7-day and 1-day safety net.