Fix SQL Server Encryption Error - One Click Solution

Read the Error - It Is a Trust Problem, Not a Network Problem

Your network is fine and the server is running. The connection reached SQL Server, the server offered an encrypted channel for the login, and your PC refused it because the certificate proving the server's identity is signed by nobody your PC trusts. The full error SSMS shows is:

By default, SQL Server protects the login with a self-signed certificate it creates itself. A self-signed certificate does encrypt the traffic, but it cannot prove the server is really your server, so clients that demand verified encryption reject it. Every honest fix is one of two things: make the client accept this particular server knowingly (Steps 2 and 3), or give the server a certificate clients trust on their own (Step 4).

The Quick Client Fix in SSMS - Trust Server Certificate

This is the fast route shown in the video. It changes nothing on the server; it tells this one connection to accept the server's certificate without checking who signed it. In the SSMS Connect to Server window, click Options to open the extra tabs, go to the Connection Properties tab, set encryption to Mandatory (or leave it as offered), tick Trust server certificate, and click Connect. The login goes through straight away.

The Same Fix Inside an App Connection String

If an application fails instead of SSMS, the same switch lives in its connection string. Add the two settings explicitly - Encrypt=True turns the protected channel on, and TrustServerCertificate=True is the connection-string spelling of the SSMS checkbox:

Server=SQL01;Database=AppDB;User Id=appuser;Password=YourPassword;Encrypt=True;TrustServerCertificate=True;

Use your own server name, database and login in place of the example values. The trade-off is exactly the same as the checkbox in Step 2, with one extra danger: baked into a shipped application's configuration, the skipped check applies to every user, invisibly and permanently. Keep it in development and staging configurations, and in production treat it as borrowed time until the server certificate in Step 4 is in place.

The Proper Fix - Give the Server a Real Certificate

The permanent repair happens once, on the server, and afterwards every client connects strictly with no checkbox and no warning. First get a certificate for the server's full DNS name (for example sql01.company.local) from your internal certificate authority or a public CA, with Server Authentication usage. Import it, with its private key, into the Local Computer certificate store on the SQL Server machine. Then right-click the certificate, choose All Tasks → Manage Private Keys, and grant the SQL Server service account Read permission on the private key. Open SQL Server Configuration Manager, expand SQL Server Network Configuration, right-click Protocols for MSSQLSERVER, choose Properties, and select the certificate on the Certificate tab. On the Flags tab you can also set ForceEncryption to Yes so every client is required to encrypt. Restart the SQL Server service - the change does nothing until you do.

Verify the Fix the Strict Way

A login that succeeds quietly proves less than people think, because some setting combinations connect without real protection. Prove both halves. First, reconnect from a client the strict way: connect using the server's DNS name - the name inside the certificate - set encryption to Mandatory and leave Trust server certificate unticked. The login should succeed with no warning. Then, in that same session, ask the server whether the connection is actually encrypted by running this query in SSMS:

SELECT session_id, encrypt_option, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID;

encrypt_option showing TRUE is the passing grade. FALSE with a working login means the connection succeeded by dropping protection, and the job is not done. That passing test is the real finish line: any correctly configured client, including future SSMS versions, now connects with full validation and no special settings.