For an MSP, an expired certificate is rarely the client's website. That renews itself through the host or CDN. It's the firewall's SSL VPN portal, the Remote Desktop Gateway, the hybrid Exchange connector, or the line-of-business app on a server someone set up five years ago. Those are the ones that bring a support call at 8am, and lifetimes are shrinking: 200 days since March 2026, 100 days from March 2027 and 47 days from 2029 (see 47-day SSL certificates).
The three questions to answer for every client
- What certificates exist? You can't monitor a host you don't know about.
- What is each host actually serving? Not what the renewal log says.
- Who renews it, and how? Automated, or a person with a runbook.
1. Build the inventory from public logs
Every public certificate is published in Certificate Transparency (CT)
logs. Searching them for a client's domain lists every hostname that has
had a certificate, including the ones nobody wrote down:
vpn., remote., autodiscover., portal., the old owa..
Do this at onboarding and keep doing it: a new hostname appearing in CT is someone, maybe not you, setting something up. The certificate finder does the search for one domain; crt.sh is the raw source.
Wildcard certificates hide individual hostnames from CT, so ask the client where each wildcard is installed.
2. Check what each host serves
Connect to each host and read the certificate it presents. This is the only check that catches a renewed but not installed certificate: the ACME client or the client's IT person renewed it, but the appliance, reverse proxy or second cluster node still serves the old one. CT will show the new certificate; the host won't. See certificate renewed but not installed.
Check every port that matters, not only 443: 8443 and 4443 on firewalls, SSTP and RD Gateway, mail on 465, 587 and 993.
3. Alert relative to lifetime
"Alert 30 days before expiry" was sensible for one-year certificates. For a 47-day certificate it means alerting from day 17. Grade by the share of lifetime left instead: warn at a third of the lifetime (capped at 30 days), and treat 15% (capped at 7 days) as urgent. Automated certificates that renew on schedule then never alert; ones whose renewal is stuck do.
4. Sort hosts into automated and manual
For each host, record how it renews:
- Automated end to end (CDN, ACME on the server, cert-manager): only needs monitoring.
- Automated renewal, manual install (an ACME client on a server, then someone uploads to the firewall): the most common source of outages. Script the install step, or put it in a calendar.
- Manual (bought certificates, imported by hand): every one of these becomes four times the work at 100-day lifetimes. Plan to automate or move them behind something that renews itself.
Runbooks for the usual appliances: FortiGate, SonicWall, Sophos Firewall, IIS and RDS, Exchange hybrid.
5. Route alerts to the right place
One inbox with 25 clients' expiry warnings gets ignored. Group hosts by client, send alerts where your team already works (the PSA, Teams or Slack), and send one message per client per run rather than one per host.
6. Report it to the client
Clients don't see certificates until one breaks. A monthly line in the client report ("14 certificates monitored, 3 renewed, none expiring in the next 30 days") shows the work, and makes the case for automating the manual ones.
Doing it with Nameward
The MSP plan does the steps above for up to 25 clients, 100 domains and 500 hosts: CT inventory per domain, a live check of each host, lifetime- relative grading, renewed-but-not-installed detection, alerts by email, Slack, Teams or webhook, and a monthly white-label PDF per client. See pricing, or scan one client's domain free with the MSP domain security report.