SSL Errors: What They Are and How to Fix Them

An SSL error is what a browser shows when it cannot open a trusted encrypted connection to a website. Instead of the page you asked for, you get a warning screen and a short code in small capitals, something like NET::ERR_CERT_AUTHORITY_INVALID or SSL_ERROR_NO_CYPHER_OVERLAP.

That code is the useful part, and most guides skip past it. “SSL error” is not a technical term, and no standard defines one. It is the everyday name for a whole family of different failures, which is why generic advice like clearing your cache fixes some of them and does nothing at all for the rest.

What an SSL Error Actually Is

When you load an address starting with https://, your browser and the server run a short negotiation called a TLS handshake before any page content moves. The handshake agrees on a protocol version and a set of encryption algorithms, and the server proves its identity with a certificate. If any part of that fails, the browser refuses to continue and shows you an error rather than the page.

SSL and TLS are worth separating here, because the naming causes real confusion. SSL is the original protocol, and every version of it has been deprecated for years. What your browser actually speaks is TLS. The word “SSL” survives in product names, in configuration directives, and in error codes, which is why you still see it everywhere. When a page or a browser says SSL, it almost always means TLS.

This matters for troubleshooting because the popular definition of an SSL error is too narrow. You will often read that an SSL error means the browser could not verify the site’s certificate. That is true of one group of these errors and false of the rest. A server answering on the HTTPS port with plain unencrypted text produces an SSL error and never sends a certificate at all. Two machines that cannot agree on a cipher suite produce one before the certificate is looked at. Starting from the certificate when the certificate was never the problem is the most common reason people spend hours on a five-minute fix.

Which Stage of the Connection Failed

Every HTTPS connection runs through the same sequence, and an SSL error is simply the point at which that sequence stopped. Working out the stage narrows the cause immediately, because each stage has a completely different set of explanations.

1. The connection never became TLS. Your browser opened a connection and what came back was not TLS, or the other end closed the connection before the handshake finished. No certificate is involved, and no certificate needs replacing.
2. The handshake failed while negotiating. Both sides spoke TLS but could not agree on a protocol version, a cipher suite, or which site was being requested. The handshake stops before the certificate is validated, and often before it is even sent.
3. The certificate was received and rejected. This is the group people mean when they say “SSL error”. Expiry, hostname coverage, the chain of trust, revocation and signature strength all live here.
4. The handshake succeeded and something after it failed. The encrypted connection was established correctly, then a later layer broke. The certificate is confirmed good by this point, so replacing it changes nothing.

You do not need to guess which stage you are in. The error code tells you, and the next section maps every code to its stage.

Find Your Error

Read the code printed under the warning message. In Chrome and Edge it sits in small capitals beneath “Your connection is not private”. In Firefox you may need to open the advanced details on the warning page. Then find it below.

Stage 1: the connection never became TLS

• SSL_ERROR_RX_RECORD_TOO_LONG in Firefox means the server replied to an HTTPS request with something that is not TLS, almost always plain HTTP served on port 443. It is a server configuration problem.
• PR_END_OF_FILE_ERROR in Firefox means the other end closed the connection before the handshake completed. The cause is often between you and the server rather than on either end.

Stage 2: the handshake failed while negotiating

• ERR_SSL_PROTOCOL_ERROR is Chrome’s generic code for a handshake that failed for a reason it could not identify precisely. Start here if your code is this one, because the first job is narrowing it down.
• SSL_ERROR_NO_CYPHER_OVERLAP is Firefox’s equivalent, and equally broad: it appears for any fatal handshake failure the server reports, whatever the server’s real reason was.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH is the Chrome code for the same class of failure, raised for a short and specific list of negotiation conditions.
• ERR_SSL_UNRECOGNIZED_NAME_ALERT means the server ended the handshake on purpose because the hostname requested matches no site configured on it. No certificate is sent, so the certificate is not the fault.
• ERR_BAD_SSL_CLIENT_AUTH_CERT runs in the opposite direction to every other error here: the site asked your browser for a certificate and rejected the one it got, or got none. This one really is fixed on your machine.
• Cloudflare error 525 is a handshake failure on a different leg of the journey: between Cloudflare and the origin server behind it, not between your browser and Cloudflare. Visitors cannot act on it.

Stage 3: the certificate was received and rejected

Your connection is not private is Chrome’s warning screen for this whole group rather than a cause of its own, so if that is all you have, read the code underneath it first.

The chain of trust could not be built. The browser could not link the site’s certificate back to a root it trusts, usually because the server sends its own certificate and omits the intermediate above it.

• NET::ERR_CERT_AUTHORITY_INVALID in Chrome and Edge.
• SEC_ERROR_UNKNOWN_ISSUER in Firefox, the same condition under a different name.
• An expired intermediate certificate, where the chain exists but one link above you has run out.
• MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT, where there is no chain because the certificate signed itself.

The dates or the name do not match. The certificate is trusted but does not apply to this moment or this hostname.

• NET::ERR_CERT_DATE_INVALID, where the certificate has expired or is not valid yet. Worth knowing that a wrong clock on your own device produces this too.
• NET::ERR_CERT_COMMON_NAME_INVALID, where the hostname is not listed in the certificate.
• DLG_FLAGS_SEC_CERT_CN_INVALID, the same hostname problem reported by software built on the older Windows web stack, mainly Internet Explorer mode in Edge and line-of-business applications.

The certificate is trusted and current but disallowed for another reason.

• NET::ERR_CERT_REVOKED, where the Certificate Authority cancelled it before its expiry date.
• NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED, where the certificate did not arrive with enough public proof of issuance.
• NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM, where something in the chain is signed with SHA-1. Current Chrome may report the same certificate under a different code, but the condition and the fix are unchanged.
• SEC_ERROR_REUSED_ISSUER_AND_SERIAL, a collision inside Firefox’s own certificate store rather than a fault in the connection.
• NET::ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN, which applies to a very small set of domains built into the browser, so an ordinary website cannot produce it.

The certificate file itself is wrong. These two are found on the server rather than in a browser, and they usually stop a site from serving HTTPS at all.

• ERR_SSL_SERVER_CERT_BAD_FORMAT, where the browser could not decode the certificate the server sent.
• A modulus mismatch, where the installed certificate does not belong to the installed private key.

Stage 4: the handshake succeeded and something after it failed

These are filed under SSL errors by habit. In each case the encrypted connection was already working, so the certificate has been validated successfully and reissuing it will not help.

• ERR_SSL_BAD_RECORD_MAC_ALERT means the server received encrypted data it could not verify, which happens after the handshake under the session keys. Something in the path is corrupting or rewriting traffic.
• ERR_QUIC_PROTOCOL_ERROR is a failure of QUIC, the transport underneath HTTP/3. It is not a certificate problem, and the usual cause is a firewall or VPN filtering UDP.
• ERR_SPDY_PROTOCOL_ERROR is a failure at the HTTP/2 layer, which sits above a completed TLS handshake.
• Mixed content is the odd one out: the page loaded over HTTPS perfectly well, then asked for a resource over plain HTTP. It produces no error page at all, just a downgraded padlock and missing scripts or images.

Errors named after a device rather than a stage

Two platforms produce enough of their own quirks to be worth treating separately, because the same underlying condition behaves differently on them.

• SSL errors on iPhone and iPad, including the message “An SSL error has occurred and a secure connection to the server cannot be made”. The date and time setting is the first thing to check.
• SSL connection errors on Android, where Chrome and other apps consult different trust stores, and a missing intermediate certificate causes more trouble than it does on a desktop.

Codes that no longer appear

Three codes are still widely written up but have been removed from the browsers that produced them, so if you are reading advice about one of them, check the date on it. The conditions behind two of them still exist under other names.

• NET::ERR_CERT_SYMANTEC_LEGACY was deleted in Chrome 136, released in April 2025.
• ERR_SSL_VERSION_INTERFERENCE was removed in Chrome 76 in 2019, though the interference it described still happens and now surfaces differently.
• ERR_SPDY_PROTOCOL_ERROR was renamed to ERR_HTTP2_PROTOCOL_ERROR in Chrome 77, also in 2019. The failure it describes is still current, which is why it is listed under stage four above.

If You Are Visiting the Site

Most SSL errors are the website’s to fix, and no amount of work on your own device will change them. There is a short list of genuine exceptions, and it is worth going through it before concluding the site is broken.

• Check your clock. Certificate validation compares the certificate’s dates against your device’s own time. A clock that is wrong by months or years makes every certificate look invalid, and this is the single most common visitor-side cause.
• Try a second network. Switching from Wi-Fi to mobile data, or the reverse, tells you in seconds whether something on the network is intercepting traffic. Public and hotel Wi-Fi are frequent offenders.
• Turn off HTTPS scanning temporarily. Antivirus products and corporate proxies inspect encrypted traffic by substituting their own certificates. When they do it badly, you get an SSL error on sites that work fine elsewhere.
• Try a private window and another browser. If the error appears in one browser and not another, the cause is usually local, in an extension or in stored data. If it appears in all of them, it is the site.

If none of that helps, the problem is on the server and the honest answer is that you cannot fix it. That applies completely to Cloudflare error 525, where the failure happens on a connection your browser is not part of.

Browsers do offer a way to continue past most certificate warnings, and it is worth being clear about what that costs. Proceeding tells the browser to accept a connection whose identity it could not verify, which means you have no assurance you are talking to the site you typed rather than to something in between. That is an acceptable trade on a test server you control. It is not acceptable on anything where you will enter a password or a payment detail. Some errors offer no way past at all, and that is deliberate rather than a fault.

If You Run the Website

Diagnose before you change anything. Reinstalling a certificate that was never the problem is the usual way an hour becomes an afternoon.

Start with an external check

Run the domain through our SSL Checker. It reports what the server is actually sending to the outside world, which is frequently not what is sitting in the configuration file. A chain that looks complete on disk but arrives incomplete at the browser is the most common finding, and it is the cause behind both NET::ERR_CERT_AUTHORITY_INVALID and SEC_ERROR_UNKNOWN_ISSUER.

You can see the same thing from the command line. This prints every certificate the server offers, in the order it offers them:

openssl s_client -connect example.com:443 -servername example.com -showcerts

Read the certificate list in that output, not the Verify return code line at the bottom. That line is far less informative than it looks: it reports only OpenSSL’s verdict on the chain, it ignores the hostname unless you ask for the check explicitly, and it prints 0 (ok) even when the server sent no certificate at all because the handshake was aborted. If the output says no peer certificate available rather than showing a subject= line, nothing was verified and the failure happened earlier.

Check the dates and the hostname

These two account for a large share of certificate rejections. To read the validity window of the certificate the server is serving:

openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates -subject

Browsers match the hostname against the subjectAltName extension and ignore the Common Name entirely, so that is the field to inspect on a local certificate file:

openssl x509 -noout -text -in certificate.crt | grep -A1 "Subject Alternative Name"

To make OpenSSL apply the hostname check that a browser applies, add the flag rather than assuming a clean result covers it:

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com

On macOS these commands need attention. The openssl that ships with macOS is LibreSSL, and it rejects -verify_hostname outright and reports a healthy result on some genuinely broken chains. Install OpenSSL through Homebrew, then run openssl version again to confirm which binary you are actually calling. If it still reports LibreSSL, your PATH is finding the system copy first, so call /opt/homebrew/bin/openssl by its full path.

Then fix and verify

What to change follows from the stage, and the individual guides linked above carry the platform-specific steps. Three fixes cover most cases:

• Serve the full chain. Concatenate your certificate and the intermediate certificates your Certificate Authority supplied into the file your server points at. Do not put the private key in that file.
• Renew before expiry, and automate it. Certificate lifetimes are shrinking, so anything renewed by hand will eventually be renewed late. ACME automation removes the deadline.
• Cover every hostname you actually serve. A certificate for a domain does not cover its subdomains unless it is a wildcard or lists them.

Always test the configuration before reloading the service, and re-run the checker afterwards from outside your own network. A fix confirmed only in the browser you have been testing in is not confirmed, because that browser may be holding a cached result.

How to Prevent SSL Errors

Almost every SSL error on a working website comes from one of three things: a certificate that expired, a chain that was never complete, or a configuration that drifted. All three are preventable.

• Automate renewal. Maximum certificate lifetimes are being reduced in stages over the next few years, and manual renewal stops being practical well before the end of that. Automate now rather than when it breaks.
• Monitor expiry independently. A calendar reminder fails when the person leaves. An external check that alerts you weeks ahead does not.
• Re-check after every change. Server migrations, CDN changes and control-panel updates all quietly rewrite certificate configuration. Verify from outside afterwards.
• Test on a phone, not only on a desktop. Mobile platforms are stricter about incomplete chains, so a chain problem often shows on a phone while the desktop looks fine.
• Install correctly the first time. Our installation tutorials cover the chain and binding steps per platform, and most chain errors originate at install time.

Frequently Asked Questions