Common SSL/TLS Errors

Every SSL/TLS error you encounter is your browser doing exactly what it should: refusing to establish a connection it can't verify is secure. These aren't bugs or oversights. They're your browser saying "I can't prove this connection is safe, and I won't pretend otherwise."

Understanding what each error means—and why browsers are so strict about them—helps you fix issues quickly and appreciate why the strictness matters.

Why Browsers Are Strict

During the TLS handshake, your browser validates the server's certificate and negotiates encryption. If anything fails validation, the browser refuses to proceed. This strictness exists because accepting invalid certificates could expose you to man-in-the-middle attacks—someone intercepting your "secure" connection without you knowing.

Your browser is not being difficult. It's refusing to lie to you about security.

Most errors fall into a few categories: the certificate has expired or isn't valid yet, the certificate authority isn't trusted, the domain names don't match, the certificate chain is incomplete, the client and server can't agree on encryption, or the certificate has been revoked.

ERR_CERT_DATE_INVALID

The certificate has expired or isn't valid yet.

This happens when certificates aren't renewed before expiration (the most common cause), when a certificate was issued for a future date and the server clock is wrong, or when the visitor's system clock is incorrect—making valid certificates appear expired.

To fix it, check the certificate's actual validity dates using browser developer tools or openssl s_client. Renew expired certificates immediately. Verify both server and client system clocks are accurate using NTP. For visitors reporting this error on a valid certificate, ask them to check their system time.

Certificate expiration is entirely preventable with monitoring and automated renewal through services like Let's Encrypt.

ERR_CERT_AUTHORITY_INVALID

The certificate isn't signed by a Certificate Authority your browser trusts.

This occurs with self-signed certificates not in the browser's trust store, certificates from private enterprise CAs not installed on the client machine, certificates from CAs that browsers have distrusted, or certificates from regional CAs not yet widely trusted.

For public websites, use certificates from established CAs like Let's Encrypt, DigiCert, or GlobalSign. For internal sites using a private CA, distribute your CA's root certificate to all client machines through Group Policy, MDM, or configuration management.

Self-signed certificates should never appear on public production websites. They're fine for local development, but that's it.

ERR_CERT_COMMON_NAME_INVALID

The certificate doesn't cover the domain you're accessing.

This happens when the certificate is for www.example.com but you're accessing example.com (or vice versa), when the certificate is for an entirely different domain, when wildcard certificates don't cover the specific subdomain, or when accessing the site by IP address when the certificate only covers domain names.

Modern certificates use Subject Alternative Names (SANs) to list all covered domains. Make sure your certificate includes every domain and subdomain users might access. If you use both www.example.com and example.com, both must be in the certificate. Redirect users to whichever domain the certificate covers, or include both.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

The client and server couldn't agree on how to encrypt the connection.

This means the server only supports TLS 1.0 or 1.1 (which modern browsers have disabled), the server's cipher suites don't overlap with what the client supports, or server misconfiguration is preventing negotiation.

Enable TLS 1.2 and TLS 1.3 on your server. Configure strong cipher suites—ECDHE key exchange with AES-GCM or ChaCha20-Poly1305. Test your configuration with SSL Labs (ssllabs.com/ssltest) to see exactly what versions and ciphers your server offers.

This error is increasingly common as browsers drop support for older, weaker protocols. The fix is always on the server side.

SEC_ERROR_UNKNOWN_ISSUER (Firefox)

Firefox-specific error indicating the certificate chain doesn't lead to a trusted root.

This happens when the server doesn't send intermediate certificates (the most common cause), when intermediates are sent in the wrong order, when corporate proxies or antivirus software are intercepting HTTPS with their own certificates, or when a CA isn't in Firefox's trust store.

Firefox maintains its own certificate trust store, separate from the operating system. If only Firefox shows this error while Chrome and Edge work fine, the issue is likely Firefox-specific trust or corporate HTTPS interception.

Configure your server to send the complete certificate chain: your certificate first, then intermediates, with the root CA omitted (browsers have roots built in). Test with multiple browsers to isolate Firefox-specific issues.

NET::ERR_CERT_REVOKED

The Certificate Authority has explicitly revoked this certificate.

Certificates get revoked when the private key was compromised, when the certificate was issued improperly, when domain ownership changed, or when the CA made a mistake.

This error usually means something genuinely bad happened. Investigate why the certificate was revoked. Obtain a new certificate with a freshly generated private key. If the revocation was an error, contact your CA—but verify this thoroughly before assuming it was a mistake.

ERR_SSL_PROTOCOL_ERROR

A general failure during the TLS handshake.

This catch-all error can mean network issues or corrupted packets, a proxy or firewall interfering with TLS, server misconfiguration, incompatible TLS extensions, or antivirus software scanning HTTPS traffic.

Test from different networks to rule out local network issues. Temporarily disable antivirus SSL scanning. Check server logs for handshake failure details. Use openssl s_client -connect example.com:443 to see detailed handshake information.

ERR_CERTIFICATE_TRANSPARENCY_REQUIRED

The certificate lacks required Certificate Transparency proofs.

Certificate Transparency requires CAs to log all certificates they issue to public logs. Browsers verify certificates include Signed Certificate Timestamps (SCTs) proving this logging occurred. This error means SCTs are missing, there aren't enough SCTs from independent logs, or SCTs are from distrusted logs.

All major CAs automatically handle CT logging. If you're seeing this error, you're likely using an unusual certificate source. Switch to a mainstream CA like Let's Encrypt or any major commercial CA.

ERR_CERT_SYMANTEC_LEGACY

Certificates from Symantec (and related CAs like GeoTrust, Thawte, and RapidSSL) issued before the distrust deadline are no longer accepted.

Symantec's CA business had significant security and compliance failures, leading browsers to distrust their certificates. DigiCert acquired Symantec's CA business and issues trusted certificates, but old Symantec-issued certificates remain distrusted.

Replace with new certificates from DigiCert or any other trusted CA. This error is becoming rare as old certificates expire naturally.

Mixed Content Warnings

Not strictly a certificate error, but commonly encountered during HTTPS deployment. This occurs when an HTTPS page loads resources (scripts, images, stylesheets) over HTTP.

Update all resource URLs to HTTPS. Use protocol-relative URLs (//example.com/resource) or relative paths for same-domain resources. Add Content-Security-Policy: upgrade-insecure-requests to automatically upgrade HTTP requests. Check the browser console for specific mixed content warnings.

Mixed content undermines HTTPS security. Even with a valid certificate, loading scripts over HTTP allows attackers to modify those scripts.

Troubleshooting Systematically

When facing an SSL/TLS error:

Identify the exact error. Different browsers word errors differently, but the underlying cause is the same. Note the specific error code.

View the certificate. Click the lock icon (or warning) in your browser to see certificate details. Check validity dates, issuer, and covered domains.

Test with SSL Labs. Run your domain through ssllabs.com/ssltest for comprehensive analysis of your certificate, chain, and server configuration.

Test from multiple locations. Try different browsers, different networks, and different devices. If the error only appears in specific conditions, that narrows the cause.

Check your server logs. Web server error logs often contain details about handshake failures that browsers don't display.

Fix one thing at a time. Make a single change, test, confirm it worked, then move on. Document what you changed.