How to Fix SSL Certificate Errors: A Complete Troubleshooting Guide

Last Updated: October 2026

Understanding SSL Certificate Errors

SSL certificate errors occur when your browser cannot establish a trusted, encrypted connection to a website. Instead of loading the page, the browser displays a warning — "Your connection is not private," "Warning: Potential Security Risk Ahead," or similar — and blocks access to protect you from potentially unsafe communication.

These errors are not always the website owner's fault. They can be caused by server misconfigurations, expired certificates, DNS changes, client-side clock issues, or even overly aggressive antivirus software intercepting HTTPS traffic. Understanding which error you're seeing is the first step toward fixing it.

If you're unfamiliar with how SSL and TLS work, read our What Is SSL/TLS? guide first for background on certificates, the TLS handshake, and the chain of trust.

Common SSL Certificate Errors and Their Causes

SSL errors can be grouped by the underlying problem. Below are the most frequent categories, the browser error codes they produce, and what causes each one.

1. Expired Certificate (ERR_CERT_DATE_INVALID)

Every SSL certificate has a validity period defined by a "Not Before" and "Not After" date. Public certificates can be valid for a maximum of 398 days (13 months). Let's Encrypt certificates are valid for only 90 days. Once a certificate passes its "Not After" date, browsers will refuse to trust it.

Browser error codes:

• Chrome: NET::ERR_CERT_DATE_INVALID
• Firefox: SEC_ERROR_EXPIRED_CERTIFICATE
• Safari: "This Connection Is Not Private — certificate has expired"
• Edge: NET::ERR_CERT_DATE_INVALID (same as Chrome, Chromium-based)

Common causes: Forgetting to renew the certificate, a failed automatic renewal (e.g., Certbot cron job not running, DNS validation failing for wildcard certificates, port 80 blocked preventing HTTP-01 challenge), or a hosting provider that does not auto-renew.

2. Certificate Name Mismatch (ERR_CERT_COMMON_NAME_INVALID)

The domain name in the browser's address bar must match at least one of the names listed in the certificate's Subject Alternative Name (SAN) extension or, for older certificates, the Common Name (CN). If there is no match, the browser shows a name mismatch error.

Browser error codes:

• Chrome: NET::ERR_CERT_COMMON_NAME_INVALID
• Firefox: SSL_ERROR_BAD_CERT_DOMAIN
• Safari: "Safari can't verify the identity of the website"

Common causes: Visiting www.example.com when the certificate only covers example.com (or vice versa), accessing the site via an IP address when the certificate only lists domain names, migrating to a new domain without obtaining a new certificate, or a CDN/reverse proxy serving the wrong certificate for the requested hostname.

3. Untrusted Certificate Authority (ERR_CERT_AUTHORITY_INVALID)

Browsers maintain a trust store — a list of root Certificate Authorities (CAs) they trust. If the browser cannot chain the website's certificate back to one of these trusted roots, it shows an untrusted CA error.

Browser error codes:

• Chrome: NET::ERR_CERT_AUTHORITY_INVALID
• Firefox: SEC_ERROR_UNKNOWN_ISSUER
• Safari: "This certificate was signed by an unknown authority"

Common causes: The server is sending a self-signed certificate, the server is not sending the required intermediate CA certificates (incomplete chain), the certificate was issued by an internal enterprise CA that isn't publicly trusted, or the root CA has been removed from browser trust stores (rare but has happened with older Symantec roots).

4. Self-Signed Certificate

A self-signed certificate is one where the issuer and subject are the same entity — the certificate is signed by its own private key rather than by a trusted CA. Browsers do not trust self-signed certificates because there is no third-party validation of the server's identity.

Self-signed certificates trigger the same ERR_CERT_AUTHORITY_INVALID or SEC_ERROR_UNKNOWN_ISSUER errors as other untrusted CA problems. They are acceptable for local development and internal testing but should never be used on public-facing websites.

5. Incomplete Certificate Chain

The certificate chain connects your website's leaf certificate to a trusted root CA through one or more intermediate CA certificates. If the server only sends the leaf certificate without the intermediates, some browsers may fail to verify the chain — even though the certificate itself is perfectly valid.

This is one of the trickiest errors to diagnose because it often works in some browsers but not others. Chrome on Windows may succeed because the OS has cached the intermediate certificate from a previous visit, while Firefox (which uses its own certificate store and does not cache intermediates the same way) shows SEC_ERROR_UNKNOWN_ISSUER.

6. Mixed Content Warnings

Mixed content occurs when a page served over HTTPS loads sub-resources (images, scripts, stylesheets, fonts, iframes, XMLHttpRequest/fetch calls) over plain HTTP. This undermines the security guarantees of HTTPS because an attacker on the network can intercept or modify the insecure resources.

Browsers handle mixed content in two ways:

• Active mixed content (scripts, stylesheets, iframes, fetch/XHR) is blocked entirely. The resource fails to load, often breaking the page's functionality.
• Passive mixed content (images, audio, video) may load with a warning, or may be blocked depending on the browser and its settings.

Mixed content does not produce the dramatic "connection is not private" interstitial — instead, the padlock disappears or shows a warning, and the browser console logs the specific resources being blocked.

7. Protocol Version Mismatch (ERR_SSL_PROTOCOL_ERROR)

If the server supports only outdated TLS versions that the browser has disabled, or if there is no overlap in supported cipher suites, the TLS handshake fails entirely. Modern browsers require at least TLS 1.2, and many are beginning to prefer TLS 1.3.

Browser error codes:

• Chrome: ERR_SSL_PROTOCOL_ERROR or ERR_SSL_VERSION_OR_CIPHER_MISMATCH
• Firefox: SSL_ERROR_PROTOCOL_VERSION_ALERT or SSL_ERROR_NO_CYPHER_OVERLAP

Common causes: The server only supports TLS 1.0 or TLS 1.1 (both deprecated and disabled in all major browsers as of 2020–2021), the server only offers cipher suites that the browser considers insecure (e.g., RC4, export-grade ciphers, NULL ciphers), or a misconfigured SSL termination proxy.

How to Diagnose SSL Certificate Errors

Before you can fix an SSL error, you need to identify exactly what's wrong. Here are the diagnostic tools and techniques to use:

Browser Developer Tools

Every major browser provides built-in tools for inspecting SSL certificates and diagnosing connection issues:

• Chrome: Click the "Not Secure" or padlock icon in the address bar → "Certificate is not valid" → view certificate details, chain, and expiry. For more detail, open DevTools (F12) → Security tab, which shows the certificate, connection protocol, and cipher suite.
• Firefox: Click the padlock → "Connection not secure" → "More Information" → "View Certificate." Firefox shows a detailed certificate viewer with the full chain, validity dates, fingerprints, and extensions.
• Console log: Open DevTools → Console tab to see mixed content warnings. Blocked resources are logged with a description of why they were blocked and the URL of the insecure resource.

Using openssl s_client

The openssl command-line tool is the most powerful way to diagnose SSL certificate issues from a terminal. It connects to a server, performs the TLS handshake, and displays every detail:

• openssl s_client -connect example.com:443 -servername example.com — Connects to the server and shows the full certificate chain, negotiated protocol, cipher suite, and any verification errors. The -servername flag sends the SNI (Server Name Indication) header, which is critical for servers hosting multiple domains.
• openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates — Shows only the certificate's "Not Before" and "Not After" dates, useful for quickly checking expiry.
• openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text — Displays the full decoded certificate including SAN entries, issuer, signature algorithm, and key usage.
• openssl s_client -connect example.com:443 -servername example.com -showcerts — Displays all certificates sent by the server, including intermediates. This is the key command for diagnosing incomplete chain errors.

Look at the "Verify return code" at the bottom of the output. A value of 0 (ok) means the chain is valid. Common non-zero codes include 10 (certificate has expired), 18 (self-signed certificate), 19 (self-signed certificate in certificate chain), 20 (unable to get local issuer certificate), and 21 (unable to verify the first certificate).

Using Our SSL Certificate Checker

For a quick visual check, use our SSL Certificate Checker tool. It connects to any domain, retrieves the certificate, and reports:

• Whether the certificate is valid and trusted
• The certificate's issuer, subject, and SAN entries
• Exact expiry date and days remaining
• The TLS protocol version and cipher suite negotiated
• Whether the certificate chain is complete

This is particularly useful when you need an external perspective — your local machine may have cached certificates or custom trust store entries that mask problems visible to your end users.

Step-by-Step Fixes for Each Error Type

Fixing an Expired Certificate

1. Identify the expired certificate. Use openssl s_client or our SSL Checker to confirm which certificate in the chain has expired. Sometimes it's the leaf certificate; sometimes it's an intermediate that has expired.
2. Renew through your CA. If you purchased a certificate from a commercial CA (DigiCert, Sectigo, GoDaddy), log into your account, reissue or renew the certificate, and download the new files. If you use Let's Encrypt, run sudo certbot renew or sudo certbot certonly --nginx -d example.com.
3. Install the renewed certificate. Replace the old certificate and key files on your web server. For Nginx, update the ssl_certificate and ssl_certificate_key directives. For Apache, update SSLCertificateFile and SSLCertificateKeyFile.
4. Reload the web server. Run sudo nginx -t && sudo systemctl reload nginx or sudo apachectl graceful to apply the new certificate without downtime.
5. Verify the fix. Use our SSL Checker or openssl s_client to confirm the new certificate is being served and the expiry date is correct.
6. Set up automatic renewal. For Let's Encrypt, ensure the Certbot timer or cron job is active: sudo systemctl status certbot.timer. Test with sudo certbot renew --dry-run.

Fixing a Certificate Name Mismatch

1. Check the certificate's SAN entries. Run openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -ext subjectAltName to see exactly which domain names the certificate covers.
2. Identify all domains that need coverage. List every domain and subdomain that points to this server: example.com, www.example.com, api.example.com, etc.
3. Reissue the certificate. Request a new certificate that includes all required names in the SAN field. With Let's Encrypt: sudo certbot certonly --nginx -d example.com -d www.example.com -d api.example.com. For wildcard coverage: sudo certbot certonly --dns-cloudflare -d example.com -d *.example.com.
4. Update server configuration. If you run multiple sites on one server using SNI (Server Name Indication), ensure each virtual host or server block references the correct certificate for its domain.
5. Set up redirects. If users access your site via both www and non-www variants, set up a 301 redirect to canonicalize to one version. Both variants still need to be covered by the certificate so the redirect itself works over HTTPS.

Fixing an Incomplete Certificate Chain

1. Diagnose the missing intermediate. Run openssl s_client -connect example.com:443 -servername example.com -showcerts. Count the certificates returned. If you see only one (the leaf), the intermediates are missing.
2. Download the correct intermediate certificates. Your CA's documentation provides the intermediate certificate bundle. For Let's Encrypt, the fullchain.pem file already includes the leaf and intermediate — use it instead of cert.pem.
3. Concatenate the chain correctly. For Nginx, the ssl_certificate directive should point to a file containing the leaf certificate followed by all intermediate certificates, in order from leaf to root (do not include the root itself):
   cat cert.pem intermediate.pem > fullchain.pem
4. For Apache, use the SSLCertificateChainFile directive (Apache 2.4.8+: include intermediates in the SSLCertificateFile file directly).
5. Reload and verify. Reload the server and test with openssl s_client -showcerts to confirm all intermediates are now present. Also test in both Chrome and Firefox, since they handle missing intermediates differently.

Fixing Untrusted CA / Self-Signed Certificate Errors

For production websites, the only proper fix is to obtain a certificate from a publicly trusted CA. Let's Encrypt provides free certificates that are trusted by all modern browsers and operating systems.

For development environments, you have several options:

• Use mkcert (mkcert -install && mkcert localhost 127.0.0.1 ::1) to create locally-trusted development certificates. mkcert installs a local CA into your system and browser trust stores.
• Manually add the self-signed certificate to your OS trust store (Windows: Certificate Manager; macOS: Keychain Access; Linux: /usr/local/share/ca-certificates/).
• In Firefox, you can add a permanent exception for the specific site (not recommended for production).

For internal enterprise applications, deploy your organization's root CA certificate to all employee devices via Group Policy (Windows), MDM profiles (macOS/iOS), or configuration management tools (Linux).

Fixing Mixed Content

1. Find all insecure resources. Open your browser's DevTools console (F12 → Console) and look for mixed content warnings. Each warning identifies the insecure URL. You can also use the Content-Security-Policy-Report-Only header with a report-uri to collect mixed content violations at scale.
2. Update resource URLs. Change all http:// URLs to https://. For third-party resources, verify they support HTTPS. For internal resources, ensure your asset pipeline generates HTTPS URLs.
3. Check CSS and JavaScript files. Mixed content can be embedded inside stylesheets (url(http://...)) or JavaScript (fetch('http://...')). Search your codebase for http:// references.
4. Add the upgrade-insecure-requests CSP header. As a safety net, add Content-Security-Policy: upgrade-insecure-requests to your server's response headers. This instructs browsers to automatically upgrade HTTP requests to HTTPS before sending them.
5. Fix database content. CMS-based sites (WordPress, etc.) often have http:// URLs hardcoded in database content. Use a search-and-replace tool or SQL query to update them to https://.

Fixing Protocol Version and Cipher Suite Errors

1. Check current server configuration. Use openssl s_client -connect example.com:443 -tls1_2 and openssl s_client -connect example.com:443 -tls1_3 to test which protocol versions are supported. Or use our SSL Checker tool to see the negotiated protocol.
2. Enable TLS 1.2 and TLS 1.3. In Nginx: ssl_protocols TLSv1.2 TLSv1.3;. In Apache: SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1.
3. Configure modern cipher suites. Use Mozilla's SSL Configuration Generator (ssl-config.mozilla.org) to generate a recommended cipher suite configuration for your server software and desired compatibility level (Modern, Intermediate, or Old).
4. Restart and test. After updating the configuration, restart your web server and verify with openssl s_client or an online SSL test tool that TLS 1.2/1.3 connections succeed and no insecure protocols are offered.

Browser-Specific SSL Error Codes Reference

Different browsers display different error codes for the same underlying problems. Use this reference to map error codes to their root causes:

Google Chrome (and Chromium-based browsers: Edge, Brave, Opera)

• NET::ERR_CERT_DATE_INVALID — Certificate has expired or is not yet valid. Check the system clock first, then check the certificate's expiry date.
• NET::ERR_CERT_COMMON_NAME_INVALID — Domain name mismatch. The certificate does not cover the domain being visited.
• NET::ERR_CERT_AUTHORITY_INVALID — The certificate is self-signed, or the chain is incomplete, or the issuing CA is not trusted.
• NET::ERR_CERT_REVOKED — The certificate has been explicitly revoked by the CA via CRL or OCSP.
• NET::ERR_CERT_TRANSPARENCY_REQUIRED — The certificate does not have the required Certificate Transparency (CT) Signed Certificate Timestamps (SCTs).
• ERR_SSL_PROTOCOL_ERROR — General TLS handshake failure. Usually a protocol or cipher mismatch.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH — No common protocol version or cipher suite between browser and server.

Mozilla Firefox

• SEC_ERROR_EXPIRED_CERTIFICATE — Certificate has expired.
• SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE — An intermediate or root CA certificate in the chain has expired.
• SSL_ERROR_BAD_CERT_DOMAIN — Domain name mismatch.
• SEC_ERROR_UNKNOWN_ISSUER — Untrusted issuer. Missing intermediate certificates, self-signed certificate, or unknown CA.
• SEC_ERROR_REVOKED_CERTIFICATE — Certificate has been revoked.
• SSL_ERROR_NO_CYPHER_OVERLAP — No common cipher suite between browser and server.
• SSL_ERROR_PROTOCOL_VERSION_ALERT — Server does not support any protocol version the browser will accept.
• MOZILLA_PKIX_ERROR_MITM_DETECTED — Firefox detected a man-in-the-middle proxy (common with antivirus software that intercepts HTTPS).

Client-Side Causes of SSL Errors

Not all SSL errors indicate a server problem. Before contacting the website owner or checking server configuration, rule out these client-side causes:

Incorrect System Clock

SSL certificates have validity windows defined by specific dates. If your computer's clock is significantly wrong (set to the past or future), valid certificates will appear expired or not yet valid. This is the most common cause of ERR_CERT_DATE_INVALID errors that affect every HTTPS website you visit.

Fix: On Windows, right-click the clock → "Adjust date/time" → enable "Set time automatically." On macOS, System Settings → General → Date & Time → enable "Set date and time automatically." On Linux, run sudo timedatectl set-ntp true.

Outdated Browser or Operating System

Very old browsers and operating systems may not have recent root CA certificates in their trust stores. For example, Let's Encrypt's ISRG Root X1 was not trusted by Android devices before version 7.1.1 until cross-signing was arranged. Older Windows versions may lack newer root certificates.

Fix: Update your browser and operating system to the latest versions. Install pending Windows Updates or macOS updates, which include trust store updates.

Antivirus / Security Software HTTPS Interception

Many antivirus programs (Avast, Kaspersky, ESET, Bitdefender) install a local root CA certificate and intercept HTTPS connections to scan them for malware. This effectively performs a man-in-the-middle on every HTTPS connection. If the antivirus CA certificate is not properly installed, or if it has expired, you will see SSL errors on every site.

Fix: Disable HTTPS scanning in your antivirus settings (often called "SSL scanning," "Encrypted connections scanning," or "Web shield"). In Firefox, check about:preferences#privacy → "Certificates" → "View Certificates" → "Authorities" to see if your antivirus has added its own root CA.

Corporate Proxy / Firewall

Corporate networks often use SSL-intercepting proxies (Zscaler, Blue Coat, Palo Alto) that decrypt HTTPS traffic for inspection. These proxies present their own certificates for every website. If your device does not have the proxy's root CA certificate installed, all HTTPS sites will show errors.

Fix: Contact your IT department. The proxy's root CA certificate needs to be installed on your device. This is typically deployed automatically via Group Policy on corporate-managed machines.

Server-Side SSL Configuration Fixes

Nginx SSL Configuration

A properly configured Nginx SSL server block should include the full certificate chain, strong protocols, and modern cipher suites:

• ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; — Use fullchain.pem, not cert.pem, to include intermediate certificates.
• ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
• ssl_protocols TLSv1.2 TLSv1.3; — Disable SSLv3, TLS 1.0, and TLS 1.1.
• ssl_prefer_server_ciphers off; — With TLS 1.3, let the client choose; TLS 1.3 only allows secure ciphers anyway.
• ssl_session_timeout 1d; and ssl_session_cache shared:SSL:10m; — Enable session reuse for performance.
• ssl_stapling on; and ssl_stapling_verify on; — Enable OCSP stapling so clients don't need to contact the CA directly.
• add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always; — Enable HSTS to prevent protocol downgrade attacks.

Apache SSL Configuration

For Apache 2.4+, key directives include:

• SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
• SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
• SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
• SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
• SSLHonorCipherOrder off
• Header always set Strict-Transport-Security "max-age=63072000"

Let's Encrypt Certificate Renewal

Let's Encrypt certificates are valid for 90 days. Certbot, the most popular ACME client, is designed to automate renewal. However, renewal failures are a common cause of expired certificate errors.

How Certbot Renewal Works

Certbot stores certificate configurations in /etc/letsencrypt/renewal/. Running sudo certbot renew checks all certificates and renews any that are within 30 days of expiry. It uses the same validation method (HTTP-01 or DNS-01) that was used during the original issuance.

Common Renewal Failures

• Port 80 blocked: The HTTP-01 challenge requires port 80 to be accessible from the internet. If a firewall blocks port 80, or if the web server is not running, renewal fails. Check with our SSL Checker or a port scanner.
• DNS validation failure: Wildcard certificates require DNS-01 validation. If the DNS API credentials have expired or the DNS provider changed, renewal fails. Update the credentials in the Certbot DNS plugin configuration.
• Web server conflict: If you used the --standalone plugin, Certbot needs to temporarily bind to port 80 or 443, which fails if another service is already using that port.
• Certbot timer not enabled: Verify the systemd timer is active: sudo systemctl status certbot.timer. On systems using cron, check crontab -l and /etc/cron.d/certbot.

Testing Renewal

Always test renewal before it's critical:

• sudo certbot renew --dry-run — Simulates the renewal process without making changes. Fix any errors reported before they cause a real failure.
• sudo certbot certificates — Lists all managed certificates with their expiry dates and domains.

Testing Your Fix with an SSL Checker

After applying any fix, always verify from an external perspective. Your local machine may have cached certificates, custom trust store entries, or DNS cache that masks issues visible to your users.

1. Use our SSL Certificate Checker to verify the certificate is valid, the chain is complete, the expiry date is correct, and the protocol version is modern.
2. Test in multiple browsers. At minimum, test in Chrome and Firefox, since they use different trust stores. Test in a private/incognito window to avoid cached certificate state.
3. Test from different networks. If possible, test from outside your local network (e.g., use a mobile device on cellular data) to rule out local DNS or proxy issues.
4. Check the full chain. Run openssl s_client -connect example.com:443 -servername example.com -showcerts and verify the correct number of certificates are returned (typically 2 or 3: the leaf plus one or two intermediates).
5. Monitor ongoing. Set up automated certificate monitoring to alert you before certificates expire. Services like Certbot's built-in checks, UptimeRobot, or custom cron jobs that check openssl output can prevent future outages.

Frequently Asked Questions

What does "Your connection is not private" mean?

This browser warning means the SSL/TLS certificate presented by the website could not be validated. Common causes include an expired certificate, a certificate issued for a different domain name (name mismatch), a self-signed certificate not trusted by public CAs, or an incomplete certificate chain where the server is not sending required intermediate certificates.

How do I fix an expired SSL certificate?

Renew the certificate through your Certificate Authority or hosting provider. If you use Let's Encrypt with Certbot, run sudo certbot renew. Install the renewed certificate on your web server, reload the server configuration, and verify with our SSL Checker. Set up automatic renewal to prevent future expirations.

Why does Chrome show NET::ERR_CERT_AUTHORITY_INVALID?

Chrome displays this error when it cannot build a chain of trust from the website's certificate to a trusted root CA. This typically means the server is not sending required intermediate certificates, the certificate is self-signed, or it was issued by an unknown CA. Fix it by configuring the server to send the complete certificate chain.

What is a certificate name mismatch error?

A name mismatch (ERR_CERT_COMMON_NAME_INVALID) occurs when the domain in the address bar does not match any domain listed in the certificate's SAN (Subject Alternative Name) field. For example, visiting www.example.com when the certificate only covers example.com. Fix this by reissuing the certificate to include all required domain names.

How do I fix mixed content warnings on HTTPS?

Find all resources loaded over http:// using your browser's DevTools console. Update their URLs to https://. Check HTML, CSS (url() values), and JavaScript (fetch() calls). Add the Content-Security-Policy: upgrade-insecure-requests header as a safety net. For CMS-based sites, run a database search-and-replace to update stored URLs.

What causes an incomplete certificate chain error?

An incomplete chain error means the server sends only its leaf certificate without the required intermediate CA certificates. Browsers need the full chain to verify trust. Fix this by configuring your web server to send the leaf certificate concatenated with all intermediates. For Let's Encrypt, use fullchain.pem instead of cert.pem.

How do I fix SSL errors on a self-signed certificate?

For production websites, replace the self-signed certificate with one from a trusted CA like Let's Encrypt (free). For development, use mkcert to create locally-trusted certificates. For internal enterprise applications, deploy your organization's root CA certificate to all devices via Group Policy or MDM.

Why does my SSL certificate work in Chrome but not Firefox?

Chrome uses your operating system's trust store, while Firefox maintains its own. If an intermediate certificate is cached in the OS store but missing from the server configuration, Chrome may work while Firefox fails. The fix is to ensure the server sends the complete certificate chain so it works regardless of client-side caching.