After the SQL Server Certificate Fix How to Verify Encryption and Production Rules
Clearing the error is the halfway point. Two very different setups both produce a successful login: properly verified encryption, and encryption quietly abandoned. This guide gives the three tests that tell them apart, and the short set of production rules that stop the error from returning at the next update or the next certificate expiry.
✍️ Technical Anshu🔐 SQL Server • Verification
🎥 Watch the error being cleared in the video, then verify with this page
Professionals verify; they do not assume. After any route through this error - checkbox, connection string or server certificate - run the same closing routine: prove encryption is on, prove validation is on, prove the server loaded the certificate. Then write down what you did, because the certificate's expiry date is already counting down.
SQL Server query window - the verification
SELECT session_id, encrypt_option, auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;
encrypt_option
---------------
TRUE
The one result that proves the fix instead of suggesting it. Run it in the same session you just repaired.
1
Test One - Encryption Is Actually On
A login that succeeds quietly proves less than people think, because several settings combinations connect without encryption. Ask the server. In the repaired session, run the query above against sys.dm_exec_connections. encrypt_option TRUE is the only passing grade. FALSE with a working login means the connection succeeded by dropping protection, and the job is not done.
2
Test Two - Validation Is Actually On
Now prove the identity check works, by removing the training wheels:
In SSMS, set encryption to Mandatory and untick Trust server certificate, then reconnect
In an app, set Encrypt=True;TrustServerCertificate=False and restart it
Both must connect cleanly. If either falls back to needing the trust switch, the server certificate still is not right - its issuer is not trusted by this client, its name does not match, or it was never loaded
3
Test Three - the Server Loaded the Certificate
On the server, the error log from the last service start should record the certificate being successfully loaded for encryption. No such line, or a load failure, means clients are still meeting the old self-signed certificate no matter what the configuration screens suggest. Fix the private key permission first - it is the usual culprit.
4
The Production Rules That Keep It Fixed
Real certificate, renewed on a calendar. An expired certificate recreates this entire incident on a random morning. Diary the expiry date the day you install it
ForceEncryption on. With a valid certificate in place, requiring encryption server-side stops any client from quietly negotiating down
No trust bypass in shipped strings. Search your code and config files for TrustServerCertificate=True in production branches; treat every hit as a defect with an owner and a date
Internal CA trust deployed by policy. If you run your own CA, its root belongs on every client via Group Policy, so validation passes by design rather than by exception
A note in the runbook. One paragraph - where the certificate lives, when it expires, who renews it - saves the next admin the archaeology you just did
🔴 The compliance line, plainly: on a production system, a connection that works because validation was switched off is a finding in any audit, not a fix. Encrypt with validation, or document a temporary exception with an owner and an end date - there is no third honest option.
🎥 Watch the One Click Fix in the Video
The video clears the error the fast way. Use this page straight after it to confirm the connection you restored is genuinely the secure one.
encrypt_option says FALSE but the app works. What happened?
The connection negotiated down to no encryption - typically a client set to optional encryption meeting a server that does not require it. Set ForceEncryption on the server and Encrypt=True on the client, then test again.
How often should the certificate be checked?
Put its expiry date in the team calendar with a reminder a month ahead. The check itself takes a minute in certlm.msc; the outage an expired certificate causes takes considerably longer.
We fixed it months ago and the error returned after a server restart. Why?
A restart is when SQL Server reloads its certificate. If the configured certificate's private key became unreadable, or the certificate was replaced or expired, the server falls back to its self-signed one and strict clients fail again. Start with the error log's certificate line.
This guide is based on the Technical Anshu SQL Server fix video • Stuck on a step? Ask in the video comments — you will get a reply 🙏