How certificates expire unnoticed
An SSL certificate has a start date and an end date. Once the end date passes, browsers stop trusting the site until someone installs a new certificate. Nothing else changes on that day. The code is the same and the server is the same. The site is still there, but browsers treat it as broken.
The trouble is that renewal is easy to forget. Many certificates are issued for a year or less, so the gap between renewals is long enough to lose track of. The person who set up the site may have moved on. Renewal may be handled by a hosting panel, a script, or a plugin that someone switched off months ago. Each of these looks fine until the day it stops working.
A second problem is that expiry rarely comes with a warning you will see. The renewal email may go to an old inbox. The message may arrive during a busy week and get archived. If nobody checks the date on purpose, the first sign of trouble is the one your visitors see.
What visitors see when one lapses
A visitor who opens a site with an expired certificate sees a full-page warning. The browser says the connection is not private, or that the certificate has expired. Most people do not click through. They close the tab. If they were trying to pay, book or sign in, that work stops there.
The effects spread beyond the browser. Other services that call your site may fail their requests. A mobile app or integration that talks to your backend may stop working, and the error it shows the user may not mention the certificate at all. Support tickets arrive with descriptions like "the site is broken" or "it says unsafe", and you have to work backwards to find the cause.
For a small team, the cost is often the time spent finding the problem and the trust lost while it is down. Customers who see a warning on your domain do not know whether the problem is a renewal or something worse, and they will not wait to find out.
Set alerts at 30, 14 and 7 days
An expiry alert is only useful if it arrives while there is still time to act. A single reminder a day before the end date is too late, because renewal can involve a payment, a new file on the server, a DNS check, or a wait for a provider to respond.
A practical pattern is three alerts:
- 30 days before expiry. This is the planning point. Confirm who owns the renewal, check that the payment method is current, and note the date in your team's task list.
- 14 days before expiry. This is the check-in point. Confirm the renewal has started. If it has not, someone should pick it up this week.
- 7 days before expiry. This is the escalation point. If the certificate is still not renewed, treat it as urgent and do the work the same day.
The exact days matter less than the habit. What matters is that each alert goes to a named person, and that the person knows what to do when it arrives. An alert that lands in a shared inbox with no owner is easy to ignore.
Alerts should also reach people in your organisation only. Keep the recipient list to the people who can renew the certificate or approve the spend.
Check every domain and subdomain you run
Most teams count the main domain and forget the rest. A certificate for the apex domain may not cover the subdomain that serves your app, your status page, your staging site or your API. Each hostname that serves HTTPS needs its own check, because each one can expire on its own date.
Make a list before you set any alerts. Include:
- the main website and any redirect domains
- subdomains for apps, dashboards, APIs and documentation
- staging and test environments that clients or partners can reach
- any older domain that still points at a live server
- client sites you run on behalf of others
For each entry, record the certificate's end date and where it was issued. Some teams find that a domain they had forgotten is still serving traffic. Others find a certificate on a server nobody has logged into for a year. Both are worth knowing before they expire.
If you run client sites, the list is longer and the owner of each site may be different. Put each client's domains on the list with the client's name against them, so that you know whose renewal it is and who to tell if it slips.
Who renews, and where it is written down
An alert with no owner is only half a plan. For every certificate on your list, write down three things: who renews it, how they renew it, and where the renewal details are kept.
The who should be a named person, with a named backup. The how should be short: the provider, the steps or the script, and the account used. The where should be a place that outlives any one person. A shared document or your team's task list works well, provided everyone knows where it is.
Review the list when someone joins or leaves the team, and after any change to hosting or DNS. A certificate that renews automatically today may stop renewing after a server move. The list is the thing that tells you so.
If you use AperioFlow, you can keep the list next to the tasks for each site, so renewal dates sit in the same place as the work that follows them. Start free at https://app.aperioflow.co.uk/#/signup. The free plan includes 10 monitors, and a team plan is 29 pounds a month flat for up to 10 people, as on the pricing page. You can download your data at any time.