When an SSL Certificate Expires Mid-Season: Why Renewal Stopped Being a Yearly Job

Here is a scenario. It is a composite, drawn from real cases rather than one named business, but every part of it is happening somewhere on the Irish web this week.

A gift shop in Killarney, deep into the tourist season. The website takes online orders for the pieces visitors spot in the window and want posted home. One morning the owner gets a text from a regular: "Is your site down? It says it is not safe." She opens it on her own phone, and there it is. A full red screen. The browser refusing to load the page. A warning that attackers might be trying to steal her customers' information. The site itself is fine. The shop is fine. The padlock simply lapsed overnight, and the certificate that proves the connection is encrypted had quietly expired. By the time anyone noticed, a morning's worth of would-be buyers had taken one look at that warning and gone elsewhere. Revenue gone before she even knew there was a problem.

Nobody had done anything wrong, exactly. The certificate had been set up a couple of years earlier and renewed once, by hand, by someone who no longer looked after the site. The reminder went to an inbox nobody checks. Then came the scramble that always follows: a frantic hour working out who actually controlled the certificate, whether it lived with the old developer, the domain registrar, or the host, and how to get a fresh one issued before the next coachload of visitors went looking online. None of it was hard work. All of it was happening during the busiest fortnight of her year, which is precisely when nobody has a spare hour.

I have made a version of this mistake myself. Years ago I trusted a calendar reminder to renew a certificate on a server I managed. The reminder fired on a morning I was firefighting something unrelated, I waved it away, and the certificate lapsed for a few hours before a customer flagged it. Not my finest morning. I have not trusted a human to remember a renewal since.

The padlock you stopped thinking about is changing

For most business owners the SSL certificate, the thing that puts the little padlock in the address bar and the "s" in "https", has been a fit-and-forget affair. You got one when the site was built. It lasted about a year. Renewal was somebody's annual chore. That era is ending, and faster than most people realise.

In April 2025 the CA/Browser Forum, the industry body where browser makers and certificate authorities agree the rules everyone has to follow, voted to shorten how long a certificate is allowed to live. This is not a suggestion that vendors can ignore. Browsers enforce it directly. Here is the schedule they locked in.

From	Maximum certificate life	Renewals needed per year	What it means for you
Until March 2026	398 days	About 1	A yearly chore
15 March 2026	200 days	About 2	Twice a year
15 March 2027	100 days	Around 4	Every quarter
15 March 2029	47 days	Around 8	Almost monthly

Read down that last column. A certificate that used to outlive your annual accounts will, by 2029, expire roughly every six weeks. The 398-day window most sites still run on drops to 200 days next March, then to 100 days in 2027, and finally to 47 days in 2029. The reasoning behind it is sound. Shorter-lived certificates limit the damage if one is ever stolen or wrongly issued, and they push the whole web onto automation, which is where it needed to go anyway. But the practical effect for a non-technical owner is blunt. What was one chance a year to forget becomes eight.

Why "I will just renew it once a year" quietly became a trap

Here is the consequence in plain terms. Every renewal is a deadline. Miss it and you do not get a soft warning that fades after a day. You get the screen from that opening scene: a hard block that every modern browser throws the instant a certificate expires, telling your customers your site may be dangerous. Working HTTPS has been a baseline expectation for years, to the point where Google's own Search Central guidance lists it as a ranking signal. So a lapsed certificate can cost you on search as well as at the till.

It is also harder to wave away than it used to be. A few years ago a visitor could click past a certificate warning in a couple of taps. Browsers have steadily tightened that path since, and for an ordinary customer on a phone the expired-certificate page now reads as a dead end rather than a "proceed anyway" prompt. Most people will not push through it, and frankly they are right not to. They will just leave, and you will never see the visit in your figures, because the visit never really happened.

Now stretch that across the new schedule. One missed renewal a year is a risk a busy owner can usually dodge. Eight a year, landing on random weekdays while you are serving customers, filing your VAT, or away for a week, is a different proposition entirely. The arithmetic is not on the side of the person with the calendar reminder. It never really was. The shortening schedule simply removes the last bit of slack that let manual renewal limp along this far.

And the failure is always public. A broken plugin you can fix quietly before most people notice. An expired certificate announces itself to every single visitor at once, in alarming red, at the worst possible moment, which is usually whenever you are busiest and least able to deal with it.

What a proper setup looks like

Strip away the jargon and the answer is simple. Certificate renewal should be something no human ever has to remember. A well-run platform issues the certificate automatically when a site is deployed, renews it well before it expires, swaps in the new one without taking the site down, and monitors the whole cycle so that if anything does go wrong, the operations team knows before any customer does. No diary entry. No inbox nobody reads. No single morning where everything hinges on someone waving away the right reminder.

The monitoring part matters more than it sounds. Automation that nobody is watching is just a different way to fail silently. A proper setup checks that each renewal actually succeeded and raises an alert if one did not, so a rare hiccup gets caught and fixed by someone whose job that is, hours or days before a certificate would have lapsed. The owner hears about it only if there is something genuinely worth hearing about, which on a well-run platform is almost never.

This is exactly what Let's Encrypt, the non-profit certificate authority that now secures a large share of the web, was built to do. Its certificates last 90 days by design, precisely because short lifespans force everyone to automate rather than rely on memory. The technology to make certificate expiry a non-event has existed for years. The only real question is whether your hosting uses it on your behalf, or quietly leaves the job to you.

How this should feel for the owner: like nothing at all

This is the part of the job a managed platform should simply absorb. On Web60, SSL is provisioned automatically the moment a site is created, and renewed automatically for as long as the site is live, using Let's Encrypt, included in the flat €60 a year alongside everything else. When the maximum certificate life drops to 200 days next March, then to 100, then to 47, nothing changes for the owner. The renewals just happen, more often, in the background, on the kind of managed infrastructure that handles certificate renewal so you never have to think about it.

Reviewing our renewal logs this morning, every certificate due to roll over in the next fortnight had already done so on its own, with nobody touching anything. That is how it is meant to work. Invisibly. In practice it means the gift shop owner never sees the red screen, never loses a morning's orders to a lapsed padlock, and never has to understand a single word of what I have just written.

A certificate is one lock on one door

It is worth being clear about what a certificate does and does not do, because plenty of owners assume the padlock means "safe". It does not. It means the connection between your customer's browser and your site is encrypted, so nobody can snoop on it in transit. That is necessary and non-negotiable. It is also not the same thing as a secure website. A site with a perfectly valid certificate can still be broken into through an out-of-date plugin or a weak password, which is why a valid certificate is necessary but nowhere near sufficient on its own. If you want to see how the pieces fit together, our complete WordPress security and backup guide for Irish websites walks through the full set. Treat the certificate as the lock on the front door: essential, but not the only thing standing between you and trouble.

The one thing automation cannot do for you

Automatic renewal is not magic, and it is only fair to be honest about where it can still trip. A certificate can only be renewed if the certificate authority can confirm you still control the domain, and that check runs through your domain's DNS pointing at your host. If you move your domain to a different provider, let the domain registration itself lapse, or change DNS records without realising what they do, an automated renewal can fail even on a well-run platform. The fix is not complicated, but it does mean two things are worth keeping straight. Keep your domain registration paid up. And if you ever move hosts, confirm the new one re-issues the certificate as part of the migration rather than assuming it carries across. Where your host automates renewal, your only real job is to avoid pulling the rug out from under it.

When doing it yourself genuinely makes sense

I will give the other side its due, because the case is real. If you run your own servers with a dedicated operations or security team, manual and enterprise-grade certificate management earns its place. Large organisations under strict compliance regimes sometimes need extended-validation certificates that display the registered company name in the details, or run internal certificate authorities for systems that never touch the public web, and there are specialist certificate-lifecycle platforms built precisely for managing thousands of certificates across a sprawling estate. That work is genuine, and the tooling for it is good. But that is a finance firm with a security department, not the owner-operator selling craft online. For most local businesses, the right number of certificates to manage by hand is zero.

The takeaway

The web is quietly moving certificate renewal out of the realm of things a person can sensibly stay on top of. A once-a-year chore was forgettable but survivable. A roughly-every-six-weeks chore, by 2029, is not something any busy owner should be running from a calendar reminder, and the businesses that get caught out will mostly be the ones who never knew the rules had changed.

The reassuring part is that this is one of the few website problems with a genuinely clean answer. Certificate renewal is now an operations job, and operations jobs belong with whoever runs your infrastructure, not in your inbox. So the useful thing to do today is decide who owns that renewal cycle for your site. If the honest answer is "nobody, really", that is the thing worth sorting well before next March, while it is still cheap and quiet to fix.

Sources

• CA/Browser Forum, Ballot SC-081v3: the agreed schedule for reducing certificate validity periods
• Let's Encrypt: why ninety-day certificate lifetimes exist, and why they depend on automation
• Google Search Central: HTTPS as a ranking signal