Monitoring TLS Certificate Expiry

Static sites mostly get TLS for free: Cloudflare, Netlify, Vercel, GitHub Pages and Caddy all obtain and renew certificates without anyone touching them. That is precisely why expiry incidents still happen. When renewal is invisible, nobody notices when it stops working — a DNS record moved to a new provider, a CAA record added by the security team that does not list the platform's authority, an API token for a DNS challenge that expired, a forgotten subdomain still pointing at a server that was switched off. The first sign is readers seeing a full-page browser warning, often on a Saturday.

This guide sets up expiry and configuration monitoring for the domains behind a set of static sites: an inventory of every hostname, including forgotten ones, checks for expiry, coverage and chain, alert thresholds tied to renewal behaviour, and a test of the alerting itself. It is part of Monitoring Static Sites in Production, and complements Custom Domains and TLS on Cloudflare Pages.

Prerequisites

• A list of the organisation's domains and DNS provider access.
• An uptime or synthetic monitoring tool, or a scheduled CI job, to run checks.
• An alerting channel that reaches a person (not only a dashboard).

Step 1: Build the Hostname Inventory

The hostnames you know about are not the problem. The forgotten ones are. Certificate Transparency logs record every publicly trusted certificate issued for your domains, which makes them an excellent inventory source:

curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | jq -r '.[].name_value' | tr '[:upper:]' '[:lower:]' | sed 's/^\*\.//' | sort -u > ct-hostnames.txt
wc -l ct-hostnames.txt

For the organisation's five static sites, the known list had 14 hostnames. CT logs showed 41, of which 23 still resolved in DNS. Among them: an old beta-docs.example.com still serving a two-year-old copy of the documentation from a forgotten VM with a manually installed certificate expiring in 19 days, and two event microsites on a platform host whose custom domains had been removed from the platform but not from DNS.

The forgotten beta host was decommissioned and its DNS record removed; the microsite records were removed too, closing a subdomain takeover risk as well as an expiry risk.

Step 2: Check More Than the Date

For each hostname, a check connects with TLS SNI and inspects what is actually served:

check() {
  host=$1
  out=$(echo | timeout 10 openssl s_client -connect "$host:443" -servername "$host" -showcerts 2>/dev/null)
  end=$(echo "$out" | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
  days=$(( ( $(date -d "$end" +%s) - $(date +%s) ) / 86400 ))
  issuer=$(echo "$out" | openssl x509 -noout -issuer 2>/dev/null | sed 's/.*O = //;s/,.*//')
  san_ok=$(echo "$out" | openssl x509 -noout -ext subjectAltName 2>/dev/null | grep -qE "DNS:($host|\*\.${host#*.})" && echo yes || echo no)
  chain=$(echo "$out" | grep -c 'BEGIN CERTIFICATE')
  echo "$host days=$days issuer=\"$issuer\" san=$san_ok chain=$chain"
}
while read -r h; do check "$h"; done < hostnames.txt

The checks cover expiry, whether the certificate's names cover the hostname, the issuer (unexpected issuers suggest a hostname has moved to a different provider), and chain length (a single certificate without intermediates breaks some clients). Many uptime tools do this natively; the script is useful for a scheduled CI job and for understanding what the tools check.

Step 3: Thresholds That Match Renewal

Thresholds should reflect how the certificate is renewed. Platform-managed Let's Encrypt and Google Trust Services certificates are 90 days long and renew with about 30 days left. So:

• Warning at 21 days: a platform certificate at 21 days has missed its renewal window; investigate during working hours.
• Page at 7 days: renewal has failed repeatedly; someone must act today.
• Manually managed certificates (one-year): warning at 45 days, page at 14.

Alerts go to the team channel and, at the paging threshold, to the on-call rotation. A daily check is sufficient; certificates do not change by the hour.

Step 4: Monitor the Renewal Prerequisites

The most useful checks look at why renewal would fail, before it does. For each domain: CAA records must allow the issuers the platforms use (letsencrypt.org, pki.goog, digicert.com for some Cloudflare certificates, sectigo.com for others); DNS must still point at the platform; and API tokens used for DNS-01 challenges on self-hosted Caddy must be valid. A CAA check caught one change in advance: the security team added 0 issue "digicert.com" to the apex domain as a hardening step, which would have blocked Let's Encrypt renewals for three sites; the check flagged the missing issuers the same day.

dig +short CAA example.com
# 0 issue "letsencrypt.org"
# 0 issue "pki.goog"
# 0 issue "digicert.com"

Step 5: Test the Alert Path

An alert that has never fired may not work. The team keeps a test hostname with a deliberately short-lived certificate (issued with a 6-day validity from a private test setup, served on a staging VM, excluded from paging but included in warnings) so the warning path fires every week and proves the whole chain — check, threshold, notification — still works. When a notification integration broke after a chat tool migration, the weekly test caught it within days.

Beyond Certificates: The Rest of the TLS Picture

The same daily job checks two related properties that affect every reader. It records the negotiated protocol and cipher for each hostname, so a configuration change that disables TLS 1.3 or re-enables a legacy cipher is noticed; and it checks that HTTP requests redirect to HTTPS with a single hop, since a broken redirect after a platform migration can leave the plain-HTTP version serving content. For hostnames with HSTS, it verifies the header is present on the HTTPS response, because a site with HSTS preloaded and a broken certificate is unreachable rather than merely showing a warning, as described in Enabling HSTS and Preload Safely. These checks cost nothing extra — the connection is already open — and they have caught one regression: an nginx upgrade on a self-hosted mirror that reset its protocol list to a default without TLS 1.3.

Keep the hostname inventory in the repository as a plain text file, reviewed like code, so adding a new subdomain and adding its monitoring happen in the same pull request.

Measured Impact

Pitfalls & Rollback

• Monitoring only the apex. Subdomains, previews and asset hosts expire too.
• Trusting "managed" to mean "monitored". Managed renewal fails silently when DNS or CAA changes.
• Checking dates but not names or chains. A valid certificate for the wrong host is still an outage.
• Alerts that nobody receives. Test the alert path regularly.
• Rollback: monitoring changes nothing on the sites; checks can be removed at any time.

Conclusion

Automatic certificates removed the routine work of TLS, not the need to know when it fails. Inventory every hostname from Certificate Transparency logs, check expiry, names, issuer and chain daily, set thresholds that match renewal behaviour, watch the prerequisites that renewal depends on, and prove the alert path works. On these sites that found eighteen forgotten hosts and caught three renewal failures weeks before any reader would have seen a warning page.

FAQ

If certificates renew automatically, why monitor them?

Automatic renewal fails silently more often than people expect, because of DNS changes, firewall rules blocking validation, CAA records, expired API credentials for DNS challenges, or a hostname that moved to a different provider. Monitoring catches the failure while there are still weeks left to fix it.

How early should expiry alerts fire?

With 90-day certificates renewed around 30 days before expiry, alert when fewer than 21 days remain, and page someone at 7 days. If a certificate reaches 21 days without being renewed, automatic renewal has already failed at least once.

Which hostnames should be monitored?

Every hostname that serves the site or its assets, including apex and www, subdomains for docs, previews and status pages, custom domains on platform hosts, and any CDN or image hostnames. Certificate Transparency logs are a good source for finding forgotten ones.

What else besides expiry should be checked?

That the certificate covers the hostname, that the full chain is served, that it is issued by the expected authority, and that the TLS configuration still supports modern protocols. A valid but wrong or incomplete certificate breaks some clients just as badly as an expired one.

Related

• Parent: Monitoring Static Sites in Production — the monitoring setup.
• Uptime and Synthetic Checks for Static Sites — where these checks usually run.
• Enabling HSTS and Preload Safely — why a certificate failure is worse with HSTS.
• Serving a Static Site with Caddy — self-managed automatic certificates.
• security.txt and Disclosure for Static Sites — letting others report problems they find.