Traefik SSL Certificate Monitoring: Track Let's Encrypt Renewal Failures

This script iterates over all resolvers in acme.json and prints days remaining for each domain — sorted by resolver, with WARN for anything under 30 days.

Check the live TLS endpoint Traefik is serving

Parsing acme.json tells you what Traefik has stored. Checking the live endpoint tells you what it's actually serving — which differs when Traefik has loaded a stale cert into memory or when a CDN sits in front:

# Check what Traefik is actually serving to the world
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null \
  | openssl x509 -noout -enddate -issuer

# Days remaining
expiry=$(echo | openssl s_client -connect yourdomain.com:443 \
  -servername yourdomain.com 2>/dev/null \
  | openssl x509 -noout -enddate | cut -d= -f2)
echo $(( ($(date -d "$expiry" +%s) - $(date +%s)) / 86400 )) days remaining

Common Traefik Let's Encrypt renewal failure modes

Rate limiting

Let's Encrypt imposes rate limits: 50 certificates per registered domain per week, 5 duplicate certificates per week, and 5 failed validations per hostname per hour. If you redeploy frequently, reconfigure routers often, or run many subdomains, you can hit these limits. When a rate limit is hit, Traefik logs an error but continues serving the expiring cert:

# Check Traefik logs for rate limit errors
docker logs traefik 2>&1 | grep -i "rate\|too many\|urn:ietf:params:acme:error"

# For systemd deployments
journalctl -u traefik --since "7 days ago" | grep -i "acme\|renew\|error"

HTTP-01 challenge failures

Traefik handles HTTP-01 challenges by temporarily serving a validation token on port 80. This fails when:

• Port 80 is blocked by a firewall rule or security group
• A load balancer or CDN is intercepting port 80 traffic before it reaches Traefik
• Traefik itself is behind another reverse proxy that doesn't pass the /.well-known/acme-challenge/ path
• The domain's DNS points to a different IP than the server running Traefik

# Test that the ACME challenge path is reachable
curl -I http://yourdomain.com/.well-known/acme-challenge/test-token

DNS-01 challenge failures

For wildcard certs or environments where HTTP-01 is impractical, Traefik supports DNS-01 challenges via provider APIs. These fail when:

• The DNS provider API key expires or is rotated
• The DNS provider's API is rate-limited or temporarily unavailable
• DNS propagation takes longer than the ACME server's polling timeout

# Check for DNS challenge errors in Traefik logs
docker logs traefik 2>&1 | grep -i "dns\|challenge\|propagation"

acme.json permissions

Traefik requires acme.json to have permissions of 600. If the file permissions change (common after volume remounts or container restarts with different UID mappings), Traefik may refuse to write renewal updates:

ls -la /letsencrypt/acme.json
# Should show: -rw------- (600)
chmod 600 /letsencrypt/acme.json

Container restart losing ACME state

If acme.json is stored inside the container rather than in a mounted volume, every container restart means Traefik must re-issue all certificates from scratch. In a clean environment this works. During a Let's Encrypt rate limit window, it means all domains go without valid certs until the window expires:

# Verify the acme.json volume mount in your compose config
docker inspect traefik | python3 -m json.tool | grep -A5 "Mounts"

Traefik SSL monitoring in Kubernetes

When using Traefik in Kubernetes (via Helm or the official operator), certificates are stored in Kubernetes Secrets rather than acme.json. Check them with:

# List TLS secrets used by Traefik IngressRoute resources
kubectl get ingressroute --all-namespaces -o json \
  | python3 -c "
import json, sys
data = json.load(sys.stdin)
for item in data['items']:
    for route in item.get('spec', {}).get('tls', {}).get('secretName', []):
        ns = item['metadata']['namespace']
        print(f'{ns}/{route}')
"

# Check expiry of a specific TLS secret
kubectl get secret traefik-tls -n default \
  -o jsonpath='{.data.tls\.crt}' | base64 -d \
  | openssl x509 -noout -enddate

What Traefik SSL monitoring should look like

Traefik's built-in automation is genuinely useful, but a complete monitoring setup adds an independent external check:

• External TLS handshake check — verifies what visitors see, independent of Traefik's internal state
• Alerts at 30, 14, 7, and 1 day — enough runway to diagnose and fix renewal failures before expiry
• Coverage for all domains Traefik manages — not just the primary hostname
• Independent of Traefik's health — if Traefik itself is degraded, external monitoring still checks the endpoint

The goal is a second opinion on what's actually being served — one that runs whether Traefik is logging errors or not.

Check your Traefik SSL certificates now

Automated Traefik SSL monitoring

SSLWatch monitors SSL certificate expiry for any HTTPS endpoint — including all domains your Traefik instance manages — with external TLS checks and email alerts at 30, 14, 7, and 1 day before expiry. It works independently of Traefik's renewal process, so you get advance warning even when Traefik's ACME integration fails silently.