Industry Update: SSL certificate lifetimes are changing. Learn how the move to 47-day certificates will impact businesses between 2026 and 2029.
Reading time: 6 minutes
Published by: Wikicert
Category: Cyber Stories
Topic: SSL Certificates, Website Security & Digital Trust
It arrived late on a Friday afternoon.
Nothing dramatic.
No ransomware warning.
No suspicious login.
No alert saying someone had attacked the company.
Just a routine message sitting in an inbox:
Your SSL certificate is about to expire.
Someone saw it.
Someone thought:
"I'll deal with that Monday."
And that was the mistake.
At 2:17 AM on Saturday morning, the website's certificate expired.
The website itself was still running.
The server was still running.
The database was still running.
The company's internet connection was fine.
But the certificate protecting the website was no longer valid.
For visitors, the experience was very different.
Instead of a familiar HTTPS connection, the browser displayed a security warning.
The website suddenly looked dangerous.
Even though nobody had hacked it.
This is one of the most misunderstood parts of SSL certificate problems.
An expired certificate doesn't necessarily mean an attacker has compromised the website.
It means the certificate can no longer be trusted as a valid credential for that connection.
Browsers and other clients can reject connections when certificates are expired or otherwise invalid.
For a customer arriving at an online store at 2 AM, however, the distinction doesn't really matter.
They see a warning.
They leave.
And some never come back.
Certificates are part of the trust and authentication mechanism behind secure connections, which is why certificate failures can affect both security and availability.
A customer had been trying to place an order.
They clicked the website.
The browser warned them that the connection wasn't private.
They closed the page.
Then they tried again.
Same warning.
They assumed something was wrong.
Maybe the website had been compromised.
Maybe the company couldn't be trusted.
Maybe they should buy somewhere else.
The customer never knew the real problem.
It wasn't the website's design.
It wasn't the payment system.
It wasn't the hosting provider.
It was a certificate that nobody had replaced in time.
By Saturday morning, customers were reporting problems.
The support team initially assumed it was a hosting issue.
The website was technically online.
That made the problem harder to understand.
There was no obvious server outage.
No broken homepage.
No database failure.
Just a growing number of people being warned away from the website.
Eventually someone checked the certificate.
The expiration date told the whole story.
The certificate had expired.
The solution itself wasn't particularly complicated.
A new certificate needed to be issued, validated and deployed.
But that process takes time.
The team had to determine:
Which certificate had expired?
Who managed it?
Which Certificate Authority issued it?
Was domain validation still available?
Who had access to the account?
Which server needed the new certificate?
Were intermediate certificates configured correctly?
Had the replacement certificate actually been deployed?
The problem wasn't simply getting another certificate.
The problem was everything surrounding the certificate lifecycle.
The company didn't have a certificate problem.
It had a certificate-management problem.
There was no reliable inventory.
There was no automated renewal.
There was no clear owner.
There was no effective alerting process.
And there was no one checking whether the renewal had successfully reached production.
That distinction matters.
Because automation doesn't eliminate every possible failure.
A renewal can fail.
Validation can fail.
DNS configuration can change.
Deployment can fail.
Servers can be misconfigured.
That's why certificate management needs both automation and monitoring.
The UK's National Cyber Security Centre recommends automated certificate provisioning and renewal because manual processes can allow certificates to expire through human error. It also recommends monitoring renewals so failures can be detected before expiration.
The old idea of installing an SSL certificate and forgetting about it is becoming increasingly outdated.
Public TLS certificate validity periods are getting shorter.
In 2026, the maximum permitted public TLS certificate validity moved from 398 days to 200 days under the CA/Browser Forum's schedule. Further reductions are planned, including 100 days in 2027 and 47 days in 2029.
That means certificate management is becoming more frequent.
More certificates.
Shorter lifetimes.
More renewals.
More opportunities for something to go wrong.
For businesses managing multiple websites, manually tracking every certificate becomes increasingly difficult.
Modern certificate-management systems can automate much of the renewal process.
Protocols such as ACME allow compatible systems to automate certificate issuance and renewal.
That means a certificate doesn't necessarily have to depend on someone remembering a date in a calendar.
But there's an important lesson here:
Automation should not mean "set it and forget it."
A good system should still provide visibility.
You should know:
What certificates you have
Where they're installed
When they expire
Whether renewal succeeded
Whether deployment succeeded
Who is responsible when something fails
That is certificate lifecycle management.
The company eventually restored the website.
The certificate was replaced.
The website returned to normal.
But the incident left behind a more important question:
Why did everyone know when the certificate expired, but nobody knew whether it had actually been renewed?
That question changed how the company managed its certificates.
They created an inventory.
They introduced automated renewal.
They added monitoring.
They assigned ownership.
And they began treating certificates as part of their website infrastructure rather than a one-time installation task.
If your business operates a website, ask yourself:
If the answer is no, start with visibility.
There should be a clear person or team responsible.
If not, determine whether your hosting and infrastructure support automation.
An automated renewal that silently fails isn't automation you can rely on.
There should be enough time to investigate and fix the problem before expiration.
Issuing a replacement certificate isn't the same as successfully deploying it.
SSL certificates are more than a padlock in a browser.
They are part of the digital trust layer of a website.
Wikicert helps businesses and agencies navigate that layer from choosing the appropriate SSL certificate and completing validation to managing renewals, deployment and ongoing certificate support.
For organisations managing multiple websites or client domains, the goal isn't simply to have a certificate.
The goal is to keep the certificate valid, trusted, visible and properly managed throughout its lifecycle.
The certificate expired.
But that wasn't really the story.
The real story was what happened around it.
Nobody intended to let the website's certificate expire.
Nobody ignored security deliberately.
Nobody caused an outage on purpose.
A simple process failed because it depended too heavily on someone remembering what needed to happen.
That's exactly why certificate automation, monitoring and lifecycle management matter.
Because the best time to discover that your SSL certificate is about to expire isn't when your customers are already looking at a browser warning.
It's long before that.
