Defaults.Exposed › Fixes › TLS certificate health

How to fix TLS certificate health

Your SSL/TLS certificate is the digital ID card that proves a visitor is really talking to your website — not an impostor — and powers the padlock in the browser. This check looks at whether that certificate is valid and trusted, not about to expire, and built with strong, modern cryptography.

Bottom line for your business: A broken or expired certificate replaces your website with a full-screen red 'Your connection is not private' warning in every browser. Most visitors leave instantly and don't come back — online sales stop, sign-ups stop, and the connection that was supposed to be private can be quietly intercepted.

What this can cost you

• Your certificate quietly expires over a weekend; by Monday every visitor hits a full-page security warning, your checkout and contact forms are dead, and you're losing sales for every hour it takes to notice and renew.
• A customer paying over café or hotel Wi-Fi gets a warning that your certificate doesn't match your domain — they assume your site is fake or hacked, abandon the purchase, and tell others it 'looked dodgy'.
• A larger client's IT team runs a pre-contract security scan, sees a self-signed or untrusted certificate, and flags you as a risk — the deal stalls over something that costs nothing to fix.
• Your certificate uses an outdated signing method or a weak key; modern browsers start showing warnings on it, and a security audit marks you down for cryptography that's been off the recommended list for years.
• You take card payments and your payment provider re-audits you; a weak key or an expired certificate breaks the payment-security rules and your online checkout is frozen until it's corrected.

Why it matters. The certificate is the single most visible piece of your website's security — when it's healthy it's invisible, and when it breaks it takes your whole site down with a frightening warning that drives customers straight to competitors. Certificate expiry is the number-one cause of unexpected website outages, and it's entirely preventable. Getting a valid certificate is free, and keeping it healthy is mostly a matter of letting it renew automatically.

What this is, in plain words

When someone visits your website, two things have to happen for them to feel safe typing in a password or a card number. First, the connection has to be encrypted so strangers can’t read it. Second — and this is the part people forget — the visitor’s browser has to be sure it’s really your website on the other end, and not an impostor that’s set up a convincing fake. The thing that does both jobs is your TLS certificate (often called an “SSL certificate”).

Think of it as a tamper-proof ID card for your domain. A recognised authority issues it, it’s stamped with your domain name and an expiry date, and it carries the cryptographic key that scrambles the connection. When everything checks out, the browser shows the padlock and your site loads normally. When something is wrong with the ID card, the browser does the opposite of reassuring your visitor — it throws up a full-screen warning that says, in effect, “this site may not be safe.”

This check looks at the health of that ID card across four things that each independently break it:

• Is it valid and trusted? — issued by a recognised authority, matching your exact domain, not self-signed, and not expired.
• Is it about to expire? — because a certificate that lapses takes your whole site down.
• Is it signed with a strong method? — old signing algorithms can be forged.
• Is its key strong enough? — a weak key can, in principle, be broken.

The good news up front: getting a healthy certificate is free, and keeping it healthy is mostly about letting it renew itself automatically so no human has to remember.

What this can cost you

• The weekend outage. A certificate quietly hits its expiry date late on a Friday. The renewal that was supposed to run didn’t (a server moved, a script broke, nobody noticed). By Saturday morning every visitor — and every Google crawler — sees a full-page red warning instead of your homepage. Your shop is shut and you don’t even know it. The technical fix takes minutes; the lost weekend of sales and the customers who decided you’d “gone out of business” don’t come back.

• The abandoned checkout. A customer is buying from their phone on hotel Wi-Fi. Your certificate doesn’t quite match the domain they typed (say it covers shop.yourbiz.com but not the bare yourbiz.com they used). The browser warns them the site “may be impersonating” yours. To a non-technical buyer that reads as scam — they close the tab, and you never know the sale existed.

• The stalled contract. A bigger prospect’s security team runs a routine scan before signing. It comes back showing a self-signed or untrusted certificate on one of your subdomains. Even if everything else is fine, that single red flag turns a quick approval into a back-and-forth that delays the deal — over a problem that costs nothing to fix.

• The slow-motion warning. Your certificate is technically valid but signed with SHA-1, an old method browsers have been phasing out. One browser update later, a share of your visitors start seeing warnings you can’t reproduce on your own up-to-date machine. Support tickets trickle in saying the site “looks broken” and you can’t work out why.

• The compliance fail. You take card payments. During a re-audit, your provider’s checks flag a weak key or a certificate that lapsed. Card-security rules require strong, current encryption — so your online payments get suspended until you reissue, freezing revenue at the worst possible moment.

What it actually is (the four parts)

A certificate can be unhealthy in four distinct ways, and this page covers all of them. Each is a separate check under the bonnet, but to you they’re all “is my certificate OK?“

1. Valid and trusted

This is the big one — and the only part of certificate health that’s a critical, top-weight check. A certificate is “valid and trusted” only when all of these are true:

• It was issued by a recognised certificate authority that browsers already trust (Let’s Encrypt, DigiCert, Sectigo, Google, Amazon, and so on).
• It matches the exact domain the visitor is using — including subdomains. A certificate for www.yourbiz.com that doesn’t also cover yourbiz.com will warn on the bare domain.
• It is not self-signed — i.e. not one you issued to yourself, which encrypts but proves nothing about who you are.
• It is currently within its date window — not expired, and not (oddly but it happens) dated to start in the future.
• Its chain of trust is intact — the authority that signed it is itself trusted, all the way up.

If any one of these fails, browsers show the dreaded “Your connection is not private” page, and this check fails hard. Good looks like: a certificate from a recognised authority, covering every domain and subdomain you actually use, comfortably inside its dates.

2. Not about to expire

Every certificate has a hard end date. Free ones typically last 90 days; paid ones often a year. Past the date, trust evaporates instantly — there’s no grace period. This check measures how many days are left and how that interacts with who issued it:

• If it’s already expired, or expires in under 7 days, that’s treated as critical — a sign renewal has failed.
• If it expires within 30 days and isn’t auto-managed, that’s a warning to renew now.
• If it’s from an auto-renewing provider (Let’s Encrypt, Cloudflare, Google, Amazon, ZeroSSL and similar) with at least a week left, it passes — because it’s expected to renew itself before the deadline.
• Plenty of runway (90+ days, or auto-managed) is a clean pass.

Good looks like: an auto-managed certificate that renews itself without anyone touching it. The single most reliable way to never have an expiry outage is to make a machine, not a person, responsible for renewal.

3. Strong signature algorithm

Every certificate is “signed” using a cryptographic algorithm that lets browsers detect tampering. Old algorithms — MD5 and SHA-1 — have been shown to be forgeable, meaning an attacker could in principle craft a fraudulent certificate that looks legitimately yours. This check passes when the certificate uses a strong, modern signature: SHA-256 or stronger (SHA-384, SHA-512), modern ECDSA, or Ed25519/Ed448. MD5 and SHA-1 fail. Good looks like: SHA-256 or better — which is the default on every free and modern certificate, so this is rarely a problem on anything issued in recent years.

4. Strong key

The certificate carries a cryptographic key that does the actual scrambling. If that key is too short, modern computing power can — given enough resources — break it, letting an attacker impersonate your site or decrypt traffic. The accepted minimums are 2048-bit RSA or 256-bit elliptic-curve (EC). This check passes at those sizes or above and fails below them. Good looks like: 2048-bit (or 4096-bit) RSA, or a 256-bit EC key such as P-256 — again, the default on modern free certificates.

A note on the last three: valid-and-trusted is the critical one that drives the warning page. Signature and key strength are about future-proofing and audits — a recent free certificate almost always passes them automatically, but they’re the things a security review will check, so they’re worth getting right.

How to fix it (free, ~15 minutes)

Hand this section to whoever runs your website or hosting — the fix is free. A valid, strong, auto-renewing certificate costs nothing through Let’s Encrypt or any modern host. We only charge to monitor that it stays healthy over time, not to fix it. If you don’t have an IT person, the platform notes below will get most owners there.

Step 1 — Get (or replace) the certificate with a free, trusted one. This single step fixes validity, signature, and key strength all at once, because modern free certificates use SHA-256 and strong keys by default.

• Cloudflare: in SSL/TLS → Overview, set the mode to Full (Strict). Cloudflare issues and auto-renews a trusted edge certificate for you; make sure your origin server also has a valid certificate so “Strict” works.
• Google Workspace / Microsoft 365 hosting or any cPanel host: look for SSL/TLS Status and run AutoSSL. It provisions and renews free certificates automatically.
• Site builders (Squarespace, Wix, Shopify, modern WordPress hosts): SSL is usually on by default — confirm it’s enabled in your domain/security settings, and that it covers both yourbiz.com and www.yourbiz.com.
• Your own Linux server (Nginx/Apache): install Let’s Encrypt with Certbot — sudo certbot --nginx -d yourbiz.com -d www.yourbiz.com (or --apache). For a modern EC key, add --key-type ecdsa. List every hostname you serve with -d so the certificate matches them all.

Step 2 — Make renewal automatic so it never expires again. This is the step that prevents the weekend-outage scenario.

• On a Let’s Encrypt server, confirm the renewal timer is active and test it: sudo certbot renew --dry-run. Certbot normally installs an automatic timer; if not, add a daily cron job: 0 3 * * * certbot renew --quiet.
• On Cloudflare, cPanel AutoSSL, and managed/site-builder hosts, renewal is handled for you — there’s nothing to schedule.

Step 3 — Make sure it covers the right names. The most common “valid but warning” cause is a name mismatch. The certificate must cover every hostname customers actually use — the bare domain, www, and any subdomains like shop. or app.. When generating a certificate, include each one (a wildcard like *.yourbiz.com covers all subdomains in one go).

Step 4 — If only signature or key strength is flagged, just reissue. You don’t need to buy anything: generate a fresh certificate (Step 1) and the new one will use SHA-256 and a strong key automatically. On your own server you can pin a modern key explicitly — e.g. openssl ecparam -genkey -name prime256v1 -out server.key for EC, or openssl genrsa -out server.key 4096 for RSA — then reissue.

Step 5 — Verify, then re-check here. Confirm the dates, issuer and key with a quick command — echo | openssl s_client -servername yourbiz.com -connect yourbiz.com:443 2>/dev/null | openssl x509 -noout -dates -issuer -subject — then re-run this check.

Common mistakes

• Treating “we installed SSL once” as done. Certificates expire on a clock. Without auto-renewal, the question isn’t if it lapses but when — usually at the least convenient moment.
• Covering www but not the bare domain (or vice versa). Both must be on the certificate, or one of them throws a name-mismatch warning. The same trap catches new subdomains added later.
• Leaving a self-signed certificate on a “test” subdomain that’s actually public. It encrypts, so it feels secure — but browsers (and security scanners) treat it as untrusted, and it’s a classic audit red flag.
• Assuming paid means safer. A free Let’s Encrypt certificate is exactly as trusted and encrypted as an expensive one. Paying more doesn’t make a stronger padlock.
• Renewing the certificate but forgetting to reload the server. A new certificate sitting on disk does nothing until the web server is reloaded to pick it up — a surprisingly common cause of “I renewed it but it still shows expired.”
• Auto-renewal that silently failed. A renewal job can break (a moved file, a DNS change, a port blocked) and keep “succeeding” quietly. Monitoring the expiry date — not just the renewal job — is what actually catches this before it bites.

FAQ