SSL Certificate Troubleshooting Guide

SSL errors are the internet's version of a locked door with no key. Your site is up, your server is running, your content is right there, but visitors cannot get through. Instead they see a full-screen browser warning that tells them your site is not safe.

The frustrating part is that SSL errors have dozens of possible causes. A certificate can be expired, misconfigured, incomplete, revoked, or simply mismatched with the domain it is serving. The error messages browsers display are often cryptic, and the same underlying problem can surface differently in Chrome, Firefox, Safari, and Edge.

This guide covers every common SSL/TLS error you are likely to encounter. For each one, you will learn what the user sees, what is actually broken, and exactly how to fix it. Whether you are debugging a browser warning, a Cloudflare error page, or a server-side certificate chain issue, the answer is here.

---

Browser SSL errors

Browser errors are the most visible SSL failures because they directly block your visitors. Each browser displays its own variation, but the underlying error codes are consistent. Here are the ones you will see most often.

NET::ERR_CERT_DATE_INVALID

What the user sees: Chrome displays "Your connection is not private" with the error code NET::ERR_CERT_DATE_INVALID. Firefox shows "Warning: Potential Security Risk Ahead" with SEC_ERROR_EXPIRED_CERTIFICATE. Safari displays "This Connection Is Not Private."

What it means: The certificate's validity period does not include the current date. Either the certificate has expired (the notAfter date is in the past) or it is not yet valid (the notBefore date is in the future). Expired certificates are by far the more common case. [1]

Step-by-step fix:

1. Check the certificate's expiry date. In Chrome, click the padlock icon (or the "Not Secure" warning), then click "Certificate." Look at the "Valid to" field. You can also use OpenSSL from the command line. See how to check SSL with OpenSSL for the exact commands.
2. If the certificate has expired, renew it immediately. For Let's Encrypt certificates, run certbot renew --force-renewal. For commercial certificates, log into your CA's portal and reissue. Follow the SSL certificate renewal guide for a full walkthrough.
3. Install the new certificate on your server and restart your web server process (Apache, Nginx, or whatever you are running).
4. Verify the fix by loading the site in a browser and checking the certificate details. Also verify with an external tool to rule out caching. See how to validate SSL certificate.
5. If the certificate is not yet valid (the "Valid from" date is in the future), check your server's system clock. A server with an incorrect clock will reject certificates that are actually valid. Run date on the server and compare to actual UTC time. Fix with NTP if needed.

For a deeper look at the consequences of letting a certificate expire, see what happens when SSL expires.

ERR_CERT_AUTHORITY_INVALID

What the user sees: Chrome shows "Your connection is not private" with NET::ERR_CERT_AUTHORITY_INVALID. Firefox displays SEC_ERROR_UNKNOWN_ISSUER.

What it means: The browser does not trust the certificate authority (CA) that issued the certificate. This happens in several scenarios: the certificate is self-signed, the intermediate certificate chain is incomplete, or the certificate was issued by a CA that the browser does not recognize. [2]

Step-by-step fix:

1. Determine whether the certificate is self-signed. Check the "Issued By" field in the certificate details. If the issuer is the same as the subject, it is self-signed. Self-signed certificates should never be used in production. See self-signed certificates for why and what to do instead.
2. If the certificate is not self-signed, check the certificate chain. Use OpenSSL: openssl s_client -connect yourdomain.com:443 -showcerts. You should see your server certificate plus one or more intermediate certificates. If intermediates are missing, the chain is broken.
3. Download the correct intermediate certificate(s) from your CA's documentation. Most CAs provide a "certificate bundle" or "CA bundle" file.
4. Configure your web server to send the full chain. In Nginx, concatenate your server certificate and the intermediate(s) into a single file for ssl_certificate. In Apache, use the SSLCertificateChainFile directive or include the intermediates in SSLCertificateFile.
5. Test the chain using an online SSL checker or with OpenSSL. See SSL certificate chain explained for a detailed breakdown of how chains work and how to verify them.

ERR_CERT_COMMON_NAME_INVALID

What the user sees: Chrome shows NET::ERR_CERT_COMMON_NAME_INVALID. Firefox shows SSL_ERROR_BAD_CERT_DOMAIN.

What it means: The domain name in the browser's address bar does not match any of the domain names listed in the certificate. The certificate might be for www.example.com but the user visited example.com, or vice versa. It can also happen when a certificate is installed on the wrong server or when a load balancer routes traffic to a backend with someone else's certificate. [3]

Step-by-step fix:

1. Inspect the certificate and check the Common Name (CN) and Subject Alternative Names (SAN) fields. The domain the user is visiting must appear in one of these fields.
2. If the certificate covers www.example.com but not example.com (or the reverse), you need either a new certificate that covers both names or a redirect from the uncovered name to the covered one. For redirect setup, see the HTTP to HTTPS redirect guide.
3. If you serve multiple domains from the same server, make sure your web server is configured with SNI (Server Name Indication) so that it serves the correct certificate for each domain. Without SNI, the server may present the default certificate regardless of which domain was requested.
4. If you recently changed domain names or added subdomains, reissue the certificate with all required names included. SAN certificates can cover multiple domains.
5. Verify that your DNS is pointing to the correct server. A DNS misconfiguration can route traffic to a server that has a valid certificate for a different domain. Use how to check DNS records to verify.

ERR_SSL_PROTOCOL_ERROR

What the user sees: Chrome shows ERR_SSL_PROTOCOL_ERROR. Firefox shows PR_END_OF_FILE_ERROR or SSL_ERROR_RX_RECORD_TOO_LONG. The page does not load at all.

What it means: The browser and server could not agree on how to establish a secure connection. The TLS handshake failed at the protocol level. Common causes include misconfigured server SSL settings, the server sending HTTP responses on port 443, or firewall interference. [4]

Step-by-step fix:

1. Verify that your web server is actually configured for SSL on port 443. If the server is sending plain HTTP on port 443, the browser's TLS handshake will fail immediately. Check your server configuration for a valid listen 443 ssl block (Nginx) or <VirtualHost *:443> with SSLEngine on (Apache).
2. Check that your SSL certificate and private key files exist at the paths specified in your server configuration and that the web server process has read permission.
3. Test the connection with OpenSSL: openssl s_client -connect yourdomain.com:443. If you see "CONNECTED" followed by certificate information, the server is speaking TLS. If the connection hangs or returns garbage, the server is not configured for TLS on that port.
4. Check for firewall or proxy interference. Some corporate firewalls or security appliances perform TLS inspection and can break the handshake if misconfigured. If you use a CDN or reverse proxy, make sure it is configured to terminate TLS correctly.
5. Check your server logs for more specific error messages. Apache logs SSL errors in the error log. Nginx logs them with the ssl tag.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

What the user sees: Chrome shows ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Firefox may show SSL_ERROR_NO_CYPHER_OVERLAP.

What it means: The browser and server could not find a common TLS protocol version or cipher suite to use. This typically happens when the server is configured with outdated protocols that the browser has dropped support for, or when the server only supports cipher suites the browser considers insecure. [4]

Step-by-step fix:

1. Check which TLS versions your server supports. Modern browsers require TLS 1.2 at minimum and prefer TLS 1.3. If your server only offers TLS 1.0 or 1.1, modern browsers will refuse to connect. Use openssl s_client -connect yourdomain.com:443 -tls1_2 to test TLS 1.2 support.
2. Review your server's cipher suite configuration. Remove any cipher suites using RC4, 3DES, DES, or MD5. These are considered insecure and most browsers no longer support them.
3. For Nginx, set ssl_protocols TLSv1.2 TLSv1.3; and use a modern cipher string. For Apache, set SSLProtocol -all +TLSv1.2 +TLSv1.3 and configure SSLCipherSuite with current recommendations.
4. If you recently updated your server or changed SSL settings, revert to the previous configuration and test. Sometimes well-meaning security hardening accidentally removes all compatible ciphers.
5. Test with the Mozilla SSL Configuration Generator [5] to get a known-good configuration for your server software and version.
6. If the error only affects certain browsers (especially older ones), the server may be correctly configured for modern standards but the client is too old. This is a conscious tradeoff between security and compatibility.

Cloudflare SSL errors

If your site is behind Cloudflare, you have two TLS connections to manage: visitor to Cloudflare (the "edge" certificate) and Cloudflare to your origin server (the "origin" certificate). Errors on either leg produce Cloudflare-specific error pages.

Error 526: Invalid SSL Certificate

What the user sees: A Cloudflare error page with "Error 526: Invalid SSL Certificate."

What it means: Cloudflare tried to connect to your origin server over HTTPS but your origin's SSL certificate is invalid. It could be expired, self-signed, missing, or the domain name does not match. This error only occurs when your Cloudflare SSL/TLS encryption mode is set to "Full (Strict)." [6]

Step-by-step fix:

1. Check your origin server's certificate directly (bypassing Cloudflare) using openssl s_client -connect your-origin-ip:443 -servername yourdomain.com. Look for expiry, chain, and name mismatches.
2. If the origin certificate is expired, renew it. If it is self-signed, replace it with a valid certificate. You can use a free Cloudflare Origin CA certificate, which Cloudflare will trust even though public browsers will not.
3. If you do not need end-to-end encryption to the origin (and you understand the security implications), you can change your SSL mode to "Full" instead of "Full (Strict)." Full mode still encrypts the connection but does not validate the origin certificate. This is a workaround, not a best practice.
4. Verify that your origin server is listening on port 443 and serving the certificate for the correct domain.
5. After fixing, purge Cloudflare's cache and wait a few minutes for the change to take effect.

For a dedicated walkthrough, see SSL error code 526.

Error 525: SSL Handshake Failed

What the user sees: A Cloudflare error page with "Error 525: SSL Handshake Failed."

What it means: Cloudflare connected to your origin server on port 443 but the TLS handshake failed. The origin server is not properly configured for SSL. Common causes include no certificate installed on the origin, mismatched key and certificate files, or TLS version incompatibilities between Cloudflare and the origin. [6]

Step-by-step fix:

1. Confirm your origin has a valid SSL certificate installed and your web server is configured to serve it on port 443. Test with openssl s_client -connect your-origin-ip:443 -servername yourdomain.com.
2. Check that the certificate and private key match. The key must correspond to the certificate. Mismatched key/cert pairs cause handshake failures. See the "Key mismatch" section below for how to verify.
3. Make sure your origin supports TLS 1.2 or higher. Cloudflare requires at least TLS 1.2 for origin connections.
4. Check for firewall rules that might be interfering with the connection from Cloudflare's IP ranges. Cloudflare publishes its IP ranges at cloudflare.com/ips.
5. Review your origin server's error logs for specific TLS error messages.

Error 521: Web Server Is Down

What the user sees: A Cloudflare error page with "Error 521: Web Server Is Down."

What it means: Cloudflare could not establish any TCP connection to your origin server. The origin is not responding on port 443 (or port 80 if using Flexible SSL mode). This is not strictly an SSL error but it often appears during SSL troubleshooting because switching SSL modes or reconfiguring the origin can inadvertently take the web server offline. [6]

Step-by-step fix:

1. Verify that your origin web server is running. SSH into the server and check the process: systemctl status nginx or systemctl status apache2.
2. Check that the server is listening on the expected port: ss -tlnp | grep 443.
3. Verify that your server's firewall allows incoming connections from Cloudflare's IP ranges. This is the most common cause of Error 521. If you use iptables, ufw, or a cloud security group, whitelist the ranges from cloudflare.com/ips.
4. If you recently changed your Cloudflare SSL mode from "Flexible" to "Full," your origin must now accept HTTPS connections on port 443. If it was previously only listening on port 80, that is the problem.
5. Check that your origin IP has not changed without updating Cloudflare's DNS record.

Server-side SSL errors

These errors typically show up in server logs or when testing with command-line tools. They are not always visible to end users but they cause connection failures that affect everything from browsers to API clients.

Incomplete certificate chain

What it looks like: Some browsers show the site as secure while others show a warning. Mobile browsers and API clients fail more often than desktop browsers. OpenSSL testing shows "verify error:num=21:unable to verify the first certificate."

What it means: Your server is sending its own certificate but not the intermediate certificate(s) needed to chain it back to a trusted root CA. Some browsers and operating systems cache intermediates from previous connections, which is why the site works in some environments but not others. Mobile browsers and fresh browser profiles are more likely to fail because they have not cached the intermediates. [7]

Step-by-step fix:

1. Test the chain: openssl s_client -connect yourdomain.com:443. Look at the certificate chain output. You should see at least two certificates (your server cert and the intermediate). If you only see one, the chain is incomplete.
2. Download the correct intermediate certificate(s) from your CA. Every CA publishes their intermediate certificates. For Let's Encrypt, the intermediate is available at letsencrypt.org/certificates.
3. Create a certificate bundle by concatenating your server certificate and the intermediate(s) in order: server cert first, then intermediate(s), with the root CA last (or omitted, since browsers already have roots).
4. In Nginx, point ssl_certificate to the bundle file. In Apache, use SSLCertificateChainFile or include intermediates in your SSLCertificateFile.
5. Restart your web server and test again with OpenSSL. The chain should now show all certificates and "Verify return code: 0 (ok)."

For a thorough explanation of how chains work, see SSL certificate chain explained.

Private key mismatch

What it looks like: The web server refuses to start or reload, with errors like "SSL_CTX_use_PrivateKey_file ... error" (Nginx) or "AH02572: Failed to configure certificate ... key values mismatch" (Apache).

What it means: The private key file on the server does not match the certificate. This happens when you generate a new CSR (and new key) but install an old certificate, or when you install a renewed certificate without updating the key, or when files get mixed up during deployment.

Step-by-step fix:

1. Extract the modulus from the certificate: openssl x509 -noout -modulus -in cert.pem | openssl md5.
2. Extract the modulus from the private key: openssl rsa -noout -modulus -in key.pem | openssl md5.
3. Compare the two MD5 hashes. They must be identical. If they differ, the key and certificate do not match.
4. If they do not match, determine which one is correct. If you just received a new certificate from your CA, the key you generated alongside the CSR is the matching key. If you cannot find the matching key, generate a new CSR and key pair, then reissue the certificate from your CA.
5. Update your server configuration to point to the matching key and certificate files, then reload.

Mixed content warnings

What it looks like: The browser shows a padlock with a warning icon, or the padlock is missing entirely. The console shows "Mixed Content" warnings. The page loads but some resources (images, scripts, stylesheets) are blocked or loaded insecurely.

What it means: The page is loaded over HTTPS but some embedded resources (images, JavaScript files, CSS files, iframes) are referenced with http:// URLs. Modern browsers block mixed active content (scripts, iframes) entirely and may warn about mixed passive content (images). [8]

Step-by-step fix:

1. Open the browser's developer console (F12) and look for mixed content warnings. They will identify the specific URLs that are loaded over HTTP.
2. Update those URLs to use HTTPS. If the resource is on your own server, change http:// to https:// or use protocol-relative URLs (//). If it is a third-party resource, verify the third party supports HTTPS (almost everyone does in 2026).
3. For a site-wide fix, add a Content Security Policy header: Content-Security-Policy: upgrade-insecure-requests. This tells browsers to automatically upgrade HTTP requests to HTTPS for all resources on the page.
4. Check your database and templates for hardcoded http:// URLs. CMS platforms like WordPress often store full URLs in the database.
5. Set up proper HTTP to HTTPS redirects. See the HTTP to HTTPS redirect guide for configuration details.

Certificate-specific errors

These errors relate to the certificate itself rather than the server configuration.

Expired certificate

What the user sees: The specific error depends on the browser, but it always blocks access. See the NET::ERR_CERT_DATE_INVALID section above for details.

Why it happens: Certificates have a fixed validity period. Let's Encrypt certificates last 90 days. Commercial certificates typically last one year. When the expiry date passes and the certificate has not been renewed, browsers reject it immediately. [1]

The most common reasons for certificate expiry are:

• Auto-renewal failed silently (DNS validation issue, expired API credentials, permission changes)
• The person responsible for renewal left the organization
• The certificate was manually provisioned and nobody set up renewal reminders
• Payment method on the CA account expired

Prevention: Monitor all certificates with escalating alerts well before expiry. Do not rely solely on auto-renewal. See how to check SSL certificate for manual verification methods and set up automated monitoring for ongoing coverage.

Revoked certificate

What the user sees: Chrome may show ERR_CERT_REVOKED. Firefox shows SEC_ERROR_REVOKED_CERTIFICATE. Some browsers silently fail OCSP checks and do not display an error at all, depending on their revocation checking behavior.

What it means: The certificate authority has revoked the certificate before its natural expiry. This can happen because the private key was compromised, the certificate was issued in error, the domain ownership changed, or the CA itself was compromised. [9]

Step-by-step fix:

1. Verify the revocation status. Check the certificate's CRL Distribution Points or OCSP responder URL (found in the certificate's extensions). You can test OCSP with: openssl ocsp -issuer intermediate.pem -cert server.pem -url http://ocsp.ca.com -resp_text.
2. Contact your CA to understand why the certificate was revoked. If it was revoked in error, the CA may be able to un-revoke it (though this is rare).
3. In most cases, you need to issue a new certificate. Generate a new private key and CSR, submit to your CA, and install the new certificate.
4. If the revocation was due to key compromise, make sure you generate a completely new key pair. Do not reuse the compromised key.
5. Investigate how the compromise happened and close the vulnerability before deploying the new certificate.

Self-signed certificate in production

What the user sees: ERR_CERT_AUTHORITY_INVALID in Chrome. SEC_ERROR_UNKNOWN_ISSUER in Firefox. Every visitor sees a warning page.

What it means: The certificate was generated locally and is not signed by a trusted CA. Browsers have no way to verify the certificate's authenticity because it is not backed by any trusted third party. [2]

Self-signed certificates are appropriate for local development and testing. They are never appropriate for production websites or public-facing services. See self-signed certificates for a full explanation.

Step-by-step fix:

1. Replace the self-signed certificate with one from a trusted CA. Let's Encrypt provides free, trusted certificates. There is no reason to use self-signed certificates in production.
2. For Let's Encrypt, install Certbot and run certbot --nginx or certbot --apache for automatic configuration.
3. If you need a commercial certificate (for EV validation or specific organizational requirements), purchase one from a trusted CA and follow their issuance process.
4. After installing the trusted certificate, verify that the full chain is served correctly. See how to install SSL for server-specific instructions.
5. Set up auto-renewal and monitoring so the new certificate does not expire unnoticed.

Diagnosing SSL errors systematically

When you encounter an SSL error that does not match the specific patterns above, or when you need to diagnose an unfamiliar issue, follow this systematic approach.

Step 1: Check the certificate details

Start by examining the certificate itself. In Chrome, click the padlock (or "Not Secure" label), click "Connection is secure" or "Certificate is not valid," then click the certificate icon to see full details. Check:

• Validity period. Is the certificate current?
• Subject / SAN. Does the certificate cover the domain you are visiting?
• Issuer. Is it a recognized CA?

From the command line, use openssl s_client -connect yourdomain.com:443 -servername yourdomain.com to pull the certificate and chain. See how to check SSL certificate and how to check SSL with OpenSSL for detailed instructions.

Step 2: Verify the certificate chain

An incomplete chain is one of the most common and hardest-to-diagnose SSL problems because it works in some browsers and not others.

Test the chain with: openssl s_client -connect yourdomain.com:443. Look at the output under "Certificate chain." Each certificate in the chain should have a valid issuer relationship to the one above it. The chain should terminate at a trusted root.

If you see "verify error:num=21:unable to verify the first certificate," your server is not sending intermediates. See SSL certificate chain explained for how to fix this.

Step 3: Test from multiple locations

An SSL error that only appears for some users may be caused by CDN misconfiguration, regional DNS differences, or certificate deployment that has not propagated to all edge nodes. Test from different networks, devices, and geographic locations.

Step 4: Check DNS and CAA records

If you are getting certificate issuance failures (your CA refuses to issue a certificate), check your DNS CAA records. CAA records specify which CAs are authorized to issue certificates for your domain. If your CA is not listed, issuance will be blocked. See how to check DNS records to verify your CAA configuration.

Step 5: Review server logs

Your web server's error log often contains the most specific information about SSL failures. Check:

• Nginx: /var/log/nginx/error.log
• Apache: /var/log/apache2/error.log or /var/log/httpd/error_log
• Application logs for any TLS-related errors

Common SSL errors by platform

WordPress

WordPress sites commonly encounter SSL errors when:

• The site URL in the database still uses http:// after installing a certificate, causing mixed content
• A plugin or theme loads resources over HTTP
• The wp-config.php file does not define FORCE_SSL_ADMIN
• A caching plugin serves stale HTTP content after the HTTPS migration

Fix mixed content in WordPress by updating siteurl and home in the database to use https://, then search-and-replace all http://yourdomain.com references.

cPanel / Plesk

Hosting control panels sometimes install certificates incorrectly:

• The certificate is installed but the intermediate is not, causing chain errors
• The certificate is installed on the wrong domain in a shared hosting environment
• The private key was not saved correctly during CSR generation

Use the control panel's SSL status tool to verify the installation, or test with OpenSSL directly.

Docker / containerized environments

Containerized deployments frequently have SSL issues because:

• The certificate files are not mounted correctly into the container
• The container's trust store does not include the intermediate certificates
• Certificate renewal happens outside the container but the container is not restarted to pick up the new certificate
• Let's Encrypt's Certbot runs on the host but the web server runs in a container with a different webroot

Map certificate volumes correctly and set up post-renewal hooks that restart or reload the container.

Quick reference table

| Error | Most likely cause | First thing to check | |---|---|---| | NET::ERR_CERT_DATE_INVALID | Expired certificate | Certificate expiry date | | ERR_CERT_AUTHORITY_INVALID | Missing intermediate or self-signed | Certificate chain | | ERR_CERT_COMMON_NAME_INVALID | Domain mismatch | SAN fields in certificate | | ERR_SSL_PROTOCOL_ERROR | Server not configured for TLS | Server SSL configuration | | ERR_SSL_VERSION_OR_CIPHER_MISMATCH | Outdated TLS version or ciphers | Supported protocols and ciphers | | Cloudflare 526 | Invalid origin certificate | Origin certificate validity | | Cloudflare 525 | Origin TLS handshake failed | Origin SSL configuration | | Cloudflare 521 | Origin server unreachable | Server running, firewall rules | | ERR_CERT_REVOKED | Certificate revoked by CA | OCSP / CRL status | | Mixed content warnings | HTTP resources on HTTPS page | Browser console for URLs |

When to escalate

Most SSL errors can be resolved by the person who manages the server. But some situations require escalation:

• CA-side issues. If your CA's OCSP responder is down or returning incorrect results, you cannot fix that. Contact the CA.
• Registrar/DNS issues. If CAA records are preventing certificate issuance and you do not control DNS, escalate to whoever manages your DNS records.
• CDN or hosting provider issues. If the SSL error originates at the CDN or hosting layer, and you do not have direct access to that configuration, contact the provider.
• Compromised private keys. If you suspect a key compromise, escalate to your security team immediately. Revoke the certificate, generate new keys, and investigate the breach before deploying a replacement.

---

References

1. CA/Browser Forum, "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates." https://cabforum.org/baseline-requirements/
2. Mozilla, "How to troubleshoot security error codes on secure websites," Mozilla Support. https://support.mozilla.org/en-US/kb/error-codes-secure-websites
3. Chromium, "Certificate Errors: ERR_CERT_COMMON_NAME_INVALID," Chromium Documentation. https://chromium.googlesource.com/chromium/src/+/master/net/cert/
4. Mozilla, "Security/Server Side TLS," Mozilla Wiki. https://wiki.mozilla.org/Security/Server_Side_TLS
5. Mozilla, "SSL Configuration Generator," Mozilla. https://ssl-config.mozilla.org/
6. Cloudflare, "Troubleshooting SSL errors," Cloudflare Support. https://developers.cloudflare.com/ssl/troubleshooting/
7. DigiCert, "Fix Common SSL Certificate Errors," DigiCert Knowledge Base. https://www.digicert.com/kb/ssl-certificate-installation/
8. Mozilla, "Mixed Content," MDN Web Docs. https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content
9. Let's Encrypt, "Revoking Certificates," Let's Encrypt Documentation. https://letsencrypt.org/docs/revoking/