← Blog

Signs Your SSL Certificate Is Failing: 8 Clear Warnings

June 26, 2026

By Nick Phillips, Founder

Signs Your SSL Certificate Is Failing: 8 Clear Warnings

TL;DR:

• SSL certificate failures occur when browsers cannot verify trust or match the site’s certificate, leading to warnings or blocked access.
• Monitoring live handshake behavior and configuring proper certificate chains are essential to detect and prevent issues before visitors encounter errors.

An SSL certificate failure is defined as any condition where a browser cannot verify that your site’s certificate is valid, trusted, or correctly matched to your domain. The signs your SSL certificate is failing range from visible browser warnings like “Your connection is not private” to silent handshake errors that block visitors before a single byte of your page loads. SSL certificate errors typically fall into four categories: expiry, hostname mismatch, missing intermediate certificates, and server misconfiguration. Tools like DigiCert’s certificate checker and Cloudflare’s SSL diagnostics can surface these problems in seconds. Catching them early is the difference between a minor fix and a full site outage.

1. Signs your SSL certificate is failing due to expiry

An expired certificate is the most common SSL certificate issue, and browsers treat it as a hard failure. Chrome shows NET::ERR_CERT_DATE_INVALID. Firefox shows SEC_ERROR_EXPIRED_CERTIFICATE. Safari blocks the page entirely with a red warning. Every major browser refuses to load the site until the certificate is renewed.

What makes expiry tricky is that the window to act is shrinking. As of march 15, 2026, public TLS certificates have a maximum validity period of 200 days. That means you are renewing roughly twice as often as before, and the risk of missing a renewal window doubles with it. Shorter lifetimes are good for security but brutal for anyone relying on manual renewal.

One thing that trips people up: a device with a wrong system clock can produce the same NET::ERR_CERT_DATE_INVALID error even when your certificate is perfectly valid. Before you panic and start a renewal, check the expiry date directly.

• Open your browser’s padlock icon and click “Certificate” to see the valid-from and valid-to dates.
• Run openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates from a terminal to pull the exact dates.
• Cross-check against the current date on a second device to rule out a local clock issue.

Pro Tip: Set renewal alerts at 60, 30, and 14 days before expiry. With 200-day certificates now standard, a single 30-day alert is no longer enough buffer.

2. Domain name mismatch errors

A name mismatch error means the hostname you visited is not listed in the certificate’s Subject Alternative Name (SAN) field. Browsers show this as NET::ERR_CERT_COMMON_NAME_INVALID in Chrome or SSL_ERROR_BAD_CERT_DOMAIN in Firefox. The page is blocked completely.

Name mismatch errors are a contract violation by design. Browsers refuse to connect if the requested domain does not appear in the SAN list. This is a security feature, not a bug. The most common scenarios that cause it:

1. Your certificate covers www.example.com but not the apex domain example.com, or vice versa.
2. You added a new subdomain like shop.example.com but never updated the SAN list.
3. Your server uses SNI (Server Name Indication) incorrectly and serves the wrong certificate for the requested hostname.
4. You recently migrated to a new domain and the old certificate is still being served.

One critical detail: browsers validate the SAN extension, not the legacy Common Name field. Fixing the Common Name alone will not clear the warning. You must reissue the certificate with the correct hostnames in the SAN list.

For a full breakdown of causes and fixes, the domain mismatch fix guide from Otterwatch covers the most common SNI and SAN misconfigurations in detail.

Pro Tip: When you run openssl s_client -connect yourdomain.com:443, look for the “Subject Alternative Name” line in the output. If your hostname is not listed there, that is your problem.

3. Incomplete or broken certificate chain

A broken certificate chain is one of the sneakiest SSL warning signs because your leaf certificate can be perfectly valid and still cause trust errors. Browsers maintain a trust store of root certificate authorities (CAs). When your server sends only the leaf certificate without the intermediate certificates that connect it to a trusted root, the browser cannot complete the chain and shows NET::ERR_CERT_AUTHORITY_INVALID.

Missing intermediate certificates are a leading cause of this error. The fix is to serve a fullchain.pem file that includes both your leaf certificate and all intermediate certificates in the correct order. Most hosting panels and web servers like Nginx and Apache accept this file directly.

Common causes of broken chains:

• Installing only the leaf certificate without the intermediate bundle.
• Using a self-signed certificate in a production environment.
• A CA that rotated its intermediate certificate after you installed yours.
• Copying certificate files manually and getting the order wrong.

The impact goes beyond user trust. Search engines treat HTTPS as a ranking signal, and a broken chain can suppress your pages in results just as effectively as a full outage.

4. Unexpected SSL errors from handshake failures

A TLS handshake failure is different from a certificate validation error, though both produce SSL warning signs in the browser. During the handshake, the client and server negotiate the encryption protocol and exchange certificates. If anything breaks in that process, the browser blocks the connection before any HTTP traffic moves.

Browsers refuse TLS connections where the certificate does not validate during the handshake phase. Refreshing the page does not fix this. The problem lives in your server configuration, not in the browser or the visitor’s network. Common server-side causes include:

• The private key on the server does not match the public key in the certificate (this happens after a certificate reissue where the new cert was uploaded but the old key was left in place).
• The server is configured to serve the wrong certificate for a given hostname, often a leftover from a multi-domain setup.
• TLS protocol version mismatches, where the server only supports older protocols the browser has deprecated.
• Firewall or load balancer rules that terminate TLS incorrectly before traffic reaches the origin server.

Incorrect server SSL/TLS configuration causes untrusted certificate errors even when the leaf certificate itself is valid. Check your server error logs first. On Nginx, ssl_error_log entries will tell you exactly where the handshake broke.

Pro Tip: Use openssl s_client -connect yourdomain.com:443 -servername yourdomain.com and look for “Verify return code: 0 (ok)”. Any other return code points directly to the handshake problem.

5. “Your connection is not private” and other user-visible warnings

The browser warning “Your connection is not private” is the most visible SSL certificate error a site visitor sees. Chrome, Edge, and Opera all display this message with an error code underneath. Firefox shows “Warning: Potential Security Risk Ahead.” Safari shows a red “Not Secure” label with a full-page warning.

Common SSL errors include expired certificates, untrusted certificate authorities, and certificate name mismatches. Each produces a slightly different error code, which tells you exactly what went wrong. The code NET::ERR_CERT_DATE_INVALID points to expiry. NET::ERR_CERT_COMMON_NAME_INVALID points to a hostname mismatch. NET::ERR_CERT_AUTHORITY_INVALID points to a chain or trust problem.

Most visitors will not click through a browser warning. They will leave. That makes these warnings a direct threat to your traffic and revenue, not just a technical inconvenience.

6. The HTTP fallback: your site loading without HTTPS

If your site loads over plain HTTP instead of HTTPS, your certificate has either expired or is not being served at all. This is a quieter failure sign than a browser warning, but it is just as serious. Visitors may not notice the missing padlock, but their data is unencrypted.

Check your site by typing http://yourdomain.com directly. If the server does not redirect to https://, your SSL configuration has a gap. Also check that your HSTS (HTTP Strict Transport Security) header is set, which forces browsers to use HTTPS even if a user types the HTTP version manually.

7. Mixed content warnings

Mixed content warnings appear when an HTTPS page loads resources (images, scripts, stylesheets) over HTTP. Chrome shows a “Not Secure” label in the address bar. The browser console shows Mixed Content: The page was loaded over HTTPS, but requested an insecure resource.

This is a partial SSL failure. Your certificate is valid, but your page is undermining it by pulling in unencrypted assets. The fix is to update all resource URLs to HTTPS. For WordPress sites, a plugin like Really Simple SSL can scan and update these automatically.

8. Practical tools to detect SSL certificate issues early

Detecting SSL problems before visitors hit them requires active monitoring, not just a mental note to renew next quarter. Monitoring live server SSL behavior rather than relying on countdown badges is the most reliable approach, because chain misconfigurations and handshake failures can invalidate an otherwise valid certificate without touching the expiry date.

Automated SSL certificate monitoring reduces operational risk, especially with shorter certificate lifetimes now standard. The tools worth knowing:

• Otterwatch: Watches your SSL certificates and uptime together, sends plain-language alerts before expiry, and runs external checks rather than just reading a file timestamp. Free for up to five sites.
• DigiCert Certificate Inspector: Good for one-off checks of chain validity and SAN entries.
• SSL Shopper SSL Checker: Quick visual breakdown of your cert chain and any missing intermediates.
• OpenSSL CLI: The most direct tool for diagnosing handshake issues and reading raw certificate data.

For a side-by-side look at how these tools compare on features like handshake testing and alert frequency, the SSL monitoring tools comparison from Otterwatch is worth a read.

The gap between tools that check expiry dates and tools that run live handshake tests is significant. Proper SSL monitoring runs external handshake tests, not just file expiry timestamps, to catch chain or config errors invisible to simple expiry checks.

Key takeaways

SSL certificate failures are detectable early if you monitor live handshake behavior, not just expiry dates.

Why I think most site owners catch SSL failures too late

The pattern I see most often is this: a site owner sets up a certificate, maybe even turns on auto-renewal, and then assumes the problem is solved. It is not. Auto-renewal can fail silently. The renewed certificate can be issued but not deployed. The chain can break during a server migration. None of these problems show up on a dashboard that only watches the expiry date.

The 2026 shift to 200-day maximum certificate lifetimes makes this worse. Renewal is now a more frequent event, which means more opportunities for something to go wrong. I have seen sites go down not because anyone forgot to renew, but because the renewal script ran, the new certificate was written to disk, and the web server was never reloaded to pick it up. The expiry badge said “valid.” The browser said otherwise.

My honest recommendation is to treat SSL monitoring the same way you treat uptime monitoring. You would not rely on a user complaint to tell you your site is down. Do not rely on a user complaint to tell you your certificate is broken. Set up external checks that actually complete a TLS handshake from outside your network. That is the only way to know what your visitors are actually seeing.

The other thing worth saying: mixed content warnings and HTTP fallback failures are easy to overlook because they do not always produce a full browser block. A site that loads over HTTPS but pulls one image over HTTP is still a partially broken site. Audit your resource URLs after any migration or CMS update.

— Nick Phillips

Otterwatch keeps an eye on your SSL so you do not have to

Catching SSL certificate issues before your visitors do is exactly what Otterwatch is built for. It runs real external checks on your certificates and your site uptime together, and sends you a calm, plain-language heads up well before anything breaks.

Otis, the park ranger otter behind Otterwatch, does not send walls of red alerts. He sends one friendly message that tells you what is wrong and what to do about it. You can run a free SSL check on any domain right now, no account needed. Or sign up for ongoing SSL and uptime monitoring and get five sites watched for free. With 200-day certificate lifetimes now the standard, having something quietly watching your certs is no longer optional.

FAQ

What does “your connection is not private” mean?

This browser warning means the SSL certificate for the site cannot be verified as valid, trusted, or correctly matched to the domain. The cause is usually an expired certificate, a hostname mismatch, or a broken certificate chain.

How do I quickly check if my SSL certificate is failing?

Click the padlock icon in your browser’s address bar and select “Certificate” to see the expiry date and the domain names covered. For a full chain and handshake check, use a tool like Otterwatch’s free SSL checker or run openssl s_client -connect yourdomain.com:443.

Can auto-renewal fail without me knowing?

Yes. Auto-renewal scripts can run successfully and still leave a broken certificate in place if the web server is not reloaded after the new certificate is written to disk. External handshake monitoring catches this where expiry-date-only tools do not.

What is a SAN mismatch and why does it block my site?

A SAN (Subject Alternative Name) mismatch means the hostname you visited is not listed in the certificate’s SAN field. Browsers treat this as a security violation and block the connection entirely, regardless of whether the certificate is otherwise valid.

How often do I need to renew my SSL certificate now?

As of march 15, 2026, the maximum validity period for public TLS certificates is 200 days. That means renewals happen roughly twice as often as under the old 398-day limit, making automated monitoring and alerts more important than ever.

Recommended

• How to Avoid SSL Expiration Warnings: 2026 Guide · Otterwatch
• Blog · Otterwatch
• Why SSL Affects Website Credibility: A Clear Guide · Otterwatch
• Certificate Expiration Notification Explained for Site Owners · Otterwatch