SSL Handshake Failure

The failure is mutual rather than one-sided: two pieces of software could not agree on a protocol version and cipher suite they both accept, so the connection closes before AUTHINFO or any other command is exchanged. No credentials leave the machine, no article is requested, and no state changes on the server. This is a software compatibility problem, and in the large majority of cases the outdated half is the client.

How the failure presents in a log

The TCP connection succeeds and then closes within about a second, and the log records something about a protocol version, a cipher, or an unexpected message, rather than a news response code. Because a socket opened at all, the hostname resolved and the port is reachable, which eliminates refusal, blocking and resolution failure in one stroke. A log containing a number such as 502 describes a handshake that actually completed, and points somewhere else entirely.

Deprecated protocol versions are the usual answer

Servers have spent years retiring older TLS versions and the cipher suites that accompany them. A newsreader that has not been updated in a long time may offer only what has since been disabled, and the result is exactly this error, appearing abruptly on a configuration that ran unchanged for years. Updating the newsreader is the fix. Clients that link against the operating system's TLS library rather than shipping their own inherit the version floor from the OS, which is why an old but maintained client on a current system often works while the same client on an unpatched machine does not.

Three causes unrelated to the client's age

SSL enabled against port 119 produces a handshake failure because the server there is waiting to speak plaintext NNTP and sends a greeting the client cannot read as a TLS record. A system clock wrong by weeks or years puts the certificate outside its validity window and fails validation during the handshake, which is worth checking on any machine restored from an image or with a dead battery. And on a filtered or corporate network, an interception appliance may terminate TLS itself; where it supports a narrower set of ciphers than the real server, the handshake breaks against a device the reader may not know is in the path.

Checks in order of likelihood

1. Confirm the pairing: port 563 with SSL on, or 119 with SSL off. Mixed settings account for a large share of reports.
2. Check the system date, time and time zone.
3. Update the newsreader to a current release, then the operating system where the client relies on system libraries.
4. Test from another network. Success on a phone hotspot with failure on an office or campus link identifies interception on the latter.

Why this is almost never the provider

A server-side misconfiguration in TLS breaks every customer using that client family simultaneously and is corrected quickly, because it is impossible to miss. The far more common history is a client that stopped being updated while the rest of the internet moved on. A reader whose second, newer newsreader connects to the same server on the same machine has already proved the server is fine.