Why SSL Certificates Are Expiring Faster (And Why Yours Shouldn't Be Your Problem)

Almost exactly a year ago, Let's Encrypt quietly switched off the emails that used to warn you when your website's security certificate was about to expire. No more "your certificate expires in twenty days" reminder landing in your inbox. For most site owners nothing changed, because the renewal happens automatically and they never read those emails anyway. For a smaller group still renewing certificates by hand, a safety net had just disappeared.

That decision was a signal of where the whole industry is heading. The certificate that secures your website, the thing that puts the padlock in the browser and the "s" in "https", used to last over a year. By 2029 it will last 47 days. The change is already underway, and the first step lands in a few months.

This is a reference piece on what is actually changing, when, and what it means for a business website. I run operations for a hosting platform, so I will be direct about the part most coverage skips. Whether this is a problem for you comes down to one thing, and it is not the certificate. It is whether your renewal is automated.

What changed: the industry put certificates on a shrinking clock

In April 2025 the CA/Browser Forum passed Ballot SC-081v3 ^[1]. That body is where the certificate authorities, the organisations that issue certificates, and the browser makers, Apple, Google, Mozilla and Microsoft, agree the rules that decide which certificates a browser will trust. The vote was 29 in favour, none against, with five authorities abstaining. When the people who issue the certificates and the people who build the browsers that trust them agree unanimously, it is not a proposal. It is the roadmap.

The decision sets a phased schedule that cuts the maximum life of a TLS certificate, the technical name for what most people call an SSL certificate, from today's ceiling of 398 days down to 47 days. It happens in three steps, spread over several years, so nobody has to change everything at once.

Here is the timeline that matters for planning.

Effective date	Maximum certificate validity	Roughly how often you renew
Now (since 2020)	398 days	About once a year
15 March 2026	200 days	About twice a year
15 March 2027	100 days	Every three months or so
15 March 2029	47 days	Roughly monthly

Take those rows one at a time, because each is a real change of pace.

The 398-day ceiling has been in place since 2020, when the browser makers last cut it. At that length a certificate is, in practice, an annual job. That is precisely why it gets forgotten: a task you do once a year never builds a habit.

From 15 March 2026 the maximum falls to 200 days. If you renew at the deadline you are now doing it about twice a year. For anyone managing certificates by hand, the annual reminder has just become a twice-yearly one, and the cost of missing it has not changed.

A year later, on 15 March 2027, the ceiling drops again to 100 days, which means renewing roughly every three months. At that cadence, manual renewal stops being an occasional chore and becomes a standing commitment somebody has to actually own.

The final step, on 15 March 2029, takes the maximum to 47 days, with renewal landing roughly monthly. The same ballot also cuts how long a certificate authority can reuse your domain validation to just 10 days ^[1], so you cannot pre-arrange everything far in advance. The control checks happen close to each issuance, every time.

One honest caveat on those numbers. They are ceilings, not targets. A sensible automated system renews well before the deadline to leave a buffer, so the real-world rhythm is tighter than the table suggests. Treat "roughly monthly" as the comfortable side of what 47 days actually demands.

Why shorter certificates are actually safer

This is not change for its own sake. A certificate is a signed statement that says, in effect, "this really is their website, trust it for the next X days." The problem is what happens if the private key behind it is stolen or the certificate was issued in error. That statement keeps vouching for whoever holds it until it expires.

In theory there is a fix called revocation, a way to cancel a bad certificate early. In practice it has never worked reliably, because browsers often do not check revocation lists, or fail open when they cannot reach them. So the genuinely dependable limit on a compromised certificate is not revocation. It is the expiry date.

Shorter lifetimes shrink that window of exposure. Let's Encrypt issued its first six-day certificate in February 2025 for exactly this reason ^[3]: a stolen six-day certificate is close to worthless before anyone can use it at scale. For a business owner the practical upshot is reassuring, with one condition attached. There is less to fear if a certificate is ever compromised, but only if a machine is doing the renewing. Re-issuing a certificate every six days by hand is not a security policy. It is a part-time job nobody applied for.

What an expired certificate actually does to your website

When a certificate lapses, the browser does not show a small warning in the corner. It throws a full-page block in front of your site: "Your connection is not private", or "Warning: Potential Security Risk Ahead". A visitor cannot reach your homepage, your prices or your checkout without clicking through a screen that looks, to a normal person, exactly like the warning you get before a scam site.

Most people do not click through. They leave. Your site has not gone down in the technical sense, the server is still answering, but it has gone invisible, which for a customer is worse, because it looks broken and untrustworthy in the same instant.

Picture a Kilkenny craft brewery selling online on the first cold Friday of the season, the certificate having quietly expired in the early hours. Every customer who clicks through from the newsletter hits a red security warning instead of the checkout, and by the time anyone spots it on Monday morning, the weekend's orders are simply gone. No alert fired. No page errored. The site just sat there, fully functional and completely untrusted, for three days.

Which sites feel an expired certificate most

• Online shops. A security warning standing between a customer and the checkout is lost revenue, immediately, and the busier the trading day the bigger the hole it punches.
• Service businesses taking enquiries. Your contact or booking form sits behind the same full-page block, so the leads you paid to attract bounce before they ever reach you.
• Anyone running paid ads. You are buying clicks that now land on a browser warning, which means spending money to show prospective customers a broken padlock.

The real dividing line: automated renewal or the manual scramble

Here is what the "47 days" headline obscures. A large part of the web already lives in the short-lived world, and nothing breaks. Let's Encrypt certificates have lasted 90 days for years, and they are designed to renew automatically about every 60 days through a protocol called ACME, with no person involved. Sites running on free, automatically issued SSL certificates have been quietly renewing six or so times a year, untouched by human hands, the entire time. For them, 200 days or 47 makes no practical difference at all. The renewal was never on anyone's to-do list to begin with.

The businesses that will feel March 2026 and everything after it are the ones still treating a certificate as an annual purchase. Buy a one-year certificate, install it by hand, set a calendar reminder, repeat. That model is already creaking. At twice a year it gets irritating. At monthly it collapses, because the failure mode of manual renewal is simply forgetting, and forgetting scales badly when the deadline comes round every few weeks instead of every twelve months.

The failure I have learned to respect is not the dramatic one. A renewal job runs, a domain-validation step fails quietly because of a stale DNS record, and the certificate does not actually renew. Nothing alerts anyone, because as far as the scheduler is concerned the job "ran". The site is fine right up until the morning the old certificate expires, and then it is very much not fine. We monitor the outcome now, not just the job, because a renewal process you never verify is a renewal process you do not really have.

For a business owner the goal is to never think about any of this. A certificate should be provisioned the moment your site goes into production and renewed long before it expires, by the platform, as a background fact of hosting rather than a recurring task. That is what managed Irish infrastructure that issues and renews your certificate automatically is for. The certificate lifecycle becomes someone else's monitored process, and your only involvement is not having to be involved.

To be fair, you do not need a managed host to solve this. If you run your own servers with a properly configured ACME client, and, crucially, with monitoring that tells you when a renewal fails rather than only when it runs, you are already equipped for the 47-day world, and this whole change is a non-event for you. Plenty of capable operators are in exactly that position. But that is a setup with someone watching it, not a one-year certificate and a note in a calendar, and it is not where most independent businesses are or were ever meant to be.

Where automation still needs a human

Automated renewal is not magic, and treating it as magic sets you up for the one morning it is not. The honest limitations are worth knowing.

ACME renewal depends on the certificate authority being able to confirm you still control your domain. So if your DNS provider has an outage, or someone edits a DNS record, or a CAA record (a small DNS setting that lists which authorities are allowed to issue certificates for your domain) is misconfigured, the renewal can fail. There are also rate limits: request too many certificates too quickly and the authority makes you wait.

And a certificate only proves your site is who it claims to be. It does nothing for a site that is slow, hacked, or simply offline. SSL is one layer, and it belongs inside a wider WordPress security and backup routine rather than standing in for the whole of it.

Whether renewals are genuinely monitored, as opposed to merely scheduled, depends on your hosting provider, so do not assume it. Ask the question in plain words: "Do you renew my certificate automatically, and what happens if a renewal fails?" The shape of the answer tells you most of what you need to know.

Three checks that tell you your SSL is handled

You do not need to understand ACME to know whether you are exposed. Three checks will do it.

1. Verify the padlock and the dates. Click the padlock next to your address in the browser and look at the certificate's expiry date. If it is only weeks or a couple of months out and you never set that up, something is renewing it for you, which is what you want.
2. Confirm who owns the renewal. Ask your host, or whoever built the site, in plain language, whether certificate renewal is automatic and monitored. "It just works" is not the same answer as "we watch it, and we are alerted if it fails."
3. Check you would find out before your customers do. Make sure a failed or expiring certificate raises an alert to a real person, because the worst possible way to learn your certificate lapsed is a phone call from a customer staring at a security warning.

Conclusion

The certificate change is real, it is phased, and the first step lands in March 2026. But the schedule itself is not the story. The story is that the industry has decided certificates should renew often enough that no person can sensibly keep up by hand, which leaves automation that somebody actively watches as the only durable answer.

If your renewals already happen in the background, and a real person is alerted when one fails, the move to 200 days, then 100, then 47, will pass you by entirely. That is exactly how good infrastructure is supposed to behave: quietly, and without your attention. If you are still renewing a certificate from a calendar reminder, the next few years are a fair prompt to change that, on your own terms and well before a deadline forces the issue.

Either way, the question worth asking this week is a short one. If your certificate failed to renew tomorrow, who would know, and how soon?

Frequently Asked Questions

Do I need to manually renew my website's SSL certificate?

On most modern managed hosting, no. Certificates from Let's Encrypt and similar authorities are issued and renewed automatically through a protocol called ACME, normally well before they expire. You only manage renewals by hand if you bought a commercial certificate and installed it yourself, or your host does not automate the process. If you are unsure, ask your provider directly whether renewal is automatic and monitored.

When do the shorter SSL certificate rules take effect?

The CA/Browser Forum's phased schedule reduces the maximum certificate lifetime from 398 days to 200 days on 15 March 2026, to 100 days on 15 March 2027, and to 47 days on 15 March 2029. These are maximums rather than targets. In practice, automated systems renew earlier than the deadline to leave a safety buffer, so the real renewal cadence is tighter than the headline number.

What happens if my SSL certificate expires?

Browsers replace your website with a full-page security warning, such as "Your connection is not private", and most visitors leave rather than click through it. The site is still technically running, but it is effectively unreachable and looks untrustworthy at the same time. For an online shop or a site with enquiry forms, that means lost sales and lost leads for as long as the certificate stays expired.

Are free SSL certificates affected differently from paid ones?

The maximum-lifetime rules apply to all publicly trusted certificates, free or paid. In practice, free certificates from Let's Encrypt already last 90 days and renew automatically, so they are built for short lifetimes and the new schedule barely touches them. Many paid annual certificates assume manual installation, which is exactly the model the new rules make hardest to sustain.

Does a shorter certificate actually make my website more secure?

Indirectly, yes. A shorter lifetime limits how long a stolen or wrongly issued certificate can be abused before it expires, which matters because the older mechanism for cancelling bad certificates early has never worked reliably across browsers. The trade-off is more frequent renewals, which is only safe if the process is automated and someone is alerted when a renewal fails.

How do I check who is responsible for renewing my certificate?

Ask your hosting provider, or whoever built your site, directly: is certificate renewal automatic, and is a person alerted if a renewal fails? You can also click the padlock in your browser to see the current certificate's expiry date. If renewal is genuinely managed for you, the expiry date should never be something you have to track yourself.

Sources