How to Audit Client SSL Certificates: A Step-by-Step Guide for Agencies

Most agencies discover their SSL coverage gaps when a certificate expires, not before. The discovery sequence is familiar: the client calls, the site is down, someone logs into the hosting control panel to investigate, and the expired certificate date is visible. The gap was there for months. No one was looking.

A systematic SSL audit surfaces the gaps before they become incidents. Run once thoroughly, it produces a complete inventory and a clear picture of where the monitoring coverage is inadequate. Run after client onboarding, it ensures new clients are covered from day one.

This guide covers how to run that audit for an existing client portfolio.

Step 1: Build the Certificate Inventory

The audit starts with enumeration — finding every domain and subdomain across your client portfolio that has or should have an SSL certificate.

For each client, document:

Primary domain — both the apex (client.com) and www variant
All active subdomains — staging, app, API, admin, mail, booking tools, campaign microsites, anything that is publicly accessible or used by the client's team
Third-party integrations that use client domains — payment processor redirect pages, marketing automation landing pages, booking system subdomains
Development and staging environments — even those not shared publicly

Finding subdomains you do not already know about:

Most agencies do not have a complete list of subdomains for each client. Three approaches to find what you have missed:

DNS zone lookup — if you manage or have access to the client's DNS zone, review all A and CNAME records to identify every hostname that resolves
cPanel or hosting control panel — hosted DNS zones typically list all records in the account
Certificate Transparency logs via crt.sh — Certificate Transparency is a public log that records every certificate issued for a domain. Searching crt.sh for %.client.com returns all subdomains that have had a certificate issued. This is the most reliable method for finding subdomains you did not know existed, including subdomains provisioned by previous agencies or by the client directly

For each domain/subdomain found, record:

Current certificate expiry date
Certificate issuer (Let's Encrypt, DigiCert, Sectigo, Comodo, ZeroSSL, etc.)
Where the certificate is managed (cPanel, hosting control panel, Cloudflare SSL, CDN, Shopify, external certificate authority)
Who is responsible for renewal — the agency, the client, or a third party
Whether auto-renewal is configured and, if so, what mechanism it uses

This produces a spreadsheet or database record for every certificate across your portfolio. That is the artifact you are building towards.

Step 2: Check Each Certificate's Current Status

Once you have the inventory, check the actual current state of each certificate — not what the hosting panel reports, but what the live site is actually serving.

What to check on each certificate:

Validity. Is the certificate currently valid? Is the current date before the expiry date? This is the baseline check.

Remaining validity period. How many days until expiry? Flag everything under 60 days for immediate attention. Anything under 30 days requires urgent action.

Certificate chain completeness. An SSL certificate is issued by a CA that is itself trusted by browsers via an intermediate certificate chain. If the intermediate certificate is missing or incorrect, some browsers (particularly older mobile browsers) will show a certificate error even though the end-entity certificate is valid. Check that the full chain is served correctly.

Subject Alternative Names. The SAN list defines which hostnames the certificate covers. A certificate issued for www.client.com does not cover client.com unless the apex domain is explicitly in the SAN list. Check that the SAN list matches the hostnames you expect it to cover.

Issuer continuity. If the issuer has changed since the last renewal, note it. A switch from Let's Encrypt to a paid issuer (or vice versa) may be intentional, but it is worth confirming. An unexpected issuer change can indicate a certificate was provisioned by a party other than the expected one.

Tools for checking certificate status: the browser padlock and certificate details, the openssl command line (openssl s_client -connect client.com:443 -servername client.com), or SSL inspection tools like SSL Labs' SSL Test for a detailed chain analysis. For portfolio-scale checking, an automated tool is preferable to manual inspection of each domain.

Step 3: Check Renewal Configuration

Knowing a certificate's current status is not sufficient. You also need to know whether renewal will happen when the certificate approaches expiry — or whether you will be in the same position in 90 days.

For Let's Encrypt certificates:

Is auto-renewal configured? Via cron, hosting platform automation, ACME client, or WordPress plugin?
When did the certificate last renew successfully? The certificate's issuance date tells you. If it was issued close to 90 days ago, it should renew soon — or may have already failed to do so.
Is the renewal mechanism still functional? A cron job configured six months ago may no longer be running. A WordPress plugin managing renewal may have been deactivated.

For paid certificates:

Who receives the renewal reminder email? Is it an active email address? Is it the agency or the client?
Is the email address associated with the certificate owner account still monitored by a current employee?
What is the renewal lead time — when does the issuer start sending renewal reminders, and is that enough time to act?

Flag any certificate where renewal is dependent on a human receiving and acting on an email, rather than an automated process. Email-dependent renewal is the most common failure mode.

Step 4: Map Subdomains Missed by Monitoring

Even if you have monitoring in place, the audit will typically surface subdomains that are not covered. This is the most common finding.

The usual misses:

Staging environments — often set up quickly and never added to monitoring
Admin and control panel subdomains — cPanel, Plesk, WHM, mail server interfaces
Third-party tool subdomains — booking tools, review widgets, support chat systems that use a client subdomain
Old campaign subdomains — microsites from past campaigns that still have DNS records and certificates, even if they are rarely visited

For each missed subdomain, determine whether active monitoring is required. Old, retired subdomains may simply need their DNS records removed. Active subdomains need to be added to the monitoring configuration.

Step 5: Set Up Ongoing Monitoring

The audit produces a point-in-time picture. Ongoing monitoring is what converts that snapshot into continuous coverage.

Document the audit results — the inventory, the status of each certificate, the renewal configuration, the subdomains added to coverage.

Configure monitoring for every domain and subdomain found. Do not limit monitoring to the primary domain. Every hostname in the inventory should have a certificate check.

Set tiered alert thresholds. 60 days, 30 days, and 7 days are the standard thresholds for agency environments. The 60-day alert gives enough lead time to work through normal client communication without urgency. The 7-day alert is the escalation trigger.

Route alerts to the right people. An alert that goes to a generic monitoring inbox is only marginally better than no alert. Per-client routing, where the alert goes to the account manager responsible for that client, is the configuration that actually produces action.

Test the alert delivery. Confirm that alerts are being delivered to active inboxes, that the Slack or email channel is monitored, and that the alert message includes enough context for the recipient to act without additional investigation.

The audit tells you what to monitor. Merlonix provides the ongoing monitoring layer — per-client certificate tracking, configurable alert thresholds, and account-manager routing — to ensure the gaps the audit surfaced stay closed.