This means the connecting client and your server couldn't agree on any combination of TLS version and cipher suite — usually because your server has been hardened to only support modern options, and the client is old enough to only support legacy ones that have since been disabled.
The fix
If this is affecting a meaningful number of legitimate visitors, check whether your server's minimum supported TLS version is more restrictive than necessary for your actual audience. If it's an isolated old device or outdated tool, the more sustainable fix is usually updating that client rather than lowering your server's security baseline for everyone else.
What this error means about the negotiation between client and server
This error indicates the client and server couldn't agree on any mutually supported combination of protocol version and cipher suite — each side supports a set of options, but those sets don't overlap at all, preventing the handshake from completing regardless of either side's configuration being individually valid.
How to determine which side, client or server, needs to be updated
Testing the same server with a different, more current client (or testing your client against a different, known-modern server) helps isolate whether the incompatibility stems from an outdated server configuration or an outdated client — the fix always involves updating whichever side is running the more restrictive, outdated configuration.
What a specific real-world example of this mismatch looks like
A server hardened to only accept TLS 1.2 and 1.3 with modern cipher suites, connecting from a very old device still running TLS 1.0 with only legacy cipher support, is a textbook example — neither side is technically broken, they simply share no common ground for a secure connection.
How to check your own browser or system's currently supported protocols and ciphers
Most browsers expose their currently supported TLS versions and cipher suites through internal diagnostic pages (like chrome://net-internals in Chrome) — checking this directly shows you exactly what your specific client currently supports rather than needing to guess.
Why this specific error has become less common as legacy client support has diminished
As the population of genuinely legacy clients (very old browsers, ancient operating systems) has shrunk industry-wide, servers have felt increasingly comfortable dropping support for the oldest protocol versions and ciphers entirely, reducing the practical frequency of a complete negotiation failure like this one.
A final note on choosing a compatibility target deliberately
If you're a server administrator and this error is affecting a meaningful share of your legitimate visitors, checking your actual visitor analytics for browser and OS version distribution before hardening further helps you choose a genuinely appropriate compatibility level rather than guessing at what your specific audience actually needs.
What specific TLS versions and cipher suites are considered current best practice today
TLS 1.2 and 1.3, paired with modern AEAD cipher suites like AES-GCM or ChaCha20-Poly1305, represent the current recommended baseline — a server or client still limited to only TLS 1.0/1.1 or legacy, non-authenticated cipher modes is increasingly likely to encounter exactly this kind of mismatch against modern counterparts.
How to check which specific protocols and ciphers are actually available on your own system
Most operating systems and browsers expose diagnostic information about currently supported TLS versions through internal settings or developer tools — checking this directly tells you definitively what your own system supports, rather than needing to infer it indirectly from error messages alone.
A quick closing checklist
A quick closing checklist covers identifying which side is more restrictive, checking your actual audience's client capabilities before assuming a fix, and choosing a balanced compatibility tier like Mozilla's intermediate preset rather than either extreme.
What role server-side logging plays in diagnosing this from the administrator's perspective
Your web server's own error logs often record the specific client TLS capabilities that were rejected during a failed negotiation attempt, giving you concrete data about what your actual visitors' clients are requesting rather than needing to guess based on general assumptions.