How to Set Up SSL Monitoring

SSL certificates typically have a validity period of 90 days to 13 months, depending on the certificate authority and type. Unlike domain registrations, which send renewal reminders to the domain owner, SSL certificate expiry notifications often go to the technical contact on the hosting account — an email address that may not be monitored by the person responsible for the client relationship.

When an SSL certificate expires, the impact is immediate and total. Modern browsers display a full-screen warning — 'Your connection is not private' in Chrome, 'Warning: Potential Security Risk Ahead' in Firefox — that prevents most visitors from reaching the site. The site is technically online, but for all practical purposes it is down. Revenue stops, leads stop, and the client calls you asking what happened.

The problem is compounded for agencies managing multiple client sites. Each site may have its own SSL certificate, hosted on different platforms, managed through different hosting accounts, with renewal notifications going to different email addresses. Without a centralized tracking system, it is only a matter of time before a certificate expiry slips through the cracks.

SSL monitoring solves this by providing a single view of every certificate's status and expiry date, with alerts that fire well before the expiry so there is time to act. It converts a process that depends on scattered email notifications into one systematic workflow.

Before you can monitor SSL certificates, you need to know where they all are. For each website you manage, identify the domain and any subdomains that serve content over HTTPS. Each unique hostname may have its own certificate, or multiple hostnames may share a certificate — the inventory should capture every hostname that needs to be monitored.

For each hostname, record the certificate type (single domain, wildcard, multi-domain/SAN), the certificate authority, the issue date, the expiry date, and where the certificate is managed (which hosting account, which control panel, which renewal system). This information can be gathered by checking the certificate details in a browser — click the padlock icon in the address bar and view the certificate information.

Do not forget subdomains. A site may have the main domain on one hosting platform, a staging subdomain on another, and an API subdomain on a third. Each of these may have its own certificate with its own expiry date. Missing a subdomain in the inventory means that subdomain's certificate can expire without warning.

For agencies, build this inventory during client onboarding and update it whenever a new site is added or a hosting migration changes the certificate configuration. The inventory is the foundation of the entire SSL monitoring workflow — if a certificate is not in the inventory, it is not being monitored.

Once you have the inventory, configure expiry tracking for every certificate. The goal is to receive an alert when a certificate is approaching expiry — far enough in advance to handle the renewal without urgency, but not so far in advance that the alert gets ignored among other notifications.

A practical alert schedule uses three milestones: a 60-day advance notice that the certificate will need renewal within the next quarter, a 30-day notice that renewal should be initiated if it has not been already, and a 14-day notice that the certificate is approaching expiry and action is urgent. These milestones give multiple opportunities to address the renewal before it becomes an emergency.

For certificates managed by hosting providers with auto-renewal, the alerts serve a different purpose. Rather than reminding you to manually renew, they remind you to verify that the auto-renewal has completed successfully. Auto-renewal can fail when hosting accounts have billing issues, when domain validation fails, or when the provider's renewal system encounters an error. The alert is a prompt to check, not necessarily to act.

Most SSL monitoring tools check the live certificate on each monitored hostname and report the current expiry date. This means the tracking reflects the actual state of the certificate, not what was recorded when the inventory was created. If a certificate is renewed early, the monitoring system picks up the new expiry date automatically.

Many hosting providers and certificate authorities offer automatic SSL certificate renewal. This is convenient when it works, but auto-renewal is not infallible. Billing problems on the hosting account can prevent renewal. Changes to DNS configuration can break the domain validation that auto-renewal depends on. Provider system changes can interrupt the renewal process without notification.

The verification process is straightforward: when you receive a 30-day or 14-day expiry alert for a certificate that should be auto-renewing, check the live certificate to see whether a new certificate has been issued with an updated expiry date. If the expiry date has moved forward, the auto-renewal completed. If the expiry date has not changed, the auto-renewal has not run and manual intervention is needed.

For agencies managing client sites, this verification step is especially important. The client may assume the hosting provider handles everything. The hosting provider may assume someone is monitoring the certificate. The gap between those assumptions is where expired certificates happen. A monitoring workflow that explicitly verifies auto-renewal closes that gap.

Document the auto-renewal status for each certificate in your inventory. Note which certificates are auto-renewed, through which provider, and when you last verified the renewal was working. This record makes the verification process efficient during future renewal cycles.

Managing SSL certificates across a handful of sites is straightforward. Managing them across dozens or hundreds of sites requires a system that scales. The key is centralization: a single dashboard or report that shows the status and expiry date of every certificate across every site, sorted by urgency so the ones needing attention soonest are at the top.

For agencies, organize the monitoring by client rather than by certificate. Each client view should show all certificates associated with their sites, the expiry status of each, and any actions needed. This matches how the work is actually done — when you contact a client about their upcoming renewals, you want to address all of them in a single conversation rather than reaching out separately for each certificate.

Wildcard certificates add a layer of complexity. A single wildcard certificate for *.example.com covers every subdomain under that domain. When monitoring, you need to track the certificate at the wildcard level and verify that the subdomains actually using it are covered. If a new subdomain is added that is not covered by the existing wildcard, it needs its own certificate.

Multi-domain certificates (SAN certificates) that cover multiple distinct domains require similar attention. Track which domains are covered by each certificate, and verify that all expected domains are included. When a new domain is added to the portfolio, check whether it can be added to an existing multi-domain certificate or needs its own.

SSL monitoring should not be a separate process that runs on its own schedule. It should be integrated into the regular website health check workflow that runs for every site. When you run a monthly health check, the SSL certificate status — valid or expiring, expiry date, certificate type — should be part of the check results.

This integration means SSL monitoring happens as a natural part of the existing workflow rather than requiring a separate process to maintain. The monthly health check already verifies reachability, response time, and security headers. Adding SSL certificate status to that check is a small addition that provides significant value.

For agencies delivering client reports, including SSL certificate status in every monthly report makes the monitoring visible to the client. 'SSL certificate valid through March 2026 — next renewal due February 2026' tells the client that the certificate is being tracked and that there is a plan for renewal. This is a simple line in a report that provides significant reassurance.

When an SSL certificate is renewed, verify the new certificate is active and serving correctly by running a health check immediately after the renewal. This confirms the renewal completed successfully and that the site is serving the new certificate without any chain or configuration issues.

Only checking the main domain and ignoring subdomains is a mistake that leaves gaps. Staging sites, API endpoints, and mail subdomains all use SSL certificates that can expire. If a staging site's certificate expires, it may not affect production visitors, but it can block development and testing work. If an API subdomain's certificate expires, it can break integrations that depend on that API.

Assuming auto-renewal always works without verification is another common error. Auto-renewal is reliable under normal conditions, but when conditions change — hosting account billing issues, DNS changes, provider system updates — it can fail silently. The only way to know auto-renewal worked is to check the certificate's current expiry date.

Not tracking certificate type and coverage creates confusion when renewals are due. If you do not know whether a certificate is a single-domain, wildcard, or multi-domain certificate, you may not realize that renewing one domain's certificate also affects other domains covered by the same certificate.

Waiting until the certificate is 7 days from expiry before taking action leaves no margin for complications. If the renewal process encounters a problem — a billing issue, a validation failure, a provider delay — there is no time to resolve it before the certificate expires. The 60-30-14 day alert schedule provides adequate margin for most situations.