SSL Certificate Monitoring: Never Let Your Cert Expire Again

An expired SSL certificate doesn't just break HTTPS — it completely blocks users from accessing your site. Modern browsers show an alarming "Your connection is not private" warning with no obvious way to proceed. Most users leave immediately. SSL certificate expiry is one of the most preventable causes of complete service outages, yet it continues to affect even major organizations regularly.

Why SSL Certificates Expire (and How Teams Miss It)

SSL certificates are valid for a fixed period — in 2026, the maximum validity period is 398 days (about 13 months). Certificates from Let's Encrypt expire every 90 days.

Teams miss expiry because:

Email notification rot: Domain registrars and CAs send expiry reminders to the technical contact email registered years ago — an email address that might belong to a former employee or be checked infrequently.

Multi-certificate complexity: Large organizations manage dozens or hundreds of certificates across multiple domains, subdomains, and environments. Manual tracking doesn't scale.

Auto-renewal failures: Let's Encrypt's Certbot is supposed to automatically renew certificates, but auto-renewal can fail silently due to:

• Port 80 being blocked by firewall rules
• DNS validation challenges failing
• Rate limit violations
• Server storage space issues
• Process not running at renewal time

Wildcard certificates: A wildcard certificate (*.yoursite.com) covers all subdomains but has a single expiry date. When it expires, it takes down all subdomains simultaneously.

How SSL Certificate Monitoring Works

AzMonitor's SSL monitoring connects to your HTTPS endpoint and evaluates the certificate:

1. Establishes TLS connection to your domain
2. Reads the certificate presented by the server
3. Extracts expiry date from the certificate's validity period
4. Calculates days until expiry from the current date
5. Validates certificate chain (is it signed by a trusted CA? Is the chain complete?)
6. Checks hostname matching (does the certificate cover the requested hostname?)
7. Alerts based on configured thresholds

Multi-Tier Alert Configuration

The right approach uses multiple alert tiers with increasing urgency:

| Alert Tier | Days Before Expiry | Action Required | Channels | |-----------|-------------------|-----------------|---------| | Informational | 60 days | Start renewal process | Email | | Warning | 30 days | Renew immediately | Email + Slack | | Urgent | 14 days | Escalate if not renewed | Slack + SMS | | Critical | 7 days | Emergency renewal | SMS + Phone | | Emergency | 2 days | All-hands incident | SMS + Phone + Page |

# AzMonitor SSL monitoring configuration
ssl_monitors:
  - domain: yoursite.com
    alerts:
      - days_before_expiry: 60
        severity: info
        channels: [email]
      - days_before_expiry: 30
        severity: warning
        channels: [slack, email]
      - days_before_expiry: 14
        severity: critical
        channels: [slack, sms]
      - days_before_expiry: 7
        severity: emergency
        channels: [pagerduty, sms]

What to Monitor Beyond Just Expiry

SSL monitoring should cover more than just the expiry date:

Certificate Chain Validity

A certificate signed by a trusted CA is not useful if the intermediate CA chain is broken. Browsers require the complete chain from your certificate to a trusted root CA.

What can go wrong: Servers sometimes serve only the end-entity certificate without the intermediate certificates. Some browsers maintain local caches of intermediate certificates and work anyway; others fail immediately.

Monitor the complete chain — AzMonitor verifies the full chain is present and trusted on every check.

Hostname Matching

Your certificate must include the hostname being requested. Common mismatches:

• Certificate issued for www.yoursite.com but accessed as yoursite.com
• Certificate for yoursite.com but API is at api.yoursite.com (requires wildcard or SAN)
• Certificate for old domain after a domain migration

TLS Protocol Version

TLS 1.0 and 1.1 are deprecated and disabled in modern browsers. If your server only supports these old protocols, some clients can't connect.

Monitor that your servers support TLS 1.2 (minimum) and TLS 1.3 (preferred), and don't accept connections downgraded to deprecated protocol versions.

Certificate Transparency Logs

All public certificates must be logged in Certificate Transparency (CT) logs. Monitoring CT logs can reveal:

• Certificates issued for your domain by unauthorized CAs (potential attack)
• Shadow IT certificates (someone issued a cert for your domain you don't know about)

Cipher Suite Configuration

Weak cipher suites (RC4, 3DES, export ciphers) should not be supported. Monitor that your server's cipher suite configuration excludes deprecated algorithms.

Setting Up Comprehensive SSL Monitoring

Don't just monitor your primary domain — cover all endpoints that use HTTPS:

Priority 1 — Monitor immediately:

• yoursite.com
• www.yoursite.com
• api.yoursite.com
• app.yoursite.com

Priority 2 — Monitor with 5-minute intervals:

• admin.yoursite.com
• mail.yoursite.com
• All customer-facing subdomains

Priority 3 — Monitor periodically:

• Staging environments
• Partner API endpoints you serve via HTTPS

AzMonitor adds SSL monitoring automatically when you add an HTTPS check — expiry monitoring comes with every HTTP monitor.

Responding to SSL Expiry Alerts

When a 30-day alert fires, the response process is:

1. Identify the certificate: Which domain, which server, which CA issued it?
2. Check auto-renewal status: Is Certbot/ACME configured? Did the last auto-renewal succeed?
3. Renew manually if needed:

   # Let's Encrypt / Certbot renewal
   certbot renew --force-renewal -d yoursite.com
   
   # Or if using ACME manually
   acme.sh --renew -d yoursite.com
   

4. Verify renewal succeeded: Check the new certificate's expiry date
5. Document root cause: Why did auto-renewal fail? Fix the underlying issue.

SSL Monitoring for Multi-Environment Setups

Monitor all environments, not just production:

Production:  yoursite.com       → Alert at 30 days
Staging:     staging.yoursite.com → Alert at 14 days
Development: dev.yoursite.com   → Alert at 7 days (lower priority)
Partners:    partner.yoursite.com → Alert at 30 days

Staging certificate expiry is a common source of deployment failures — "why can't I deploy to staging?" is often a TLS certificate issue.

SSL monitoring is included in every AzMonitor plan — your HTTPS monitors automatically track certificate expiry. Start monitoring your SSL certificates and eliminate the risk of expiry-caused outages.

See also: domain expiry monitoring — domain expiry causes the same visible symptoms as SSL expiry but requires different monitoring.