--- title: SSL certificate expired — the cheapest failure that costs you the most in trust description: An expired SSL is a cheap failure that hits client trust hard. How to make SSL certificate checks continuous, see the expiry date ahead of time, and learn about it before the red warning in the browser. source: https://pingvera.com/blog/ssl-certificate-expired.html --- # SSL certificate expired: the cheapest failure that costs you the most in trust Some failures aren't embarrassing to explain: the server buckled under load, the CRM integration is throwing errors, the cart broke after a module update. And then there's the one that hurts a contractor's reputation most precisely because it's so simple — **the SSL certificate expired**. The site is more or less there, but the browser shows a red warning, and the client sends a screenshot asking "why is our site suddenly insecure?" ## Why it hurts more than it seems The client isn't obligated to know what SSL is. To you it's a certificate, a trust chain, TLS, auto-renewal, Let's Encrypt, a web-server config. To the client it's an alarming warning in the browser. And to their customer, a feeling that the site can't be trusted. The most expensive part here is the lost lead. If someone was about to leave their details or pay for an order, the browser's warning may be the last thing they see on the site. They won't stop to figure out who's at fault or what a trust chain is. They'll just close the tab. That's why an expired certificate is a "cheap" failure by cause and a very expensive one by consequence. ## "It should have renewed itself" — a weak defense Auto-renewal looks reliable right up until the day it doesn't fire. And it can fail to fire for plenty of reasons: - DNS changed or a move to another server; - a redirect misconfigured or the validation path closed; - the cron that renewed the certificate died; - someone edited the config by hand — and renewal quietly stopped going through; - the certificate was issued for the domain without www while visitors go to www (site.com and www.site.com are different stories). Many causes, one result: the browser complains, the client is angry. That's why an **SSL certificate check** should be not a one-off task at launch but continuous monitoring. ## What's worth checking in SSL To avoid being woken by a client's screenshot, a certificate is worth watching on several signals: - **SSL expiry** — how many days are left until it lapses, and knowing it ahead of time, not when it's already on fire. It's smart to warn yourself in stages — say, 30, 14, 7, and 3 days: the closer the date, the more insistent the reminder. - **Match to domains and subdomains** — the certificate should cover exactly the addresses people actually use (site.com, www.site.com, shop.site.com are different cases). - **Trust-chain errors** — sometimes a certificate is technically there, but the browser still doesn't trust it because of a badly assembled chain. - **The user's point of view** — it's important to see the site from the outside, the way a visitor does, rather than glance once at the hosting panel and relax. ## Why it's especially sensitive on a support contract An expired SSL reads as an oversight — and it doesn't matter who was formally responsible for renewal. If an agency has a support retainer, the client will ask it, specifically. Because support, in their head, means something simple: "so I don't wake up to problems like this." If they woke up to exactly this one, in their eyes the service didn't work. ## How to turn SSL oversight into an argument for support Quiet certificate oversight sells a retainer well — if you show it. One line in a report shifts the perception: "The SSL certificate was checked daily, 46 days to expiry, no chain errors." Or: "12 days before expiry we got a warning, the certificate was renewed, visitors noticed nothing." This isn't heroics — it's order. But to the client, order is valuable: they don't want to think about certificates, they want that boring technical part to simply never become their problem. It's out of small things like this that the conclusion "these folks are on top of it" is built — or the opposite. ## SSL is part of the bigger picture, not a separate chore Pingvera watches SSL expiry alongside site availability, domain expiry, form submissions, and CMS state (WordPress). For an agency the certificate stops living in one developer's head — it's in the shared control system for client sites. As soon as the date approaches, the team finds out ahead of time and calmly, not from a client's phone call. Alerts arrive where you'll see them right away — Telegram, email, or a webhook. ## Frequently asked questions **How do I check an SSL certificate's expiry date?** Once — open the site over https and look at the certificate details in the browser, or run the domain through an online SSL check. But a one-off check guarantees nothing tomorrow. More reliable is continuous monitoring: a system opens a TLS connection and sees how many days are left until expiry, whether the certificate matches the domain, and whether there are trust-chain errors. **Why didn't the certificate renew automatically?** Auto-renewal breaks for dozens of reasons: DNS changed, a move to another server, a redirect or config edited by hand, the validation path closed, cron died, or the certificate was issued for the domain without www while visitors go to www. The result is the same — the browser shows a warning. That's why SSL expiry needs to be watched, not left to "it'll renew itself." **How many days ahead should you warn about SSL expiry?** It's smart to know ahead of time, with room to react — usually a couple of weeks or more, so you can deal with it calmly instead of fighting a fire on expiry day. In Pingvera the warning threshold is configurable: as soon as the set number of days remains, an alert arrives in Telegram, email, or a webhook. Read also: [Site not working: how to check availability the right way](https://pingvera.com/blog/check-website-availability.html) and [The domain wasn't renewed — and the site vanished](https://pingvera.com/blog/domain-expiry-check.html).