The Silent Killer: SSL/TLS Certificate Expiry
It happens quietly. A certificate expires at 2 AM on a Saturday. By morning, your website greets every visitor with a full-page browser warning: "Your connection is not private." Customers leave. Search rankings drop. Revenue stops. And the fix — renewing a certificate — takes five minutes.
SSL/TLS failures are one of the most preventable causes of downtime, yet they keep happening. Equifax suffered a major brand hit partly due to an expired certificate that masked a breach. Microsoft Teams went down for hours because of a single expired cert. These aren't obscure edge cases — they're the predictable result of not monitoring something that has a hard expiration date.
This guide covers exactly what can go wrong with SSL/TLS, how to monitor it systematically, and how to make sure you never get caught off guard.
What Actually Goes Wrong with SSL/TLS
Certificate expiry gets the most attention, but it's only one of several failure modes. Here's the full list of things that break:
Expired certificates. Every SSL/TLS certificate has a Not After date. Once that date passes, browsers reject the connection outright. There's no grace period, no degraded mode — it just stops working. If you manage multiple domains, subdomains, or wildcard certs, tracking every expiry date manually is a losing game.
Weak protocol versions. TLS 1.0 was released in 1999. TLS 1.1 came in 2006. Both have known vulnerabilities, including susceptibility to BEAST and POODLE attacks. Every major browser has dropped support for them, and PCI DSS compliance requires TLS 1.2 or higher. If your server still negotiates TLSv1.0 or TLSv1.1, you have a real security issue and a compliance problem.
Bad cipher suites. Even on TLS 1.2, you can be running weak ciphers. Suites using RC4, DES, 3DES, or NULL encryption are considered broken. Suites without forward secrecy (no ECDHE or DHE key exchange) mean that if your private key is ever compromised, all past traffic can be decrypted. Your server's cipher suite configuration matters as much as the certificate itself.
Incomplete certificate chains. Your SSL certificate doesn't work alone. It's part of a chain: your certificate, one or more intermediate certificates, and a root certificate trusted by the browser. If your server doesn't send the intermediate certificates, some browsers will figure it out — but others won't. Mobile browsers and API clients are especially unforgiving. The result is intermittent failures that are hard to reproduce and harder to debug.
Mismatched domains. A certificate issued for www.example.com won't work on example.com, api.example.com, or staging.example.com unless those names are included as Subject Alternative Names (SANs). Deploying the wrong certificate to the wrong subdomain is more common than you'd think, especially in environments with many services behind different hostnames.
Missing HSTS headers. HTTP Strict Transport Security tells browsers to only connect over HTTPS. Without it, a user's first visit (or any visit via a bookmarked http:// link) can be intercepted by an attacker who downgrades the connection. HSTS isn't part of the certificate, but it's a critical part of your TLS posture.
How FortWatch's SSL Scanner Works
FortWatch's SSL/TLS scanner connects to each of your monitored domains and performs a comprehensive check. It's not just a certificate expiry countdown — it evaluates the full TLS configuration. Here's what it examines:
- Certificate expiry date — flags certificates expiring within 30, 14, and 7 days with escalating severity
- Protocol versions — detects TLS 1.0 and 1.1 support and flags them as security risks
- Cipher suite strength — identifies weak, deprecated, or insecure cipher suites in the server's configuration
- Certificate chain completeness — verifies that all intermediate certificates are present and correctly ordered
- Domain matching — confirms the certificate's Common Name and Subject Alternative Names match the scanned hostname
- HSTS header presence — checks for the
Strict-Transport-Securityheader and evaluates itsmax-agevalue - Certificate authority — identifies the issuing CA and flags self-signed certificates
Each check produces a finding with a severity level: critical for expired certificates and immediate security risks, high for weak protocols and approaching expiry, medium for configuration weaknesses like missing HSTS, and low for informational items and best-practice suggestions.
What a Failing SSL Scan Looks Like
To make this concrete, here's what FortWatch reports when it scans a domain with real SSL/TLS problems:
Critical: Certificate expired. The certificate's Not After date is in the past. Every browser will block access. This is a severity-critical finding because it causes immediate, visible downtime. The fix is to renew the certificate immediately.
High: Certificate expires in 7 days. The certificate is still valid, but the clock is ticking. FortWatch escalates the severity as expiry approaches — 30 days out is medium, 14 days is high, 7 days is critical. This gives you a clear window to act.
High: TLS 1.0 supported. The server accepts connections using TLS 1.0, which is vulnerable to known attacks. Even if TLS 1.2 and 1.3 are also available, the presence of TLS 1.0 means an attacker can force a downgrade. The fix is to disable TLS 1.0 and 1.1 in your server configuration — in Nginx, that means setting ssl_protocols TLSv1.2 TLSv1.3; and nothing else.
High: Weak cipher suites detected. The server offers cipher suites using 3DES or RC4. These have known weaknesses and should be removed from your configuration. In Nginx, use ssl_ciphers to explicitly list strong suites, or use Mozilla's SSL Configuration Generator to build a secure configuration for your server software.
Medium: Incomplete certificate chain. The server's certificate is valid, but it's not sending the intermediate certificate. Most desktop browsers can fetch the missing intermediate on their own, but mobile clients, API consumers, and command-line tools like curl will fail with a "certificate verify failed" error. The fix is to configure your server to send the full chain — in Nginx, your ssl_certificate file should contain your certificate followed by the intermediate(s).
Medium: HSTS header missing. The site is served over HTTPS, but doesn't set the Strict-Transport-Security header. This leaves users vulnerable to SSL stripping attacks on their first visit. Adding add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; to your Nginx config closes this gap.
Medium: Domain mismatch. The certificate was issued for www.example.com but the scan hit api.example.com. The server is presenting a valid certificate — just not for this hostname. This usually means the wrong certificate was deployed to this virtual host.
Setting Up SSL/TLS Monitoring in FortWatch
Getting started takes about two minutes:
Step 1: Add your domains. In the FortWatch dashboard, add each domain and subdomain you want to monitor as an asset. Include everything — your main site, API endpoints, staging environments, mail servers, anything with a certificate.
Step 2: FortWatch scans automatically. Once an asset is added, FortWatch's SSL scanner runs on a regular schedule. You don't need to configure scan timing or parameters — it checks the full TLS stack on every run.
Step 3: Review findings. Each scan produces a set of findings organized by severity. Critical and high findings represent things that need immediate attention. Medium findings are configuration improvements you should schedule. The dashboard shows you the state of every certificate across all your assets in one place.
Step 4: Get alerted before things break. FortWatch tracks certificate expiry dates and escalates alerts as the deadline approaches. You'll know about an expiring certificate 30 days out, giving you plenty of time to renew — not at 2 AM when it actually expires.
The goal is simple: you should never learn about an SSL/TLS problem from a customer or a browser warning. You should already know, and you should already have a plan.
Certificate Renewal Best Practices
Monitoring tells you when something is wrong. Automation keeps things from going wrong in the first place. Here's how to build a reliable renewal process:
Automate with Let's Encrypt and Certbot. Let's Encrypt provides free, trusted certificates with a 90-day validity period. Certbot handles the renewal automatically. Install it, run certbot --nginx or certbot --apache to get your initial certificate, and Certbot sets up a systemd timer or cron job that renews the certificate before it expires. For most setups, this is all you need.
Test the renewal process. Run certbot renew --dry-run to verify that automatic renewal will work. This catches permission issues, DNS changes, or configuration drift before they cause a real failure. Do this after any server migration or major configuration change.
Monitor as a backup layer. Even with automated renewal, things go wrong. The cron job silently fails because of a permission change. A DNS record moves and domain validation breaks. The server is rebuilt and nobody reinstalls Certbot. FortWatch acts as an independent monitoring layer that catches what your automation misses. If a certificate is 14 days from expiry, something in your automation has probably failed — and you want to know about that.
Track every certificate, not just the obvious ones. Your main website probably has solid automation. But what about that internal API? The staging environment? The mail server? The legacy app running on a VM someone set up two years ago? Certificate problems tend to hit the services you think about least. Add all of them to FortWatch.
Document your certificate inventory. Know which certificates you have, where they're deployed, who issued them, and how they're renewed. FortWatch's asset inventory gives you a centralized view, but your team should also know the answers to: "If this cert expires, who renews it and how?"
Set calendar reminders as a last resort. If you can't automate renewal for a particular certificate (some enterprise CAs don't support it), set manual calendar reminders at 30 and 14 days before expiry. But don't rely on calendar reminders alone — people ignore them, people go on vacation, people leave the company.
The Checklist: What to Do Right Now
If you've read this far, here's your action list:
- Inventory your certificates. List every domain and subdomain that serves HTTPS. Include APIs, staging environments, internal tools, and mail servers. Add them all as assets in FortWatch.
- Check your protocol versions. Make sure every server is running TLS 1.2 or 1.3 exclusively. Disable TLS 1.0 and 1.1. In Nginx:
ssl_protocols TLSv1.2 TLSv1.3; - Review your cipher suites. Use Mozilla's SSL Configuration Generator to build a secure configuration for your server software. Remove any weak or deprecated ciphers.
- Verify your certificate chains. Use FortWatch or
openssl s_client -connect yourdomain.com:443 -showcertsto verify that your server sends the full chain, including intermediate certificates. - Enable HSTS. Add the
Strict-Transport-Securityheader to all HTTPS responses. Start with a shortmax-age(like 300 seconds) to test, then increase to a year (31536000) once confirmed. - Automate renewal. Set up Certbot or your CA's automated renewal tool. Test it with a dry run. Then set up FortWatch monitoring as the safety net.
- Check your scan results weekly. Log into FortWatch and review your SSL/TLS findings. Anything critical or high should be addressed immediately. Medium findings should go into your next maintenance window.
SSL/TLS monitoring isn't glamorous, but it's one of the highest-leverage things you can do for your infrastructure's reliability and security. The certificates will expire — the only question is whether you'll know about it before your customers do.