"We use Let's Encrypt with auto-renewal, certs can't expire." I've heard this phrase dozens of times — usually from teams whose certificate just expired. Auto-renewal is great technology. But it breaks. Your DNS provider changed, your firewall updated, certbot got old, someone deleted the cron job. When? auto-renewal silently stops working, you find out at 3 AM when all traffic goes down.
SSL monitoring is insurance against this scenario. Takes 2 minutes to set up, runs for years without attention, and prevents one of the most frustrating types of downtime — because this is downtime that's 100% preventable.
Why SSL Certificates Expire Despite Automation
Let's Encrypt issues certificates on 90 days and recommends renewing every 60. Automated tools (certbot, acme.sh, Caddy) usually handle it. But there are ten reasons, by which automation silently breaks:
DNS verification stopped working. You moved DNS to Cloudflare, but certbot is configured to verify through the old DNS provider. Challenge fails, certificate won't renew. Error in certbot logs — but who reads certbot logs every day?
HTTP challenge is blocked. Firewall, WAF or CDN blocks requests to /.well-known/acme-challenge/. Or the nginx config was rewritten and someone forgot to add location for ACME. Certificate won't renew.
Certbot is outdated. After OS update, certbot can break: Python version incompatibility, outdated dependencies, changed Let's Encrypt API. Ubuntu 22 → 24 upgrade — classic moment when certbot silently stops working.
Cron/systemd timer was deleted. Certbot runs on schedule. If someone cleaned the crontab or reinstalled the system without restoring timers — updates simply don't run.
Wildcard certificate with DNS-01. Wildcard certificates require DNS-01 challenge. For this, certbot must be able to create TXT records via DNS provider API. API key rotation, plan change, permission revocation — and renewal breaks.
Common pattern: auto-renewal breaks silently. No push notifications. Error is logged to a file nobody reads. And after 30-60 days the certificate expires and everything breaks. SSL monitoring breaks this cycle — you get an alert 30 days before the issue.
What SSL Monitoring Checks
Good SSL monitoring — isn't just "certificate expires in N days". It checks the entire certificate chain and TLS configuration:
Certificate Expiration
Core check. Monitoring records the expiration date and sends an alert, when less than the configured threshold remains. Recommended thresholds: 30 days (early warning), 14 days (action needed), 7 days (emergency). In AtomPing threshold is configured in alert policy — from 1 to 90 days.
Certificate Chain
Your domain's certificate is signed by an intermediate CA, which is signed by a root CA. If the intermediate certificate is missing from the server response — some clients (especially mobile apps and old browsers) can't verify trust and will refuse to connect. Notably, Chrome on desktop might work (it can "fetch" the chain), but Safari on iOS can't.
SSL Checker from AtomPing checks completeness chain for free — can be used for one-off checks, while TLS monitoring does it automatically on every check.
Hostname Match
The certificate must cover the exact domain, where it's installed. Withcertificate for example.com doesn't cover api.example.com, if there's no SAN (Subject Alternative Name) or wildcard *.example.com. When? moving to a subdomain, this is often overlooked.
TLS Protocol Version
TLS 1.0 and 1.1 are deprecated. All modern browsers require TLS 1.2+. If your server still supports TLS 1.0 — that's both a security risk and potential compatibility issue. PCI DSS compliance requires minimum TLS 1.2 since 2018.
How to Set Up SSL Monitoring in 5 Minutes
Setting up SSL monitoring — is one of the quickest and most useful infrastructure security tasks. Here's the step-by-step process:
Step 1. List all your domains. All domains where your services run: main site, API, CDN, a status page, admin panel. Don't forget subdomains — each might have its own certificate.
Step 2. Add TLS Checks. In AtomPing create TLS-monitoring for for each domain. It checks certificate validity, chain completeness and days until expiration on every check cycle.
Step 3. Set Alert Threshold. Set 30 days as standard threshold. For wildcard certificates or those renewed manually — 45 days for more buffer.
Step 4. Connect Alert Channels. SSL alerts should go to the same channel, as uptime alerts: Slack, Telegram, email. Make sure the alert reaches the person, who can renew the certificate.
Step 5. Run a Test Check. Run SSL Checker for each domain on right now. Make sure the chain is complete, hostname matches, protocol is TLS 1.2+. If there are issues — fix them before monitoring starts alerting.
SSL Monitoring for APIs and Microservices
If you have a microservice architecture, you might have dozens of SSL certificates: each service with its own domain or subdomain. Internal services on *.internal.company.com, API gateway on api.company.com, webhook receiver on hooks.company.com.
Special risk: internal certificates. Internal services often use self-signed certificates or internal CA. They can't be monitored with regular external SSL checkers. Two approaches:
Variant 1: Single wildcard. Use one wildcard-certificate (*.company.com) for all public services. One certificate = one monitoring point. Renews once, covers all subdomains. Downside — if compromised, all services are affected.
Variant 2: Per-service certificates with centralized monitoring. Each service gets its own certificate (via cert-manager in Kubernetes, for example). Monitoring for each — through AtomPing TLS checks. More certificates = more monitoring points, but better isolation.
Real Cases: When? SSL Monitoring Saved the Day
Case 1: Cloudflare → DNS migration. Company moved DNS from GoDaddy to Cloudflare. Certbot was configured for DNS-01 challenge via GoDaddy API. After 60 days the certificate didn't renew. SSL monitoring sent an alert 30 days before expiration — team had time to reconfigure certbot for Cloudflare API.
Case 2: Intermediate certificate removal. CDN provider updated their intermediate certificate and forgot to add it to the bundle. Desktop browsers worked (they cache intermediate certificates), but mobile clients started failing with SSL errors. AtomPing's TLS monitoring noticed the incomplete chain 5 minutes after the change.
Case 3: Kubernetes cert-manager quota. cert-manager in Kubernetes hit Let's Encrypt rate limit (50 certificates per registered domain per week). New services couldn't get certificates, and existing ones started expiring. SSL monitoring showed 5 certificates approaching expiry simultaneously — which pointed to the cert-manager issue.
SSL Security Checklist
Go through this list for each production domain:
1. Certificate is valid and won't expire in the next 30 days.
2. Certificate chain is complete — includes all intermediate certificates.
3. Hostname in certificate matches the domain (including www and subdomains).
4. Minimum protocol version is TLS 1.2. TLS 1.0 and 1.1 are disabled.
5. Auto-renewal is configured and working (check the last renewal log).
6. SSL monitoring is enabled with alerts 30 days before expiry.
7. HSTS is enabled (Strict-Transport-Security header).
8. HTTP to HTTPS redirect is configured for all domains.
SSL monitoring — is the case where 2 minutes of setup now save hours of emergency work later. Set up TLS checks for all your domains today — and cross "expired certificate" off the list of possible downtime causes forever.
FAQ
What is SSL certificate monitoring?
SSL certificate monitoring is the automated process of tracking your SSL/TLS certificates for expiration dates, configuration issues, and chain validity. It alerts you days or weeks before a certificate expires, so you can renew it before your site becomes inaccessible or shows security warnings to visitors.
How often should I check my SSL certificates?
Check certificate expiration daily. Most monitoring tools, including AtomPing, run SSL checks alongside your regular uptime monitors — so every time your site is checked (every 1-5 minutes), the certificate validity is also verified. Expiry alerts are typically sent once when the certificate enters the warning window (e.g., 30 days before expiry).
Can Let's Encrypt certificates expire if I have auto-renewal?
Yes, absolutely. Auto-renewal fails more often than you'd expect. Common causes: DNS verification issues (changed DNS provider), firewall blocking the ACME challenge, certbot version incompatibility after OS update, expired API credentials for DNS-based validation. This is exactly why monitoring is essential even with auto-renewal.
What happens when an SSL certificate expires?
Browsers show a full-page security warning that most users won't click through. API clients and mobile apps refuse to connect entirely — they don't show a 'proceed anyway' option. Webhooks from services like Stripe stop delivering. Search engines may demote your site. In short: an expired certificate is effectively a full outage for most of your traffic.
How many days before expiry should I get alerted?
Set up three alert thresholds: 30 days (first warning — time to investigate if auto-renewal is working), 14 days (urgent — renew manually if auto-renewal hasn't kicked in), and 7 days (critical — drop everything and fix this). AtomPing lets you configure the expiry threshold in your alert policy settings.
Does SSL monitoring check more than just expiration?
Good SSL monitoring checks several things: certificate expiration date, chain completeness (all intermediate certificates present), hostname match (certificate covers your domain), protocol version (TLS 1.2+ required), and cipher strength. AtomPing's TLS monitoring verifies the full chain and reports days until expiry.