The IT Admin's Checklist for SSL and Domain Expiration Tracking

SSL and Domain Expiration Checklist for IT Admins

A solid SSL and domain expiration checklist has five parts: inventory every domain and certificate, set tiered alert thresholds, name an owner for each renewal, automate the checks with a monitoring tool, and audit the whole thing quarterly. In my experience, expiry outages are rarely a skills problem. They happen because someone forgot an asset exists or nobody knew whose job the renewal was. Nearly all the monitoring can be automated, which leaves people to handle renewals and the odd exception.

A quick note on terminology: "SSL" is still what most of us search for, but modern public certificates use TLS. I'll say "SSL certificate" because it's familiar, and in practice it means the same thing. Below, I walk through each step, and there's a compact copy-and-paste checklist at the end for your wiki or runbook. It's one of those jobs that feels dull right up until the day it saves your weekend.

Why SSL and domain expiry slips through the cracks

Picture it: 2am, your phone buzzes, and a partner's integration is failing because a certificate on some forgotten subdomain lapsed an hour ago. Nobody remembers who set it up. The renewal reminders were going to a colleague who left eighteen months ago. Or you find that the company's main domain is registered on a former developer's personal card, and that card has just expired.

If that sounds familiar, you're in good company. Even large vendors trip over this. Microsoft Teams suffered a widely reported disruption in February 2020 that the company attributed to an expired authentication certificate. Big or small, the pattern is the same.

The root causes are pretty consistent:

• Renewal emails go to a departed employee or a dead inbox.
• Auto-renew fails because the payment card on file has expired.
• A team spins up a shadow IT subdomain and never tells anyone.
• A certificate is issued outside the normal process, like a quick corporate-card purchase for a proof of concept that became production.

The cost goes well beyond a red browser warning. Expired certificates break API integrations, fail webhooks, erode customer trust and can cause email delivery problems. An expired domain is worse, because everything attached to it can disappear at once.

Two things are worth knowing before we start. First, certificate expiry and domain expiry are separate risks. Renewing a certificate doesn't renew the domain, and renewing the domain doesn't refresh the certificates on your services, so treat them as distinct assets with distinct workflows. Second, registrar reminders are a backup, not a control. ICANN's Expired Registration Recovery Policy requires registrars to send renewal reminders for covered gTLD registrations (roughly one month and one week before expiry), but that doesn't guarantee the right person sees them or that payment goes through.

Step 1: Inventory all domains and SSL certificates

You can't track what you don't know exists, and it's surprisingly easy for a handful of domains or certificates to live in someone's memory instead of a record. Start by building one proper inventory.

1. List every registered domain. Include old campaign domains, typo-protection domains, regional domains and anything inherited through an acquisition. Don't forget UK staples like .co.uk and .uk variants.
2. Record the domain details. Capture the registrar, registrant contact, nameservers, expiry date and auto-renew status. RDAP (the standardised successor to WHOIS) is handy for checking what the registry actually says.
3. Discover your certificates. Check certificate transparency (CT) logs, load balancers, CDNs, ingress controllers, mail servers and internal tools. CT logs help with discovery but they aren't a full inventory: they won't tell you who owns a certificate, and they won't show private-environment certificates.
4. Capture certificate details. Note the covered names (including Subject Alternative Names), the certificate authority, expiry date, issuance method (ACME, manual or managed) and which systems depend on it.
5. Hunt for the non-obvious endpoints. API gateways, VPN portals, SMTP and IMAP hosts, staging environments and the domain behind your status page all get missed more often than they should.
6. Add a business criticality column. When three alerts land at once, you'll want to know which one matters most.

Keep everything in one shared source of truth. Not five spreadsheets, and certainly not one person's head. If a vendor or agency handles renewals for some domains, still assign an internal owner. Otherwise your escalation path depends entirely on an outside party.

Step 2: Set SSL and domain expiry alert thresholds

A single "30 days before expiry" alert is better than nothing, but it's rarely enough. The right lead time depends on how long it takes you to notice a problem, approve and pay, renew or reissue, deploy and verify. Domains and certificates behave differently here.

The table below gives practical starting points, not universal standards. Adjust them to your own approval and deployment times.

Asset	SSL alerts (days before expiry)	Domain alerts (days before expiry)	Why	Where alerts go
Production site	30, 14, 7, 1	90, 60, 30, 14, 7, 1	Highest impact; this is the default pattern	Email early, chat channel when urgent
Customer-facing API	45, 30, 14, 7, 1	90, 60, 30, 14	Partners break silently, so start earlier	Team channel plus on-call
Internal tool	30, 14, 7	60, 30, 14	Lower impact, but still disruptive	Email to owner and backup
Legacy or low-priority domain	30, 7	90, 30, 14	Often forgotten; the real question is keep or drop	Email, plus a ticket to decide

Domains get earlier alerts because payments, approvals, transfers and registrant verification can all take longer than you'd expect.

How shorter SSL certificate lifetimes change alert planning

Publicly trusted certificates are currently capped at 398 days, and Let's Encrypt certificates last 90 days. The CA/Browser Forum has also approved a schedule (ballot SC-081v3) that reduces the maximum to 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. Please check the current timetable before you plan around it. Either way, renewals will come round more often, so automation stops being optional and monitoring becomes your safety net.

Alert on SSL renewal failures, not just expiry dates

An expiry-date alert tells you something is about to go wrong. A failed-renewal alert tells you something already has. Validation failures, DNS changes, inaccessible accounts and deployment errors can all quietly break automation, so monitor both.

How to avoid alert fatigue

Alert fatigue is real. Send early warnings (30 days or more) to email, and save Slack, Discord or Telegram for the urgent stuff. For high-risk assets, alert both the named owner and a monitored team channel or ticket queue, so no single mailbox becomes a point of failure.

And please don't treat a domain's post-expiry grace period as extra renewal time. Many gTLDs have an auto-renew grace period, a redemption period and a pending-delete stage, but the details vary by registry and registrar, and services can break the moment the domain lapses.

Step 3: Assign an owner for every domain and certificate renewal

This step quietly prevents most incidents. Automation can't help if nobody is accountable when it fails.

• Name one primary owner and one backup per asset. Record their team or role as well as their name.
• Clarify who pays. Is it IT, finance or a business unit? Which card or purchase order is on file, and when does that card expire?
• Separate notifications from access. Use role-based mailboxes (for example, domains@ or certs@) as the contact address so notices reach a team. For logins, give each person a named account with MFA and delegated permissions rather than sharing credentials. Document a break-glass recovery method too, so continuity doesn't hinge on one person's password manager.
• Build it into joiner-mover-leaver processes. Add renewal responsibilities and account access to on-boarding and off-boarding checklists. The "departed colleague" problem is entirely preventable.
• Define an escalation path. If the owner hasn't acknowledged an alert within, say, 48 hours, who gets pinged next? Write it down.
• Document who controls what. For domains, that means who controls the registrar account, billing and DNS changes, not just who receives the reminders.

A quick UK note: for .uk domains registered through Nominet, keep your registrant details accurate and make sure the contact email is monitored, so renewal notices and verification requests don't vanish.

Even with automated renewals, someone still owns the outcome. That person watches for failures, confirms the renewed certificate is actually deployed, and is where the escalation lands.

Step 4: Automate SSL certificate monitoring and domain expiration tracking

Here's where you get your time back. Spreadsheets and calendar reminders are fine to begin with, but they rely on someone remembering to look. The aim is for machines to do the watching and people to do the deciding.

1. Automate issuance and renewal with ACME where you can, but check the result instead of trusting it blindly. Renewals can fail for reasons nobody notices until it's too late.
2. Check the live certificate, not the one you think is deployed. SSL certificate monitoring should inspect what your endpoint is actually serving. A freshly renewed certificate sitting unused on a server protects nobody.
3. Track domain registrations centrally. Domain expiration tracking in one dashboard or feed means no more logging in to five registrars to compare dates.
4. Watch the scripts that do the renewing. If a cron job runs your renewal script, add heartbeat monitoring so a silent failure triggers an alert instead of a surprise weeks later.
5. Verify failures before alerting. Confirming an issue from more than one location cuts false alarms and keeps the noise down.
6. Feed your own systems. Export expiry data via an API or file into your inventory or ticketing, so your records stay current without manual effort.
7. Be honest about what can't be automated. Payment method updates, registrant verification and approvals still need a human. That's fine. What matters is that a human is told in good time.

One example of a tool that covers this is Moonitor. It offers SSL and domain expiration monitors alongside HTTP/S, keyword, port and ping checks, DNS record change detection and cron/heartbeat monitoring, with alerts by email, Slack, Discord, Telegram or webhooks. It also offers a free trial. Check the current feature list and trial terms on its site, and judge any tool, this one included, against the seven points above.

Step 5: Review and audit your SSL and domain inventory quarterly

Inventories drift. Teams launch, retire and rename things, and your records quietly go stale. A quarterly audit stops that drift turning into an incident.

• Reconcile your sources. Compare the inventory against registrar accounts, CT logs and your monitoring tool. Anything that appears in one but not the others deserves a closer look.
• Look for changes. Find new subdomains, retired services, and domains that should be dropped or consolidated.
• Verify the people and the payments. Confirm that contacts, owners and payment methods are still current.
• Test one alert end to end. Trigger it, check it lands in the right channel, and confirm the escalation path still works.
• Review incident history and alert noise. If one threshold is being ignored, tune it. If something nearly slipped through, tighten it.
• Go deeper once a year. Revisit CA choices, certificate types (single, wildcard, multi-domain) and registrar security such as registry lock where it's available.
• Keep a short audit log. A few lines per quarter is plenty for compliance and handovers.

It's also worth running an ad hoc audit after any acquisition, migration or team shake-up.

Printable SSL and domain expiration checklist

Copy this into your wiki or runbook and tick things off as you go.

Inventory (Step 1)

• All domains and certificates listed in one shared source of truth
• Registrar, expiry, auto-renew, CA, issuance method and dependent systems recorded
• Business criticality assigned

Alerts (Step 2)

• SSL and domain thresholds set per asset tier
• Failed-renewal alerts in place, not only expiry alerts
• Early warnings by email, urgent ones to chat

Ownership (Step 3)

• Primary owner and backup named per asset
• Role mailboxes for notices; named accounts with MFA; break-glass method documented
• Payer confirmed and escalation path written down
• Renewal duties in joiner-mover-leaver checklists

Automation (Step 4)

• ACME or managed renewal where possible
• Live-endpoint SSL checks and central domain tracking
• Heartbeat monitoring on renewal jobs

Audit (Step 5)

• Quarterly reconciliation, contact and payment checks
• One alert tested end to end
• Annual review of CAs, certificate types and registrar security
• Audit log updated

What to do when a domain or certificate expires

It happens, even to the best teams. Don't panic. Work through this:

1. Confirm the scope. Which domains, certificates and services are affected?
2. Renew or reissue. Whichever is quicker and safer.
3. Deploy the fix. Get the new certificate or domain settings live.
4. Verify from multiple regions. Check it's genuinely fixed everywhere, not just from your laptop.
5. Update your status page. Tell customers what happened and when it's resolved.
6. Write a brief post-incident note. Capture the cause and the fix, then update the checklist so it can't happen again.

If you do only one thing this week, start with the inventory. It's the least glamorous step, and it's the one that makes everything else work.

Frequently asked questions about SSL and domain expiration tracking

What should be on an SSL and domain expiration checklist?

An inventory, tiered alerts, named owners, automated monitoring and a quarterly audit. The printable version above condenses all five.

How often should I audit my certificates and domains?

Quarterly, with continuous monitoring in between. Add a deeper annual review and an ad hoc audit after acquisitions, migrations or team changes (see Step 5).

Who should own renewal responsibilities on a team?

One named owner and a backup per asset, usually in IT or DevOps. Use role mailboxes for notices, but keep logins on named, MFA-protected accounts (see Step 3).

Can I automate the entire SSL and domain expiration checklist?

Most of it. Renewal, expiry checks and alerting can be automated, but payments, registrant verification, approvals and the quarterly review still need a person.

How far in advance should I get alerts for domain expiry versus SSL expiry?

Start domain alerts at 60 to 90 days and SSL alerts at around 30 days, earlier if renewal is manual. Treat these as starting points and adjust them to how long your approvals and deployments really take (see Step 2).