Skip to content
Guides

47-day SSL certificates: what changes and when

Public TLS certificates are getting shorter every year until 2029, when the longest one a CA may issue lasts 47 days. Anything renewed by hand stops being workable long before then. Here is the schedule, what tends to break, and how to find out about a failed renewal before your visitors do.

The dates

In April 2025 the CA/Browser Forum, the body of certificate authorities and browser makers that sets the rules for public certificates, passed ballot SC-081. It lowers the maximum validity of a publicly trusted TLS certificate in steps. Each limit applies to certificates issued on or after its date; a certificate issued the day before keeps its full lifetime.

Issued on or afterLongest allowed certificate
September 1, 2020398 days
March 15, 2026200 days
March 15, 2027100 days
March 15, 202947 days

The same ballot shortens how long a CA may reuse your domain validation: down to 10 days by 2029. In practice that means proving control of the domain almost every time you renew, which is easy for an automated client and tedious for a person.

If your certificates come from Let's Encrypt or another ACME CA, they are already 90 days or shorter, so the 200 and 100 day steps change nothing for you. The 47-day step does: renewal moves from roughly every 60 days to roughly every month, and every renewal is another chance for the automation to fail quietly.

What breaks

The failures follow a pattern. They are rarely the main website.

  • Manual renewals. A yearly calendar reminder becomes eight to twelve reminders a year, owned by whoever set it up. The first missed one is an outage.
  • Appliances and load balancers. Firewalls, VPN gateways, storage arrays and older load balancers often accept a certificate only through a web form. If the vendor ships no ACME client or API, someone pastes the file in by hand.
  • Copies of the certificate. The same certificate installed on a CDN, a mail server and an internal proxy gets renewed in one place and expires in the others.
  • ACME clients that stopped running. A cron job on a server that was rebuilt, a DNS API token that was rotated, a firewall rule that blocks the HTTP challenge. The client fails, logs it somewhere nobody reads, and the old certificate runs out a few weeks later.
  • Services that load the certificate once. The new file lands on disk but the process keeps serving the old one until it restarts.

Internal services that use a private CA are not covered by these rules. They often break anyway, because the same team and the same habits manage both.

How to get ready

  1. List every hostname that serves a public certificate, including the ones on appliances, mail servers and CDNs. Certificate Transparency logs show every certificate issued for your domain, which is a good way to find the ones nobody remembers.
  2. For each one, write down how it renews: an ACME client, a cloud provider's managed certificate, or a person. Anything renewed by a person needs a plan before March 2027, when the limit reaches 100 days.
  3. Move what you can to automatic renewal. Managed certificates from your CDN or cloud load balancer renew without you. Elsewhere, an ACME client with DNS validation works even for hosts that are not reachable from the internet.
  4. Make sure the service reloads after a renewal, and test that by renewing early once.

To see where one certificate stands today, run it through the SSL certificate checker. It shows the total lifetime, the issuer, whether it looks ACME-issued, and the first limit a certificate of that length would break.

How to catch a failed renewal

Automation removes the reminder, so you need a different signal: something outside the server that reads the certificate actually being served and warns you while there is still time. A renewal client checking its own work cannot see a stale copy on another machine or a process that never reloaded.

With a 47-day certificate renewed at about two thirds of its life, a healthy certificate never has fewer than about 15 days left. Fewer days than that means renewal has already failed at least once. That makes the remaining days a good alarm, and a better one than the expiry date itself.

Every HTTPS monitor on RealUptime Monitor reads the certificate the server presents and alerts you at 30, 14, 7 and 1 day before expiry, through the same channels as your other alerts. It is included on the free plan. For the stories of companies that learned this the hard way, see expired certificate outages and how to catch them.

Next

Uptime monitoring explained: what a green badge actually measures