SQL Server says the connection was established and then fails during login with a certificate trust error. This is not a network problem and your data is not gone. It is a trust problem between the client and the server certificate, and it has one fast fix and one proper fix. Both are here, honestly graded.
Your app or SSMS connected yesterday and refuses today, or a fresh install has never connected at all. The error text is long but its meaning is short: the client demanded an encrypted, identity-checked login, and the server's certificate could not pass the identity check. Work through the fixes in this order: understand the message, apply the one click client fix if your situation allows it, use the same switch in app connection strings, then finish the job properly on the server so nobody has to tick that box again.
A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 - The certificate chain was issued by an authority that is not trusted.)
Your network is fine and the server is running. The connection reached SQL Server, the server offered an encrypted channel, and your PC refused it because the certificate proving the server's identity is signed by nobody your PC trusts. By default SQL Server protects the login with a self-signed certificate it creates itself. A self-signed certificate encrypts the traffic, but it cannot prove the server is really your server, so strict clients reject it.
So the real problem is not connectivity. It is trust. Every honest fix is one of two things: make the client accept this particular server knowingly, or give the server a certificate that clients trust on their own. Both routes are in this guide, in the right order.
This is the quick 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.
Honest grading: traffic stays encrypted, but the identity check is skipped, so the client would also accept a fake server in between. On your own office LAN, for a server you control, this is the accepted day-to-day workaround. Over the internet or on a production server holding customer data, treat it as a temporary bridge only, and do Fix 4.
If an application fails instead of SSMS, the same switch lives in its connection string. The modern Microsoft driver spells it like this:
The permanent repair happens once, on the server, and then every client connects strictly with no checkbox and no warning:
One detail decides success: clients must connect by the name written in the certificate. Connecting by IP address to a certificate issued for a DNS name fails the same check, for a different reason.
Do not trust the absence of an error. Ask SQL Server itself. Run this while connected in SSMS:
Check this after every route above. The quick fix and the proper fix should both end at TRUE.
The video shows the one click route live - the exact checkbox, on the exact screen, in under a minute. Watch it once and the error will never scare you again.
▶️ Watch Full VideoNo. The login never completes, so nothing is checked and nothing is changed. Your password, database and data are untouched; only the secure channel setup failed.
Usually the client changed, not the server. SSMS 20 and newer drivers encrypt by default and validate the certificate strictly, where older versions connected quietly. A separate case guide on this page covers that change in detail.
No. The traffic is still encrypted. What you give up is the identity check - the client no longer proves the server is genuine. That is why it is a LAN workaround, not a production practice.