An SSL outage is one of the loudest failures a website can have. Every visitor sees a scary browser warning. Conversion stops. Customer service tickets pile up. Search engines start downgrading the affected pages. The good news: most SSL outages are quick to diagnose and quick to fix - once you know where to look.
This guide walks through the diagnosis and fix step-by-step, with concrete commands you can paste into a terminal.
Step 1: Confirm what you're seeing
Before fixing anything, identify what kind of SSL outage you have. The five main categories - each has a different fix:
- Expired certificate - the most common. Browser says "your connection is not private" with a specific "certificate has expired" reason.
- Broken chain - certificate is valid, but the intermediate isn't being sent. Modern browsers handle this; older clients (legacy Android, old Java apps) refuse the connection.
- Hostname mismatch - certificate is valid but doesn't cover the hostname your visitors are using. Often happens when a wildcard certificate doesn't reach deep enough into subdomain levels.
- Untrusted issuer - your CA is no longer trusted, or you're using a self-signed certificate that visitors' browsers don't recognise.
- Cipher or protocol mismatch - server only accepts TLS 1.0/1.1 or a weak cipher. Modern browsers refuse to negotiate.
Run this from a terminal that isn't on the affected network:
openssl s_client -servername example.com -connect example.com:443 < /dev/null 2>&1 | head -30
The output tells you which category you're in. Look at the Verify return code line - values like 10 (certificate has expired), 21 (unable to verify the first certificate), or 20 (unable to get local issuer certificate) map directly to the categories above.
Step 2: Fix the expired-certificate case
If the verification code is "certificate has expired" (or you can see the notAfter date is in the past), you need a new certificate. Three paths:
- Re-run your existing automation (
certbot renew --force-renewalif you use Let's Encrypt). - Log into your CA portal and reissue.
- Issue a fresh free certificate from Beacon while you sort out the longer-term path.
Need a working certificate right now?
Beacon issues free 90-day Let's Encrypt certificates with a guided DNS-validation flow. No account, no command-line tools, no ACME client to install - just a domain you control. Most people get a working certificate in under 10 minutes.
Get a free certificate from BeaconStep 3: Fix the broken-chain case
If the certificate is valid but the chain is broken, the server isn't sending the intermediate certificates. The fix is to install the full chain, not just the leaf certificate. Most CAs provide the intermediate certificates alongside the leaf - typically as chain.pem, intermediate.pem, or ca-bundle.crt. Combine them into a fullchain file or configure your server to load them separately.
For nginx: use ssl_certificate fullchain.pem; (leaf + intermediates concatenated), not ssl_certificate cert.pem; (leaf only).
For Apache: set SSLCertificateChainFile chain.pem alongside SSLCertificateFile cert.pem.
Step 4: Fix the hostname-mismatch case
Certificate is valid, but the hostname being requested isn't on the Subject Alternative Name (SAN) list. Two common scenarios:
- You launched
api.eu.example.comand your wildcard certificate is*.example.com. Wildcards only cover one level deep, so the new subdomain isn't covered. You need a new certificate that includes eitherapi.eu.example.comexplicitly or a deeper wildcard. - You serve multiple sites on one IP via SNI, and the wrong certificate is being served for one of them. Check your server configuration to make sure each hostname maps to the right certificate.
Step 5: Fix the cipher/protocol case
Server is rejecting modern clients. Usually means TLS 1.0/1.1 is the only available protocol, or the cipher list is too restrictive. Update your TLS configuration to require TLS 1.2 minimum (1.3 preferred) and include modern cipher suites. The Mozilla SSL Configuration Generator produces ready-to-paste configurations for most web servers.
Step 6: Verify the fix from outside
Don't trust the server's internal view. Run the same openssl s_client command from a different machine, or use an online checker like Qualys SSL Labs. If you're behind a CDN, wait 5–10 minutes for cache invalidation before re-testing.
Step 7: Run the post-mortem
Once the outage is resolved, the structural fix matters more than the technical fix. Most SSL outages are monitoring failures, not cryptography failures. Three questions worth answering honestly:
- Did anyone get an alert before the outage hit? If yes, why was it missed? If no, why didn't monitoring catch it?
- Is the cert's owner still on the team and reachable? If not, who's the new owner?
- What's the next certificate that would fail for the same reason? If you can name one, the structural problem still exists.
Stop this from happening again
TLS Radar continuously monitors every certificate across your domains and alerts you weeks before anything expires, and also catches the silent failure modes (chain breaks, weak ciphers, hostname mismatches) that expiry-only monitoring misses. Built for solo developers monitoring a handful of sites and for enterprise teams managing thousands of certificates across multiple environments.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.