What an SSL certificate actually does

An SSL certificate does two jobs, and only two. It proves that the server answering for your domain name is genuinely allowed to answer for it, and it lets the browser and the server agree on a secret key so that everything passing between them is encrypted. That is the whole product. When the certificate lapses, both jobs stop at once, and every visitor gets a full page warning instead of your website.

That warning is the part worth understanding, because it is not a small red icon tucked in the corner. It is an interstitial that covers the page, and a customer has to deliberately click through two levels of “this site may be unsafe” to reach you. Most people do not. They close the tab.

What the padlock is really telling you

The padlock has been badly explained for twenty years, usually as “this site is secure”, which it does not mean.

A certificate is a signed statement from a certificate authority that says: the holder of this file demonstrated control of this domain name. That is it. It says nothing about whether the business is legitimate, whether the site is well built, or whether the forms on it are safe. A scam site can hold a perfectly valid certificate, and plenty do.

What the padlock genuinely guarantees is the second job: the connection is encrypted. Nobody sitting between the visitor and your server, on a cafe network, on a hotel router, at an internet provider, can read the enquiry form your customer just filled in, or alter the page on its way through. Before HTTPS was normal, injecting advertising into other people’s web pages in transit was a real business model.

The two parts people confuse

SSL and TLS. SSL is the old name for the protocol and it has been deprecated for years. The current protocol is TLS. Everyone still says “SSL certificate” out of habit, including us, and the certificate file is the same thing either way.

The certificate and the configuration. A valid certificate on a badly configured server still produces browser warnings: wrong domain name on the certificate, a missing intermediate certificate in the chain, or the certificate covering example.com but not www.example.com. These are separate failures from expiry and they look identical to a visitor.

What actually happens when it lapses

There is no grace period. A certificate carries a hard expiry timestamp, and at the moment it passes, browsers stop trusting it.

The visible result is the browser interstitial, on every page, for every visitor. Behind that, several things break quietly at the same time:

• Forms and checkouts stop. Anything posting to your domain over HTTPS fails or is blocked.
• Search crawlers back off. Google announced in August 2014 that HTTPS is a ranking signal, describing it then as a very lightweight one, but the bigger problem is that a crawler hitting a certificate error is not indexing anything new that day.
• Integrations fail silently. Payment gateways, booking widgets, mail providers verifying your domain, anything calling your site over an API. Machines do not click through a warning. They just stop, often without telling anyone.
• Email about the site gets flagged. Links in your campaigns and your transactional mail now point at a warning page.

If your site is behind a content delivery network or a proxy, the failure can be stranger still. The edge may hold a valid certificate while the certificate on your origin server has expired, which produces intermittent errors that are miserable to diagnose from the outside.

Why certificates expire so fast now, and why that is fine

Certificates used to last two or three years. They do not any more, and the direction of travel is aggressive.

Let’s Encrypt, which issues the certificate behind a very large share of the web at no cost, states plainly in its FAQ that its default certificates are valid for 90 days, that it also offers six day certificates, and that there is no way to adjust these lifetimes and no exceptions.

The wider industry is following. In April 2025 the CA/Browser Forum, the body where certificate authorities and browser makers set the rules, passed Ballot SC-081v3, which schedules a reduction in the maximum certificate validity period from 398 days down to 47 days, starting in March 2026 and concluding in March 2029. It passed with no votes against, and all four major browser makers voted in favour.

The logic is sound. A short certificate limits the damage if a private key is stolen, and it forces renewal to be automated, because no human is going to do it every six weeks by hand.

The practical consequence for you is simple and it is the point of this whole article: manual certificate renewal is finished. If a person has to remember, it will eventually be missed, and the window in which it gets missed is getting shorter every year.

The renewal failures we actually see

Automated renewal is the answer, but automation fails in specific, repeatable ways. In rough order of how often they bite:

1. Renewal was automated for the old setup. The site moved host, changed proxy, or gained a new subdomain, and the renewal job was never updated. It keeps running and keeps failing.
2. The validation path got blocked. Most automated renewal proves domain control by serving a file at a path under /.well-known/. A new firewall rule, a redirect-everything rule, or a security plugin that blocks unknown paths quietly kills renewal months before the certificate expires.
3. Renewal succeeded, reload did not. The new certificate is sitting on disk while the web server carries on presenting the old one, because nothing told it to reload.
4. Only the bare domain was covered. Renewal works perfectly for yourbusiness.com.au and nobody notices www.yourbusiness.com.au was dropped until a customer types it.
5. Expiry notices went to an address nobody reads. The warning emails go to whoever registered the certificate, often a developer who stopped working on the site two years ago.

Every one of these is invisible from the outside until the day it is not. That is why the fix is monitoring rather than diligence.

How to check, and what “good” looks like

Run your domain through the SSL Checker and look for four things:

• Days remaining. If it is under 15 on a 90 day certificate, renewal has probably already failed once.
• The names on the certificate. Both the bare domain and the www version should be listed, plus any subdomain you actually use, such as a booking or shop subdomain.
• A complete chain. The certificate should link back to a trusted root. Browsers on desktop often paper over a missing intermediate certificate; older phones do not, which is how you get the report that “it only breaks on her iPhone”.
• The issuer and the issue date. If the issue date has not moved in six months on a 90 day certificate, something is wrong with your assumptions about what is renewing it.

Then check the redirect: typing the plain http:// address should land you on the https:// version of the same page, once, with no chain of hops in between.

Where this fits

Certificates are maintenance, not a project. They renew on a schedule, they fail on a schedule, and the only durable answer is that renewal is automated, monitored, and alerts a person who is still employed when it breaks. That is part of what our hosting and care work covers, and it is genuinely the least interesting thing we do, which is exactly the point. Nobody should be thinking about a certificate until the week they have to.

If you are not sure who renews yours, check it today. The answer “I assume the host does it” is the one that costs a weekend.