The phone call lands on a Friday afternoon. The website’s serving a red browser warning, the booking form has stopped taking payments, and the office manager has just realised the marketing email she sent that morning is now bouncing because the mail domain’s certificate also expired. Three things, one root cause: an SSL certificate (the digital padlock that proves a website is real, and what makes the browser show the lock icon next to the URL) lapsed at 02:14 that morning and nobody saw the warning emails because they went to an inbox the original developer set up four years ago.
We’ve watched versions of this play out across small businesses for years. The mechanics are simple, but the reason it keeps happening is that SSL renewals live in a strange ownership gap. The website hosting company assumes IT handles it, IT assumes the web developer handles it, the web developer left in 2023, and the bill is on a personal credit card that’s been cancelled. The certificate expires unnoticed and the trading day breaks.
What follows is the frame we use to take that risk off the table. Five touchpoints, one calendar, no surprises.
Why this matters more in 2026 than it did in 2020
Two things have shifted in recent years. First, certificate lifetimes have shrunk. Browser vendors agreed back in 2020 to cap maximum SSL validity at 13 months, and the industry’s moving toward 90-day and even 47-day lifetimes by 2027. That means renewals stop being annual and start being quarterly, or monthly. You can’t lean on a single calendar reminder anymore.
Second, the ripple effect when a certificate fails is wider than it used to be. A modern SME’s website is usually wired into payments, email authentication, customer portals, booking systems, and a CRM (your customer database). One expired certificate can take all of those down at once. The blast radius is bigger; the warning window is shorter.
Common failure modes
Before the checklist, the patterns we see most often:
- Orphan certificates. Someone left the business, took the renewal notifications with them. Nobody noticed until expiry.
- Renewal emails to a generic inbox.
info@oradmin@that nobody actively monitors. Warnings sit there for months. - Auto-renewal that didn’t. The card on file expired. The auto-renewal failed without notice. The certificate didn’t renew.
- Subdomain blind spots. The main domain renews fine. The
checkout.orapp.subdomain has its own certificate and its own renewal cycle that nobody tracked. - Internal certificates ignored. Internal portals, VPN gateways (your remote-access door), mail servers all have certificates too, and they fail differently. Users get a scary warning, click through, and now they’re trained to ignore certificate warnings.
The common thread: nobody owns it. The five-touchpoint checklist puts an owner on each stage.
The five-touchpoint checklist
Touchpoint 1: Inventory, know what you actually have
What this means in practice: list every certificate that’s currently live, where it’s hosted, who’s paying for it, and what it covers.
Most SMEs we work with discover they have between three and twelve certificates when they thought they had one. The website domain, the email mail-server, the staff VPN, the internal SharePoint (the file-and-document side of Microsoft 365) portal, the customer-facing booking subdomain, the API endpoint the warehouse uses, each can have its own certificate, its own issuer, and its own renewal cycle. You can’t manage what you can’t see, so the first job is a clean inventory: domain, issuer, expiry date, registered admin email, billing source, what would break if it lapsed.
Touchpoint 2: Ownership, name a person, not a role
What this means in practice: every certificate has a named human accountable for it, with a backup. Not “IT”, not “the agency”, but a named person, in writing, with their contact details up to date.
Roles are slippery: “the web team handles it” works until the web team is one freelancer who quit. Names are sticky by contrast. If the person leaves, the gap is visible. We keep a single spreadsheet (the printable version of this checklist gives you the template) with primary owner, backup owner, last-verified date. When somebody leaves, the spreadsheet tells you exactly what needs reassigning.
Touchpoint 3: Calendar, three reminders, not one
What this means in practice: every certificate gets reminders at 60 days, 30 days, and 7 days before expiry, hitting at least two inboxes.
One reminder is a single point of failure, whereas three reminders across two inboxes gives you redundancy without becoming noise. The 60-day touch is the planning trigger; that’s when the renewal goes onto someone’s task list. The 30-day touch is the action trigger; if it isn’t done, escalate. The 7-day touch is the emergency trigger. By that point something’s wrong and a person needs to pick up the phone.
Touchpoint 4: Renewal test, verify before the swap
What this means in practice: before the new certificate goes live, test it on a staging environment or during a low-traffic window, and check every dependent service still works.
Most certificate renewals are clean, but only most. The ones that aren’t fail in ways where the certificate itself looks fine but a downstream service can’t use it: wrong intermediate chain, missing subject-alternative-name for a subdomain, a service that pinned the old certificate’s fingerprint. The five minutes you spend verifying the new certificate against every dependent service is the five minutes that saves you the Friday-afternoon phone call. Check the website loads, check email authentication still passes (SPF, DKIM, DMARC, the three email-authentication settings that tell other mail servers your messages are genuine), check the VPN connects, check the booking form takes a test payment.
Touchpoint 5: Post-renewal log, close the loop
What this means in practice: when a renewal completes, write down what was renewed, when, by whom, and the new expiry date.
The log is what makes next year’s renewal easy. It tells the new IT person who took over from the old one what’s been done and what’s next. It tells the auditor or insurer that yes, you have a process. And it catches the slow drift. If the same certificate has been renewed three years in a row by three different people with three different issuers, that’s a signal to consolidate.
Where SMEs trip
The two failures we see most often, even with a checklist in hand:
The first is treating the inventory as a one-time exercise. New subdomains get spun up, new services get launched, new certificates get issued, and the inventory drifts within months. The inventory needs a quarterly refresh, minimum. We build that refresh into the managed-service calendar so it happens without anybody needing to remember.
The second is letting the renewal slip from a scheduled job to an emergency. The 60-day reminder hits, somebody marks it “I’ll do it next week”, next week becomes next month, and now you’re at 14 days with a renewal that needs three approvals you don’t have. The discipline is treating the 60-day touch as the deadline, not the warning.
What good looks like
When this is working, certificate renewals are boring. Sixty days before expiry the calendar pings, the named owner books a 30-minute slot, the renewal goes through, the verification passes, the log gets updated, and the next reminder is automatically scheduled for the new expiry. No drama, no Friday phone calls, no red browser warnings in front of a customer.
Across the SMEs we manage, certificates aren’t a thing anyone thinks about, because the process thinks about them on everyone’s behalf, which is the goal.
Where this lands with us
Certificate management sits inside our Managed Services practice. For clients on a managed contract we run the inventory, hold the calendar, own the renewals, and keep the log; it’s part of the service, not an add-on. For clients who’d rather run it themselves, we’ll hand over the template and the calendar and check in twice a year to make sure nothing’s drifted.
Either way the goal’s the same. The Friday-afternoon call where a padlock turned red costs you the booking system, the customer trust that took years to build, and a weekend of cleanup. None of that is the certificate’s fault, it’s the gap nobody owned. Close the gap and the call doesn’t happen.
Working through a certificate inventory and not sure what’s actually out there? Drop us a note at info@jmopartners.co.uk and we’ll do a free initial sweep.
Want the printable version of this checklist? Drop us a note at info@jmopartners.co.uk and we’ll send it through.
JMO|Partners · Enterprise IT, sized for SMEs.