SSL Certificate Monitoring for WordPress Agencies

The One Line a WordPress Maintenance Provider Should Never Say

"Sorry, the SSL certificate expired."

For agencies running WordPress maintenance services across multiple clients, an SSL expiry incident is one of the most preventable — and most embarrassing — failures possible. The assumption that Let's Encrypt auto-renewal "just works" is exactly what causes 2 AM emergencies.

This article covers how to centralize SSL certificate expiry management across all client sites, detect renewal failures before they cause outages, and fold SSL monitoring into your maintenance service offer. For the broader context of adding uptime monitoring to WordPress maintenance plans, see "Add Uptime Monitoring to WordPress Maintenance Plans." For a general guide on SSL monitoring, see "How to Prevent SSL Certificate Expiry Disasters."

WordPress-Specific SSL Auto-Renewal Failure Patterns

General auto-renewal failure causes apply to any environment, but WordPress hosting adds several failure modes that are less obvious.

Failure Modes Specific to WordPress

1. Shared hosting auto-renewal is not global — it is per-domain

On shared hosting platforms, Let's Encrypt auto-renewal often requires enabling it per domain through a control panel, not as a global setting. Adding a new domain without toggling auto-renewal for that specific entry means the first renewal attempt will fail silently.

2. Server migrations do not carry over certbot configuration

When migrating a WordPress site to a new server, the focus is on files, database, and DNS. The certbot setup on the old server does not transfer automatically. The certificate may still be valid at migration time, but the next renewal attempt fails because certbot was never configured on the new server.

3. Caching plugins interfere with ACME challenges

W3 Total Cache, WP Super Cache, and similar plugins can cache the .well-known/acme-challenge/ path that Let's Encrypt uses for domain validation. When the ACME challenge URL returns a cached response instead of the expected challenge file, domain validation fails and renewal is blocked. Cache exclusion rules can also disappear after plugin updates.

4. WordFence blocks certbot requests

WordFence and similar security plugins may classify the certbot agent's HTTP requests as bot traffic and block them with a 403. Renewal that worked fine before a WordFence configuration change may silently start failing afterward.

# Check ACME challenge access in Nginx logs
grep "acme-challenge" /var/log/nginx/access.log | tail -20

# Look for 403 or 404 responses — these indicate a caching plugin or firewall is blocking certbot
# The challenge URL should return 200

Centralizing SSL Monitoring Across Client Sites with Miterl

Create SSL Monitors for Each Client Site

Miterl monitors SSL certificate expiry through a dedicated ssl monitor type. When a certificate's remaining days drop below the configured threshold, an alert fires to the contacts you specify (Slack, Chatwork, LINE, etc.).

# Create an SSL monitor for a WordPress client site
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Client A - SSL Certificate",
    "type": "ssl",
    "url": "https://client-a.com",
    "interval_seconds": 3600,
    "ssl_expiry_alert_days": 30,
    "alert_contact_ids": [1]
  }'

Setting ssl_expiry_alert_days to 30 triggers an alert when 30 days remain before expiry. The recommended setup for agencies is three thresholds: 30 days (schedule renewal), 14 days (confirm renewal is in progress), and 7 days (final escalation). Create a separate monitor for each threshold.

Bulk-Register Multiple Sites for SSL Monitoring

If you manage ten or more sites, a simple shell loop is faster than registering through the dashboard one at a time.

# Bulk-register multiple client sites for SSL monitoring
DOMAINS=(
  "client-a.com"
  "client-b.co.jp"
  "client-c.net"
)

for DOMAIN in "${DOMAINS[@]}"; do
  curl -X POST https://miterl.com/api/v1/monitors \
    -H "Authorization: Bearer YOUR_API_KEY" \
    -H "Content-Type: application/json" \
    -d "{
      \"name\": \"${DOMAIN} - SSL\",
      \"type\": \"ssl\",
      \"url\": \"https://${DOMAIN}\",
      \"interval_seconds\": 3600,
      \"ssl_expiry_alert_days\": 30
    }"
  echo "Registered: $DOMAIN"
  sleep 1
done

SSL Monitors and Uptime Monitors Are Separate — Set Up Both

SSL monitoring (type: ssl) and HTTP uptime monitoring (type: http) are independent monitor types. Set up both for each client domain.

If an SSL monitor reports down, the certificate has already expired or a certificate chain problem exists. This requires immediate action regardless of whether the alert threshold has been reached.

Using the Expiry Dashboard to Track All Certificate Dates

Miterl tracks the expires_at value for each SSL monitor and surfaces it in the expiry dashboard, giving you a single view of every client certificate and how many days remain.

# Retrieve expiry data for all SSL monitors via the API
curl -s "https://miterl.com/api/v1/monitors?per_page=100" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  | jq -r '.data[] | select(.type == "ssl") | "\(.name)\t\(.status)\t\(.expires_at)"'

Run this before preparing monthly maintenance reports to catch any certificates approaching expiry across all clients in a single command.

WordPress-Side Configuration to Prevent ACME Challenge Failures

Monitoring catches failures after they occur. These configuration steps reduce the frequency of renewal failures in the first place.

Exclude the ACME Challenge Path from Caching Plugins

In W3 Total Cache, WP Super Cache, WP Fastest Cache, or any similar plugin, add the following path to the cache exclusion list:

/.well-known/acme-challenge/

To set this at the web server level directly in WordPress .htaccess:

# Bypass cache for ACME challenge verification
<IfModule mod_rewrite.c>
  RewriteRule ^\.well-known/acme-challenge/ - [L]
</IfModule>

Verify certbot Auto-Renewal Periodically

# Test auto-renewal without actually renewing
sudo certbot renew --dry-run

# Check the systemd timer status
systemctl status certbot.timer

Running --dry-run monthly confirms that certbot can still complete the renewal process successfully. A clean dry-run result means the certificate will renew when the time comes.

Building SSL Monitoring into Your Maintenance Service Offer

SSL certificate monitoring is one of the easiest maintenance items to explain to clients — and one of the most persuasive for demonstrating proactive value.

Adding SSL Status to Monthly Reports

A single line in your monthly maintenance report turns invisible background work into visible client value:

SSL Certificate Status: Healthy (XX days remaining)
Next renewal scheduled: YYYY-MM

When nothing went wrong that month, this line proves why the maintenance contract exists.

Pricing SSL Monitoring as Part of WordPress Maintenance Plans

A rough guide for incorporating SSL monitoring into tiered maintenance pricing:

The value proposition is straightforward: the client is paying to not get a call from their customers about a broken padlock icon. For the broader framework of adding monitoring to WordPress maintenance pricing, see "Add Uptime Monitoring to WordPress Maintenance Plans."

Summary

Preventing SSL certificate expiry incidents across multiple WordPress client sites requires both a reliable renewal mechanism and independent monitoring that catches failures before clients notice.

• WordPress-specific failure modes include caching plugin interference with ACME challenges, security plugin blocks on certbot, and certbot configuration not surviving server migrations
• Create ssl type monitors in Miterl for each client site with 30-day, 14-day, and 7-day alert thresholds
• SSL monitors (type: ssl) and uptime monitors (type: http) are separate — configure both for every domain
• Use the expiry dashboard and the monitors API to pull all certificate dates into one view for monthly reporting
• Exclude .well-known/acme-challenge/ from caching plugins and run certbot renew --dry-run monthly to keep the renewal mechanism healthy

SSL monitoring is a low-effort, high-visibility maintenance item that clients understand immediately. Sign up for free to try it across your client sites. For full configuration details, see the documentation. Agency-specific scenarios are also covered in the use cases section.