SSL Certificate Monitoring: Why Expiry Alerts Save You From Downtime

An expired SSL certificate turns your website into a warning page. Visitors leave, search rankings drop, and revenue stops. SSL certificate monitoring with automated expiry alerts is the simplest way to make sure that never happens. Here is how it works, what gets checked, and how to set it up.

The Cost of an Expired SSL Certificate

When an SSL certificate expires, browsers do not quietly let traffic through. They display a full-screen interstitial -- "Your connection is not private" in Chrome, "Warning: Potential Security Risk Ahead" in Firefox -- and most visitors will not click past it. They leave. They go to a competitor. And they may never come back.

The business impact is immediate and measurable:

• Lost revenue. For e-commerce sites, every minute of certificate downtime translates directly to abandoned carts and lost sales. A site doing $10,000/day in revenue loses roughly $7 per minute the warning page is displayed.
• Destroyed trust. Browser security warnings train users to associate your brand with danger. Even after you fix the certificate, the memory of that warning lingers.
• SEO penalties. Google has used HTTPS as a ranking signal since 2014. An expired certificate effectively takes your site offline from a crawler's perspective. Extended downtime leads to deindexing, and recovering search rankings takes far longer than renewing a certificate.
• Delayed incident detection. During the 2017 Equifax breach, an expired SSL certificate on an internal monitoring tool prevented the security team from inspecting network traffic for 19 months. The breach went undetected while 147 million records were exfiltrated.

Equifax is the most cited example, but it is far from the only one. Microsoft Teams went down for hours in February 2020 because of an expired certificate. Spotify suffered a widespread outage in 2020 from the same cause. LinkedIn, Cisco, and the UK government's gov.uk have all experienced certificate-related outages. In every case, the certificate had a known expiration date. The failure was not technical -- it was operational. Nobody was watching.

Why Certificates Still Expire Unexpectedly

If every certificate has a fixed expiration date, why do they still catch teams off guard? Because the operational reality of managing certificates across a production environment is full of failure modes that a calendar reminder does not solve.

• Let's Encrypt 90-day cycles. Short-lived certificates are more secure in theory, but they demand reliable automation. A 90-day renewal window means four opportunities per year for something to break -- per domain.
• Auto-renewal failures. Certbot or ACME clients depend on cron jobs, DNS validation, and web server configurations. A server migration that changes the document root, a DNS provider API change, a misconfigured firewall rule blocking the ACME challenge -- any of these silently breaks auto-renewal. The certificate renews successfully for months, then one day it does not.
• Team turnover. The engineer who configured the certificate pipeline leaves the company. The renewal process was in their personal crontab, or tied to their account credentials with the certificate authority. Nobody else knows the setup exists until the certificate expires.
• Wildcard certificates covering multiple services. A single wildcard cert (*.example.com) might secure your main site, API, staging environment, and internal tools. When it expires, everything goes down simultaneously. And because the cert is managed centrally, individual service owners assume someone else is handling it.
• Multi-year certificates creating complacency. Before the CA/Browser Forum mandated a maximum 398-day validity, organizations could buy three-year or even five-year certificates. Teams that deployed a long-lived cert years ago have no renewal muscle memory. When it finally expires, nobody remembers the process.

The common thread is that certificate expiration is a predictable event that organizations treat as an unpredictable one. SSL certificate monitoring exists to close that gap.

What SSL Certificate Monitoring Actually Does

SSL certificate monitoring is the practice of continuously checking your domain's certificate status and alerting you before problems become outages. The distinction between "checking once" and "continuous monitoring" matters.

A one-time check -- running openssl s_client manually, or pasting your domain into SSL Labs -- tells you the state of your certificate right now. That is useful for debugging, but it does nothing to prevent the next expiration. By the time you remember to check again, the certificate may already be expired.

Continuous monitoring automates the check on a schedule -- daily, every 12 hours, or even hourly -- and sends alerts at defined thresholds before expiration. A well-configured SSL monitoring tool will:

• Check certificate validity on a schedule. Not once, but every scan cycle. If you are scanning every 12 hours, you get 60 checks in the 30 days before expiration.
• Alert at multiple thresholds. A warning at 30 days gives your team time to plan. A critical alert at 7 days tells you the renewal pipeline is broken and someone needs to act immediately.
• Validate the full certificate chain. An expired intermediate certificate causes the same browser warnings as an expired leaf certificate. Chain validation catches issues your server's own renewal process would miss.
• Check the TLS protocol version. A valid certificate served over TLS 1.0 is still a security failure. Monitoring should flag deprecated protocol versions alongside certificate status.
• Detect weak cipher suites. Even with a valid cert and modern TLS, weak ciphers (like RC4 or 3DES) undermine the entire connection. Comprehensive monitoring catches these configuration issues too.

The goal is simple: you should never learn about a certificate problem from a customer, a browser warning, or a monitoring dashboard turning red at 3 AM. You should learn about it 30 days in advance, from an email or Slack message, with enough time to fix it during business hours.

What Gets Checked in an SSL/TLS Scan

Scanward's SSL scanner evaluates your domain's certificate and TLS configuration across five dimensions. Each check starts at a base score of 100, with deductions for issues found. Here is exactly what gets checked and how it affects your domain security score.

Certificate validity and expiry date

The scan connects to your server, retrieves the certificate, and checks whether it is currently valid. If the certificate is expired, the score drops to 0 immediately. There is no partial credit for a certificate that expired yesterday -- browsers treat it the same as one that expired a year ago.

Days until expiration

For valid certificates, the scan calculates the exact number of days remaining. Two thresholds apply:

• Less than 7 days remaining (critical): -40 points. Your certificate is about to expire and auto-renewal has likely failed. Immediate action required.
• Less than 30 days remaining (warning): -15 points. You are inside the renewal window. If auto-renewal is working, the cert should renew soon. If not, this is your early warning.

TLS protocol version

The scan checks which TLS versions your server supports. The scoring is straightforward:

• TLS 1.3: Best. No deduction. This is the current standard with improved performance and security.
• TLS 1.2: Good. No deduction. Still considered secure and widely supported.
• TLS 1.1 or below: -30 points. TLS 1.0 and 1.1 were deprecated by RFC 8996 in March 2021. All major browsers have dropped support. If your server still accepts these versions, it is a significant security and compatibility issue.

Cipher suite strength

Even with TLS 1.2 or 1.3, the specific cipher suites your server negotiates matter. The scan flags weak ciphers -- including RC4, 3DES, export-grade ciphers, and NULL ciphers -- with a -20 point deduction. Modern servers should use ECDHE key exchange with AES-GCM or ChaCha20-Poly1305.

Certificate chain validation

The scan validates the entire chain from your server's leaf certificate through any intermediate certificates up to a trusted root CA. An incomplete or invalid chain -- missing intermediates, self-signed certificates in production, or an untrusted root -- results in a -50 point deduction. Chain issues are particularly insidious because some browsers cache intermediate certificates and work fine, while others fail. You may not see the problem on your own machine.

Here is the scoring breakdown in one view:

The SSL/TLS score accounts for 25% of your overall domain security grade. A failing SSL score drags down your entire rating, which is appropriate -- a broken certificate is the most visible security failure your visitors will encounter.

How to Set Up SSL Monitoring

There are three approaches to SSL certificate monitoring, ranging from manual scripts to fully automated platforms. The right choice depends on how many domains you manage and how much operational overhead you are willing to accept.

1. Manual: openssl commands and cron scripts

The most basic approach is a shell script that checks certificate expiration via openssl and sends an alert. Here is a working example:

# Check certificate expiry date for a domain
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null \
  | openssl x509 -noout -dates

# Output:
# notBefore=Jan 15 00:00:00 2026 GMT
# notAfter=Apr 15 23:59:59 2026 GMT

To get the number of days remaining, you can parse the expiry date:

# Get days until expiry
EXPIRY=$(openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null \
  | openssl x509 -noout -enddate | cut -d= -f2)
EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s 2>/dev/null || date -j -f "%b %d %T %Y %Z" "$EXPIRY" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (EXPIRY_EPOCH - NOW_EPOCH) / 86400 ))

echo "$DAYS_LEFT days remaining"

You can wrap this in a cron job that runs daily and sends an email or Slack webhook if $DAYS_LEFT drops below 30. The problem: this approach is fragile. The script breaks when a server moves, DNS changes, or the cron daemon restarts. It does not check TLS versions or cipher suites. And it does not scale -- adding a new domain means editing a shell script.

2. Free one-time tools: SSL Labs and Why No Padlock

Qualys SSL Labs provides the gold standard one-time SSL test. It gives you a detailed report on your certificate, protocol support, cipher suites, and known vulnerabilities. Why No Padlock focuses on mixed content issues that break the padlock icon.

These tools are excellent for debugging a specific issue, but they are manual. You have to remember to go to the site, enter your domain, and wait for results. There are no alerts, no scheduling, and no way to monitor multiple domains at once. If you are managing more than two or three domains, this quickly becomes unsustainable.

3. Automated monitoring: Scanward

Scanward runs SSL certificate checks automatically on every scan cycle -- every 24 hours on the free plan, every 12 hours on Pro, every 6 hours on Agency. Each scan checks certificate validity, days to expiry, TLS protocol versions, cipher strength, and chain integrity. When a threshold is crossed, you get an email alert (and Slack on paid plans).

The key difference from the other approaches: SSL monitoring is part of a comprehensive domain security score that also covers DNS, HTTP security headers, email authentication, and uptime. Instead of running separate tools for each concern, you get a single dashboard with a single grade. When your certificate is about to expire, it shows up alongside your other security posture data -- not in isolation.

Beyond Expiry: TLS Configuration Best Practices

A valid, unexpired certificate is the minimum. The TLS configuration surrounding that certificate matters just as much. Here are the settings every production server should have.

Disable TLS 1.0 and 1.1

TLS 1.0 and 1.1 are vulnerable to BEAST, POODLE, and other known attacks. All major browsers dropped support in 2020. There is no reason to keep them enabled. For Nginx:

# Nginx: /etc/nginx/nginx.conf or site config
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

For Apache:

# Apache: /etc/apache2/mods-enabled/ssl.conf
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLHonorCipherOrder off

Use strong cipher suites

Restrict your cipher suites to AEAD ciphers with forward secrecy. This is a strong default for Nginx:

# Nginx: strong cipher configuration
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;

For Apache:

# Apache: strong cipher configuration
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder off

With TLS 1.3, cipher suite configuration is handled by the protocol itself -- the server uses AEAD ciphers by default. The cipher configuration above primarily governs TLS 1.2 connections.

Enable HSTS

HTTP Strict Transport Security tells browsers to always use HTTPS for your domain. Without it, a user's first visit may be over HTTP before being redirected, creating a window for man-in-the-middle attacks. Add this header to your server configuration:

# Nginx
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

# Apache
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

HSTS is one of the most impactful security headers you can deploy. For a complete walkthrough of all recommended headers, see our HTTP security headers guide.

Set up auto-renewal and verify it works

If you use Let's Encrypt, make sure auto-renewal is actually running. The most common setup is a certbot cron job or systemd timer:

# Check if the certbot timer is active (systemd)
systemctl status certbot.timer

# Or check the cron job exists
crontab -l | grep certbot

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

Run certbot renew --dry-run after any server migration, DNS change, or web server reconfiguration. If the dry run fails, your next real renewal will fail too -- and you will find out 90 days later when the certificate expires.

The best certificate monitoring setup combines auto-renewal for prevention with external monitoring for verification. Auto-renewal handles the happy path. Monitoring catches everything else.

Putting It All Together

SSL certificate expiration is a solved problem -- in theory. Every certificate has a known expiry date. Renewal can be automated. Alerts can be configured. And yet, expired certificates remain one of the most common causes of production outages, because the operational plumbing that keeps renewal working is itself fragile and unmonitored.

The fix is straightforward. Set up auto-renewal for your certificates. Configure your TLS settings to use modern protocols and strong ciphers. Deploy HSTS. Then put external monitoring in place to verify that all of it is actually working -- not just today, but every day, automatically.

Scanward's SSL certificate monitoring checks your cert validity, expiry countdown, TLS version, cipher strength, and chain integrity on every scan. It is part of a broader domain security grade that also covers DNS, security headers, email authentication, and uptime -- giving you a single view of your domain's external security posture.