Monitoring SSL Certificate Expiry Across Many Domains: Automation That Actually Scales

Once you have more than a handful of domains and subdomains, manually tracking SSL certificate expiry stops being realistic. A single forgotten certificate can turn into browser “Not Secure” warnings, blocked checkouts, support tickets, and a hit to your brand’s credibility. Whether you manage dozens of client sites as an agency, run a SaaS platform with custom domains, or operate a multi‑brand corporate portfolio, you need a repeatable way to monitor SSL expiry and renew certificates automatically.

In this article, we’ll walk through how we at dchost.com think about the problem from both a technical and operational perspective. We’ll cover how to build a clean inventory of certificates, the practical methods to check expiry at scale, how to plug expiry monitoring into your existing alerting stack, and how to design an SSL renewal strategy that balances free automation with commercial certificates where they’re truly needed. The goal: a setup where SSL just renews quietly in the background, and the only time you hear about certificates is in routine reports—not in a rush when a browser starts complaining.

Why SSL Expiry Monitoring Becomes Hard with Many Domains

When you only manage one or two sites, watching certificate expiry is easy: your browser shows the date, and your CA sends reminder emails. But as the number of domains, environments, and providers increases, this model breaks down quickly.

Typical real‑world complications include:

• Many domains and subdomains: main site, blog, shop, staging, admin, API, static assets, regional versions, and landing pages all on separate hostnames.
• Multiple infrastructures: some sites on shared hosting, some on VPS or dedicated servers, others behind a CDN or third‑party SaaS landing page builder.
• Different certificate types and CAs: Let’s Encrypt DV for blogs, SAN or wildcard certificates for e‑commerce, and possibly OV/EV certificates for corporate sites.
• Shorter validity periods: modern public certificates are limited to 398 days, and ACME‑based certificates (e.g. Let’s Encrypt) are commonly 90 days.

On top of this, SSL is only one part of your security posture. You may already be tracking SSL/TLS security updates on your servers, HTTP security headers, DDoS protection, and more. The key is to put SSL expiry in the same category: something you monitor continuously and treat as a standard piece of infrastructure hygiene, not an ad‑hoc task.

Step 1: Build a Clean Inventory of Domains and Certificates

Before you automate anything, you need to know what you actually have. In almost every SSL audit we’ve seen, the first surprises come from missing domains or forgotten subdomains.

Where to Collect Domain and Certificate Data

Use multiple sources to build your inventory:

• DNS zones: Export all A, AAAA, and CNAME records from your DNS providers and list every hostname that should be served over HTTPS.
• Web server configs: Parse Nginx, Apache or LiteSpeed configs on your VPS/dedicated servers to list every server_name (Nginx) or ServerName/ServerAlias (Apache).
• Control panels: From cPanel/DirectAdmin/Plesk, export domain lists for each account. This is especially important for agencies and resellers.
• CDN / reverse proxies: For domains terminating SSL at a CDN or WAF, export hostnames from those dashboards as well.
• Certificate authority dashboards: Commercial CAs often provide an account‑level view of all issued certificates.

Make It a Single Source of Truth

Once collected, normalize this into a single inventory (spreadsheet, Git repo, or config database) with at least:

• Hostname (e.g. www.example.com)
• Environment (prod / staging / dev)
• Hosting location (shared hosting, VPS, dedicated, colocation, CDN, third‑party SaaS)
• Certificate type (DV/OV/EV, wildcard/SAN/single‑name, Let’s Encrypt vs commercial)
• Where SSL terminates (origin server vs CDN vs load balancer)
• Responsible team or owner (marketing, e‑commerce, IT, external agency)

For agencies, this inventory sits nicely next to your existing hosting and DNS audit checklist when onboarding new clients. Keep it under version control if possible, so changes over time are tracked like code.

Step 2: Technical Methods to Check SSL Expiry at Scale

With a clear host list, the next challenge is: how do you check expiry dates automatically and reliably?

Method 1: Query Certificates Over the Network

The most robust method is to perform a real TLS handshake to each hostname and read the certificate’s Not After date. On Linux, you can use openssl directly:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null 
  | openssl x509 -noout -dates

For a scriptable, multi‑domain setup, wrap this into a loop and parse the output:

#!/usr/bin/env bash
host=$1
expiry_date=$(echo | openssl s_client -servername "$host" -connect "$host":443 2>/dev/null 
  | openssl x509 -noout -enddate | cut -d= -f2)
expiry_ts=$(date -d "$expiry_date" +%s)
now_ts=$(date +%s)
days_left=$(( (expiry_ts - now_ts) / 86400 ))

echo "$host: $days_left days left"

This approach has several advantages:

• It tests the “real” certificate users see (including CDN or load balancer termination).
• It catches misconfigurations (wrong certificate served for a hostname).
• It works regardless of which ACME client or CA you’re using.

Method 2: Read Certificates From the File System

On servers you control (VPS, dedicated or colocation), you can read expiry directly from certificate files:

openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem -noout -enddate

This is useful if SSL terminates only at your origin and isn’t fronted by a CDN. It’s also convenient to build local checks that run as part of server health scripts, alongside CPU, disk and memory metrics. If you’re already following a stack like we describe in our Prometheus + Grafana VPS monitoring playbook, adding certificate expiry as another metric is straightforward.

Method 3: Use Monitoring Tools and Exporters

For larger environments, you may prefer dedicated exporters:

• Prometheus exporters: There are SSL/TLS exporters that expose ssl_cert_not_after metrics per hostname, which you can alert on from Grafana or Alertmanager.
• Uptime monitoring tools: Many uptime platforms can warn when certificates near expiry, together with HTTP/HTTPS availability checks, similar to the approach we describe in our website uptime monitoring and alerting guide.
• Control panel notifications: cPanel/DirectAdmin AutoSSL can send expiry or renewal failure emails, but they’re often too noisy to scale alone.

The best pattern is usually a hybrid: use your own network‑level checks for critical domains and let external tools provide a second independent signal.

Step 3: Build an Automated SSL Expiry Monitoring Pipeline

Now that you know how to check a single certificate, the next step is to turn it into a pipeline that runs regularly and alerts the right people.

1. Store Your Host List in a Machine‑Readable Format

Convert the inventory into a simple file format that your scripts and monitoring can read easily, such as CSV or YAML:

# hosts.csv
hostname,env,owner
www.example.com,prod,marketing
api.example.com,prod,backend
shop.example.com,prod,ecommerce
blog.example.com,staging,marketing

Or YAML/JSON if you prefer more structure.

2. Schedule Regular Checks

On a monitoring VPS or management server (we often recommend a small dedicated VPS for this kind of tooling), run your expiry checks via cron or systemd timers:

• Run once per day (or twice a day for critical environments).
• Parse each hostname, calculate days until expiry, and classify it into buckets: OK (> 30 days), warning (30–15 days), critical (< 15 days).

3. Send Alerts to the Right Channels

How you alert depends on your team size and tooling:

• Email reports: A daily summary listing domains below specific thresholds.
• Chat notifications: Post to Slack/Teams/Discord when a certificate enters a critical window.
• Monitoring dashboards: If you already use Prometheus/Grafana, push metrics and define alerts there.

A simple pattern that works well in smaller teams is: daily email summary for everything expiring in <= 30 days, plus an immediate high‑priority alert if any production domain falls below 7 days.

4. Separate “Automated” and “Manual” Certificates

In your reports, distinguish between:

• Certificates managed by ACME automation (Let’s Encrypt, ZeroSSL, etc.). These should auto‑renew; an approaching expiry usually indicates a configuration or DNS/HTTP validation problem.
• Manually managed commercial certificates (OV/EV, special SANs). These require calendar‑based renewals, purchase orders, or paperwork.

For ACME‑managed domains, investigate any certificate with < 15 days left. For manually managed domains, start renewal processes early (at least 30–45 days before expiry) to leave time for validation and approvals.

Step 4: Automating SSL Renewal Across Many Domains

Monitoring expiry is only half the story. The real win comes when renewals happen automatically so that your monitoring pipeline mostly acts as a safety net.

Let’s Encrypt and ACME Automation

For most DV (Domain Validation) use cases, Let’s Encrypt or similar ACME CAs are ideal: they are free, widely trusted, and built for automation. We’ve covered the ecosystem and new features in detail in our article on innovations in SSL certificate automation you should be using now.

Key concepts:

• ACME protocol: Standard API for requesting and renewing certificates.
• HTTP‑01 challenge: Proves control over a domain via a HTTP file under /.well-known/acme-challenge/.
• DNS‑01 challenge: Proves control via a TXT record; ideal for wildcards and multi‑tenant SaaS.

Automation Options by Hosting Type

How you implement ACME automation depends on where you host.

• Shared hosting at dchost.com: Our shared and many managed hosting plans provide free Let’s Encrypt SSL with automatic issuance and renewal via the control panel. Once enabled for a domain, certificates renew in the background without manual steps. We explain why this matters in our guide on why free SSL with Let’s Encrypt matters and how automatic renewal works on cPanel/DirectAdmin.
• VPS/dedicated/colocation: Install an ACME client such as certbot or acme.sh and configure it to request certificates for your domains, then reload Nginx/Apache after successful renewals.
• Multi‑tenant SaaS with custom domains: Use DNS‑01 ACME flows and automated DNS APIs to handle Bring‑Your‑Own‑Domain at scale, as we describe in our guide to scaling auto‑SSL in multi‑tenant SaaS.

Practical Tips for Robust ACME Automation

• Always test in staging first: Many CAs provide staging endpoints with no rate limits; use them when scripting new flows.
• Handle web server reloads safely: After renewal, gracefully reload Nginx/Apache (e.g. nginx -s reload or systemctl reload nginx) instead of restarting to avoid downtime.
• Use DNS APIs for DNS‑01: For wildcard and multi‑tenant flows, integrate your ACME client with your DNS provider’s API so TXT records are created automatically.
• Plan for CA outages or rate limits: For heavy multi‑domain setups, consider a backup CA and a strategy like the one we describe in our redundant ACME automation playbook with acme.sh fallback.

Step 5: Designing a Renewal Strategy: Free vs Commercial, SAN vs Wildcard

Not every certificate should be the same. A good renewal strategy balances automation and compliance.

Where Free DV Certificates Shine

Let’s Encrypt‑style DV certificates are perfect for:

• Blogs, marketing sites, and landing pages.
• APIs and microservices where trust is based on DNS, not company identity.
• Staging and test environments.
• Most e‑commerce stores where PCI‑DSS requirements focus on TLS versions and ciphers, not EV bar presence.

We compare this in detail in Let’s Encrypt vs commercial SSL: choosing the right certificate for e‑commerce and enterprise. For many setups, DV + strong TLS configuration is enough.

When You Still Need Commercial Certificates

Consider OV/EV or specialized commercial certificates when:

• You need organization or extended validation for regulatory or contractual reasons.
• You’re using advanced features like certain hardware appliances that only integrate with specific CAs.
• You require large SAN certificates that bundle many hostnames in one certificate with a commercial support SLA.

In those cases, put renewal dates into your general contract/calendar system and still monitor expiry externally—don’t rely solely on vendor emails.

Wildcard vs SAN (Multi‑Domain) Certificates

For infrastructures with many subdomains or brands, choosing between wildcard and SAN certificates is crucial. Our article on wildcard SSL vs SAN certificates for e‑commerce setups walks through this in detail, but at a high level:

• Wildcard (*.example.com): Great when you control all subdomains in one environment and want simpler issuance and renewal. Typically requires DNS‑01 challenges for ACME.
• SAN (multi‑domain): Useful for a fixed list of hostnames across brands or environments, but changes require re‑issuing the certificate.

Your monitoring pipeline doesn’t change much between the two; what changes is the number of hostnames covered by each certificate and how often those host lists change.

Step 6: Ownership, Access and Disaster Scenarios

SSL expiry issues are often not technical but organizational. To avoid surprises, treat SSL like any other shared infrastructure component.

Define Clear Ownership

For each group of domains, define:

• A primary technical owner (team or person).
• An escalation path (who gets alerted if renewals fail).
• Where ACME accounts, API credentials, and commercial CA logins are stored (ideally in a password manager or secret management system).

Avoid personal accounts with no backup; use shared/team accounts where possible and document the process in your internal runbooks.

Plan for Migration and Disaster Recovery

SSL and domains often cross organizational boundaries, especially during migrations or mergers. When moving hosting (for example, consolidating sites onto a new dchost.com VPS or dedicated server), include SSL in your migration checklist:

• Export existing certificates and chain files if you must reuse them.
• Recreate ACME automation on the new servers and test renewals.
• Verify HTTP‑01 or DNS‑01 challenges still work after DNS changes.
• Run full post‑migration checks for mixed content and HTTPS redirects.

If you follow a structured migration plan like in our guides on full HTTPS migration with 301 redirects and HSTS or zero‑downtime hosting migrations, SSL becomes just another checkbox instead of a risk factor.

Example Strategies for Different Teams

1. Digital Agency with 80+ Client Domains

An agency often has a mix of clients on shared hosting, managed WordPress, and VPS stacks.

• Use the agency’s internal Git repo as the master domain inventory.
• Enable AutoSSL / Let’s Encrypt for all domains on shared hosting accounts (including those at dchost.com).
• For VPS clients, standardize on a single ACME client (e.g. acme.sh) and a common Nginx/Apache configuration pattern.
• Run a centralized expiry check from a small monitoring VPS that queries each hostname over the network and sends a daily report.
• For premium or regulated clients using commercial OV/EV SSL, store contract and renewal dates next to the inventory file and set calendar reminders 60 days before expiry.

2. SaaS Platform with Bring‑Your‑Own‑Domain

A SaaS product allowing customers to map their own domains (e.g. store.customer.com pointing to your platform) must handle certificates programmatically.

• Use DNS‑01 ACME challenges with your DNS provider APIs or client‑side DNS instructions.
• Implement auto‑issuance when a customer connects a new domain, and auto‑renew via scheduled jobs.
• Keep a database table with each custom domain, its certificate status, and next renewal date.
• Expose certificate health in your internal monitoring dashboards and alert if any certificate is < 15 days from expiry.
• Follow the architecture principles in our article on Bring‑Your‑Own‑Domain with automatic SSL at SaaS scale.

3. Corporate IT with Mixed On‑Prem and Hosted Infrastructure

Corporate environments usually have legacy systems, on‑prem load balancers, and newer workloads on VPS/dedicated hosting.

• Perform a one‑time discovery of certificates on all load balancers, web servers, and proxies.
• Use commercial certificates where required by policy, and DV/ACME for the rest.
• Standardize monitoring: one expiry checker that hits every public hostname, regardless of where it’s hosted.
• Integrate SSL alerts into the same NOC/SOC tooling used for uptime and security alerts.

How dchost.com Fits Into Your SSL Monitoring and Renewal Strategy

At dchost.com we design our services so that SSL is a solved problem, not a constant manual chore.

• Shared hosting and reseller plans: Free Let’s Encrypt SSL is available for most domains, with automatic issuance and renewal via the control panel. You can map multiple domains and subdomains without worrying about buying separate certificates for each.
• VPS and dedicated servers: You have full root access to run your preferred ACME client, configure Nginx/Apache or reverse proxies, and integrate with your monitoring stack. Combining this with the approaches from our VPS monitoring and alerting guide gives you end‑to‑end visibility.
• Colocation: If you host your own hardware with us, our network and data center environment are ready for modern TLS, HTTP/2, and HTTP/3, which we explored in our article on how HTTP/2 and HTTP/3 affect SEO and Core Web Vitals from the hosting side.

Whichever option you choose, the core ideas in this guide stay the same: keep a clean inventory, automate renewals wherever possible, continuously monitor expiry from the user’s perspective, and keep organizational ownership clear. Once those are in place, SSL certificates become a quiet, reliable part of your infrastructure instead of a recurring source of last‑minute firefights.

If you want to consolidate domains or move existing sites onto an infrastructure where SSL automation and monitoring are easier to manage, our team at dchost.com can help you design the right mix of shared hosting, VPS, dedicated servers or colocation to match your portfolio size and compliance needs.