The checkbox works instantly, which is exactly why it deserves one honest page. Trust server certificate keeps the encryption and drops the identity check. Whether that trade is fine depends entirely on where the connection travels and what the data is worth. This guide grades it without fear and without sales talk.
Every SQL admin meets this switch, usually during an outage, usually in a hurry. The honest rule is simple: the checkbox is a bridge, not a destination. Use it knowingly on networks you control, refuse it on paths you do not, and learn the middle option - trusting your own server's certificate directly - which keeps full validation switched on.
When checked, the client encrypts the connection but does not verify that the certificate was issued by a trusted authority, or that it belongs to this server.
TrustServerCertificate=True (the connection-string spelling) and the SSMS checkbox do one precise thing: the login channel is still encrypted, but the client skips validating the certificate - no check of who signed it, and no check that the name inside it matches the server you dialled. Encryption without identity. A locked door, with no check of who is standing behind it.
In these cases the practical risk is low, because an attacker would first need a position inside your network - at which point this checkbox is the least of the problems.
Between skipping the check and buying certificates there is a documented middle path: trust this one server's certificate directly. Export the certificate SQL Server is using (or the certificate of your internal CA) and install it into the Trusted Root Certification Authorities store on the client PCs. The client then validates the chain like any other - encryption stays strict and the checkbox stays unticked - it simply trusts your authority instead of a public one. Group Policy can push that trust to a whole office. If you later install a properly signed certificate, remove the workaround and nothing about the setup is second-class.
The video uses this very checkbox to clear the error in one click. Watch it, then use this page to decide how long that setting should stay in place.
▶️ Watch Full VideoYes. The data, including the login, travels inside an encrypted channel. What is missing is proof that the far end is really your server and not an impostor presenting any certificate at all.
No panic, but do plan the exit. The accepted end state is a real certificate on the server, or your internal CA trusted on the PCs. Both remove the need for the checkbox without touching the network.
Yes. Export that certificate and place it in the Trusted Root store on the clients, ideally through Group Policy. Validation then succeeds for your server only, which is far tighter than skipping validation for everything.