Common SSL Errors and How to Fix Them

Why SSL Errors Happen

SSL/TLS errors occur when a browser cannot establish a secure connection to a website. The browser performs several checks during the TLS handshake: Is the certificate expired? Does it match the domain? Was it issued by a trusted authority? Is the chain complete? Is the protocol version supported?

If any check fails, the browser blocks access and shows an error page. These errors are intentional — they protect users from intercepted or compromised connections. But when the error is on your site, it is effectively a full outage. Users cannot reach your content, APIs reject requests, and search engines penalize your rankings.

Here are the most common SSL errors, what causes them, and how to fix each one.

SSL Error Quick Reference

NET::ERR_CERT_DATE_INVALID — Expired Certificate

This is the most common SSL error. The certificate's validity period has ended, and the browser refuses to trust it.

What you see: Chrome displays "Your connection is not private" with the error code NET::ERR_CERT_DATE_INVALID. Firefox shows "Warning: Potential Security Risk Ahead." Safari shows a similar blocking page.

What causes it:

• The certificate expired and was not renewed (most common)
• Auto-renewal via Certbot or ACME failed silently
• The server's system clock is incorrect (rare but possible on misconfigured servers)
• The user's computer clock is wrong (client-side issue, not your fault)

How to fix it:

ERR_CERT_AUTHORITY_INVALID — Untrusted Certificate Authority

The browser does not trust the entity that issued the certificate.

What causes it:

• Self-signed certificate used in production (only valid for local development)
• Certificate issued by an internal or private CA not in the browser's trust store
• The certificate authority was distrusted (as happened with Symantec-issued certificates)
• Missing intermediate certificate — the browser cannot build a chain to a trusted root

How to fix it: If you are using a self-signed certificate, replace it with one from a trusted CA. Let's Encrypt provides free trusted certificates. If you believe your certificate is from a trusted CA but still see this error, the issue is almost certainly a missing intermediate certificate (see the chain issues section below).

ERR_CERT_COMMON_NAME_INVALID — Domain Mismatch

The domain in the browser's address bar does not match any domain listed in the certificate.

What causes it:

• Certificate issued for www.example.com but user visits example.com (or vice versa)
• Wildcard certificate for *.example.com does not cover the apex domain example.com
• Certificate issued for the wrong domain entirely (copy-paste error during CSR generation)
• Server hosts multiple domains and serves the wrong certificate via SNI misconfiguration

How to fix it: Check which domains the certificate covers by examining the Subject Alternative Names (SANs). Run openssl s_client -connect yourdomain.com:443 -servername yourdomain.com | openssl x509 -noout -text | grep -A1 "Subject Alternative Name". Reissue the certificate with all required domains included, or configure your web server's SNI settings to serve the correct certificate for each domain.

ERR_SSL_PROTOCOL_ERROR — Protocol or Cipher Mismatch

The browser and server cannot agree on a TLS protocol version or cipher suite.

What causes it:

• Server only supports TLS 1.0 or 1.1, which modern browsers have disabled
• Server configured with only weak or deprecated cipher suites
• SSL/TLS misconfiguration in the web server (nginx, Apache, IIS)

How to fix it: Update your server's TLS configuration to support TLS 1.2 and TLS 1.3. Disable TLS 1.0 and 1.1. Use Mozilla's SSL Configuration Generator (ssl-config.mozilla.org) to generate a recommended configuration for your specific web server and version. After updating, test with openssl s_client -connect yourdomain.com:443 -tls1_2 to verify TLS 1.2 support.

Mixed Content Warnings

Mixed content occurs when an HTTPS page loads resources (images, scripts, stylesheets, iframes) over plain HTTP. Browsers block or warn about these insecure resources.

What you see: The padlock icon disappears or shows a warning. The browser console logs "Mixed Content" warnings. Active mixed content (scripts, iframes) is blocked entirely. Passive mixed content (images) may load with a warning.

What causes it:

• Hardcoded http:// URLs in HTML, CSS, or JavaScript
• Third-party widgets or embeds using HTTP
• Images or assets stored on a CDN that was not configured for HTTPS
• CMS content with absolute HTTP URLs saved in the database

How to fix it: Search your codebase for http:// references and replace them with https:// or protocol-relative // URLs. For CMS content, run a search-and-replace on the database. Add the Content-Security-Policy: upgrade-insecure-requests header as a temporary measure while fixing the source URLs. Use the browser's developer console to identify exactly which resources are triggering mixed content warnings.

Incomplete Certificate Chain

This is the most insidious SSL error because it does not affect all users equally.

Your SSL certificate is signed by an intermediate CA, which is signed by a root CA that browsers trust. Your server must send the full chain: your certificate plus the intermediate certificate(s). If the intermediate is missing, some browsers can fill in the gap (via AIA fetching) while others cannot.

What you see: The site works in Chrome on desktop but fails on mobile Safari, Android, API clients, and curl. The inconsistency makes it extremely hard to diagnose without automated testing.

How to fix it: Download the correct intermediate certificate from your CA's documentation. Concatenate it with your server certificate in the correct order (server cert first, then intermediate). In nginx, this means combining them into a single file referenced by ssl_certificate. In Apache, use the SSLCertificateChainFile directive. After updating, verify the full chain with openssl s_client -connect yourdomain.com:443 -servername yourdomain.com and check that the chain shows your certificate, the intermediate, and the root.

Preventing SSL Errors with Monitoring

Every SSL error listed above can be caught before users see it. SSL monitoring connects to your server, performs a full TLS handshake, and validates the certificate on a schedule — typically every few minutes to every few hours.

SSL errors are not bugs you fix once. Certificates expire on a schedule, configurations change during deployments, and intermediates can be lost during server migrations. Monitoring is the only reliable way to catch these issues before they become outages.