How to Fix an SSL Certificate Outage: A Step-by-Step Guide
Most SSL outages fall into five categories - expired certificate, broken chain, hostname mismatch, untrusted issuer, or a cipher/protocol mismatch - and each has a different fix. The fastest way to identify which one you have is to run openssl s_client from a machine off the affected network and read the Verify return code. Fix the specific category, verify from outside (allowing 5-10 minutes for CDN caches), then run a short post-mortem, because most SSL outages are monitoring failures, not cryptography failures.
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, risky EKUs, and distrust events - that keep a site from opening in every browser. Built for solo developers monitoring a handful of sites and for enterprise teams managing thousands of certificates across multiple environments.
Related reading
Frequently asked questions
- How do I diagnose an SSL certificate outage?
- Run 'openssl s_client -connect example.com:443' from a machine that is not on the affected network and read the Verify return code. Values map to the cause: 10 is an expired certificate, 21 is an incomplete chain (unable to verify the first certificate), and 20 is a missing intermediate (unable to get local issuer certificate). That tells you which of the five categories you are in.
- What are the most common causes of an SSL outage?
- Five: an expired certificate (most common), a broken chain where intermediates are not sent, a hostname the certificate does not cover, an untrusted or self-signed issuer, and a cipher or protocol mismatch where the server only offers TLS the browser refuses. Each has a distinct fix.
- How do I fix a broken certificate chain?
- Install the full chain rather than the leaf certificate alone. In nginx, point ssl_certificate at fullchain.pem (leaf plus intermediates concatenated). In Apache, set SSLCertificateChainFile alongside SSLCertificateFile. All major CAs provide the intermediate certificates alongside the leaf.
- How do I verify an SSL outage is fixed?
- Do not trust the server's internal view. Re-run openssl s_client from a different machine, or load the site in an incognito window, or use an external scanner. If you are behind a CDN, wait 5-10 minutes for cache invalidation before re-testing, because the edge may still serve the old certificate.
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.