Some SQL Server login failures survive the certificate fix because the real fault is a disagreement: the server demands one thing, the client offers another. This guide maps the three mismatches admins actually meet, including the pre-login handshake error that looks like the certificate error but is not.
When a connection fails, ask two questions before changing anything: what does the server require, and what is this client willing to do? ForceEncryption, the selected certificate, the client's Encrypt flag and its TLS support form one negotiation. Read the failure's stage, find the disagreeing pair, and fix the outdated side - almost never the stricter one.
A connection was successfully established with the server, but then an error occurred during the pre-login handshake.
Encryption in SQL Server is negotiated between two independent switches. On the server, ForceEncryption (in SQL Server Configuration Manager) says whether encrypted logins are demanded. On each client, the Encrypt setting says whether this connection will encrypt, and the trust setting says how strictly the certificate is checked. The login works only when the pair agrees. Every mismatch produces its own flavour of failure, which is why one error message never tells the whole story.
ForceEncryption is Yes, but the server has only its self-signed certificate. Modern clients connect, are told encryption is required, inspect the certificate, and refuse it - the certificate chain error from the main guide. Nothing is inconsistent in the settings themselves; the server is demanding a standard its own certificate cannot meet. The cure is on the server: install a real certificate, as the companion guide shows.
An older application with encryption hard-coded off, or a connection string with Encrypt=False, meets a server that requires encryption. The server ends the conversation during setup. The honest fix is to update the client or its string - not to switch ForceEncryption off for the whole server to please one old program. If that program is business-critical and cannot change, isolate the compromise consciously: a separate instance for it, on the LAN only, documented as an exception with an expiry date.
When a server is hardened to modern TLS versions only, very old clients may fail even earlier, during the pre-login handshake, before certificates are discussed. The dialog above is that failure. It looks like the certificate error's twin but arrives a stage sooner. The cure is updating the client's driver or .NET components so it speaks a current TLS - weakening the server's TLS for one old client exposes every other connection on it.
For the plain certificate error the one click fix in the video is enough. Watch it first; if the failure survives, this page's alignment check is your next step.
▶️ Watch Full VideoRead the stage named in the message. Pre-login handshake means the two sides failed before or during protocol setup, usually a TLS version gap. During the login process with a sentence about the certificate chain means trust failed after the channel was offered.
That app is the outdated side. Update its driver or connection string if at all possible. If it truly cannot change, move it to its own instance as a documented exception instead of weakening the main server.
On production servers, yes, paired with a real certificate. It guarantees no client can quietly fall back to an unencrypted login. Without a valid certificate, though, it simply guarantees modern clients will fail.