SSL Monitoring Checklist: Track Certificate Health Before It Becomes a Crisis

The first step in SSL monitoring is knowing what you have. For agencies managing multiple client sites, the inventory includes: the main domain and all subdomains that have their own SSL certificates, the type of certificate for each (single-domain, wildcard, multi-domain), the issuer and the expiry date, and where the certificate is managed — hosting provider, CDN, certificate authority portal, or certificate manager like Let's Encrypt.

Wildcard certificates cover all subdomains of a domain (*.example.com) with a single certificate. Multi-domain (SAN) certificates cover a specific list of domains and subdomains. Single-domain certificates cover only the exact hostname specified. Knowing which type each site uses matters when planning renewals and when troubleshooting coverage issues.

For new clients, run a health check as part of onboarding to capture the current certificate details: expiry date, issuer, hostname coverage, and whether HTTPS is active and correctly configured. This is the starting point for ongoing SSL monitoring.

• All domains and subdomains with SSL certificates documented
• Certificate type noted (single-domain, wildcard, multi-domain)
• Certificate issuer and management location noted
• Expiry date for each certificate recorded
• Auto-renewal status confirmed (is auto-renewal enabled?)

Once you have the inventory, the ongoing workflow is to verify that certificates are actually valid — not just that they appear in a renewal record or that auto-renewal is supposedly configured. An external health check that reads the certificate details from the live server is the most reliable way to verify current status.

Run SSL checks as part of every monthly website health review. The check should confirm: HTTPS is active, the certificate is currently valid, the certificate covers the correct hostname, and the expiry window gives sufficient lead time for renewal.

If you discover a certificate expiring within 30 days, initiate the renewal process immediately rather than waiting for the next review cycle. If it is within 14 days, it is urgent regardless of anything else on the schedule.

• Is HTTPS active and the connection secure?
• Is the certificate valid for the exact hostname being tested?
• How many days remain until expiry?
• Is the certificate from a trusted issuer?
• Does the certificate cover all subdomains currently in use?
• Has the certificate changed since the last check?

Renewal timing is where SSL monitoring most commonly fails. A certificate renewal initiated with 30 days remaining is fine. One initiated with 7 days remaining is stressful and risky — if the renewal process encounters a problem, there is no margin. One initiated after expiry is a crisis.

For Let's Encrypt certificates that renew every 90 days: the auto-renewal process typically runs when there are 30 days remaining. Monitor to confirm it completes successfully rather than assuming it ran. For commercial certificates with one to two year terms: create a calendar reminder at 60 days before expiry and another at 30 days.

When a certificate renewal completes, run a health check to confirm the new certificate is installed on the live server and correctly configured. Do not assume the renewal completed successfully without verifying the result from outside the hosting environment.

• Are renewal reminders set at 60 and 30 days before expiry?
• For Let's Encrypt: has auto-renewal completed successfully?
• For commercial certificates: has the renewal been purchased and installed?
• Has a post-renewal health check confirmed the new certificate is live?
• Has the new expiry date been updated in the client record?

Certificate installed for the wrong hostname: a common issue after migrations where the certificate is renewed for one domain but installed on a server also serving different subdomains. Symptoms: HTTPS works on the main domain but shows a certificate warning on a subdomain.

Certificate chain errors: the certificate itself may be valid but the intermediate certificate chain is not installed correctly. Symptoms: the certificate appears valid in some tools but shows warnings in others. Older browsers or mobile devices may show errors while desktop Chrome shows a padlock.

Mixed content warnings: the page loads over HTTPS but includes resources (images, scripts, stylesheets) loaded over HTTP. Symptoms: a padlock icon with a warning indicator, or in some browsers, no padlock at all even though the main content is HTTPS. Check the browser developer tools console for mixed content warnings after any major content update.

• Does the certificate cover all hostnames the site serves content on?
• Are there any certificate chain warnings in browser developer tools?
• Are all page resources (images, scripts, fonts) loading over HTTPS?
• Does the certificate resolve correctly from mobile browsers?
• After a CDN or hosting change: has the certificate been re-verified from outside the CDN?

For agency use, SSL monitoring information should be recorded in client files, not just in the monitoring tool. The client record should include: current certificate expiry date, certificate type and issuer, renewal process location (where to log in to renew), and notes on any unusual certificate configuration.

When SSL is managed by the client's hosting provider with auto-renewal, document that clearly and verify the auto-renewal is actually configured — not just assumed. Hosting providers sometimes change their auto-renewal policies or systems, and what was configured a year ago may not be working the same way today.

Make SSL expiry dates visible in your client review workflow. If you use a project management tool or CRM for client records, create a recurring task 60 days before each client's SSL certificate expires. This creates a redundant reminder separate from the hosting provider's notifications.

• SSL expiry date recorded in client file
• Renewal location and process documented
• Calendar reminder set at 60 days before expiry
• Auto-renewal status documented with last verification date
• Client contact confirmed for hosting provider communications