SSL Certificates: Expiry, Chains and the Errors That Cost You Traffic

An expired certificate does not degrade a site. It takes it fully offline behind a full-page browser warning that most visitors will not click through, and that search crawlers treat as unreachable.

Revenue goes to zero, not down. And it happens to well-run companies constantly, because the failure mode is silent right up until it is total.

Here is what goes wrong and how to catch it first.

Expiry: the automation that stops quietly

Let's Encrypt certificates last 90 days and are designed to renew automatically at day 60. Automation removes the risk entirely — until the renewal cron fails and nobody notices for a month.

Renewal breaks for boring reasons: a firewall rule blocks the validation request, the webroot moved during a deployment, a DNS provider's API token expired, disk filled up, the certbot package broke on an OS upgrade. None of these announce themselves. The certificate simply stops renewing, and thirty days later the site is behind a warning.

The rule that actually protects you: monitor the certificate's expiry date independently of the renewal process. If your alerting is "did certbot succeed", you are trusting the thing that is failing. If it is "is the live certificate expiring within 14 days", you catch every failure mode including the ones you did not anticipate.

Set that alert at 14 days. A 90-day certificate that should have renewed at day 60 and has 14 days left is unambiguously broken, with two weeks to fix it calmly.

Hostname coverage: the www problem

A certificate covers specific names, listed in its Subject Alternative Name field. A certificate for example.com does not cover www.example.com unless www is explicitly listed.

This is the failure you never see yourself, because you always type the domain the same way. Meanwhile a share of your visitors — the ones who type www, or follow an old link that includes it — get a full security warning.

Check both. Every time.

Wildcards match exactly one label. *.example.com covers shop.example.com but not eu.shop.example.com. It also does not cover the bare example.com — that needs to be listed separately, which most issuers do automatically but not all.

Chain problems: fine on desktop, broken on mobile

Your certificate is signed by an intermediate certificate, which is signed by a root certificate the browser already trusts. Your server has to send the intermediate. The root is already in the trust store; the intermediate is not.

If your server sends only the leaf certificate, most desktop browsers paper over the gap by fetching the missing intermediate themselves. Many mobile browsers, API clients, older Android devices and command-line tools do not — and they see an untrusted certificate.

This is why a site can work perfectly on your laptop and fail on a customer's phone, and why "it works for me" is not a valid test for TLS. Always verify the full chain is being sent, not just whether your own browser shows a padlock.

Our free SSL checker reports the chain length alongside expiry and coverage, which is the specific thing a padlock icon cannot tell you.

TLS version

• TLS 1.3 — current. Completes the handshake in one round trip instead of two, which is a measurable speed improvement on every connection, not just a security one.
• TLS 1.2 — acceptable minimum.
• TLS 1.1 and 1.0 — deprecated, rejected by modern browsers, and a PCI compliance failure.

If your host still negotiates 1.0 or 1.1, that is a hosting configuration problem worth raising with them directly.

Free versus paid

For encryption, they are identical. Let's Encrypt uses the same algorithms, the same key sizes and gets the same browser treatment as a certificate costing several hundred euros a year.

What paid certificates add is organisational validation — the CA verified that your company exists and controls the domain, rather than just that you control the domain.

Browsers stopped displaying that distinction years ago. The green address bar with the company name is gone from Chrome, Firefox and Safari. A visitor cannot tell an EV certificate from a free one without opening the certificate details, which approximately nobody does.

So the honest position: use a free certificate unless a specific compliance requirement or contract names a certificate type. The money is better spent almost anywhere else.

The one genuine argument for paid is the warranty and support that comes with it, which matters for organisations that need someone contractually accountable. That is a procurement decision, not a security one.

Certificate lifetime is shrinking

Browsers now reject publicly-trusted certificates issued for more than 398 days, and the industry is moving toward much shorter lifetimes — proposals for 90 days and eventually 47 days as the maximum are advancing.

The practical consequence is that manual certificate management is ending. If your renewal process involves a human downloading a file and uploading it somewhere, that process will become unworkable within a couple of years. Automating it now, while you have time, is far cheaper than automating it during an outage.

Mixed content

A valid certificate does not guarantee a padlock. If an HTTPS page loads any resource over plain HTTP — an image, a script, a stylesheet, a font — browsers either block it or downgrade the security indicator.

Scripts and stylesheets are blocked outright, which usually breaks the page visibly. Images are typically allowed but remove the padlock.

The usual culprits after a migration to HTTPS are hard-coded http:// URLs in a database, in old blog posts, or in a third-party embed. Protocol-relative URLs (//example.com/x.js) work but are considered legacy; use explicit https://.

What to check, and how often

Monthly, automatically:

• Days until expiry, for the bare domain and for www
• Chain completeness
• TLS version negotiated

After any hosting or CDN change:

• All of the above, plus mixed content on key pages

Once, and then never think about it again:

• Set a CAA record naming the certificate authorities allowed to issue for your domain. Two minutes of work, and it means a CA that is not on your list cannot issue a certificate for you even if someone tricks it into trying.

That last one is covered in our DNS records guide and checkable with the DNS lookup tool.

The short version

Certificates fail in three ways: they expire, they cover the wrong hostname, or the chain is incomplete. The first is caught by monitoring the live certificate rather than the renewal job. The second is caught by checking www as well as the bare domain. The third is caught by testing from something other than your own desktop browser.

All three are cheap to check and expensive to discover from a customer.