title: How to configure encrypted SQL Server connections to prevent MITM attacks?
body: <p>It has come to my surprise that SQL Server by default does nothing to prevent man-in-the-middle attacks when configuring your SQL Server to enforce connection encryption.</p>
  
  <p>Forcing encryption on your connections is dead-simple. You go to Sql Server Configuration Manager, expand SQL Server Network Configuration, Protocols for [your instance], right-click TCP/IP, change Force Encryption to 'Yes', restart SQL Server and you're done.
  <a href="https://i.stack.imgur.com/C5aDn.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/C5aDn.png" alt="Force Encryption set to Yes"></a></p>
  
  <p>Per Microsoft TechNet (<a href="https://technet.microsoft.com/en-us/library/ms189067(v=sql.105).aspx" rel="nofollow noreferrer">https://technet.microsoft.com/en-us/library/ms189067(v=sql.105).aspx</a>), this will generate a Self-Signed Certificate. Fine, no problem, <strong>But I expect my clients to complain that the certificate is not trusted.</strong>  However, they do not. They happily connect to it. I then realize that 'Trust server certificate' <strong>is checked by default in SQL Management Studio</strong>. Fine, but the most shocking realization is: <strong>even if you uncheck "Trust server certificate", SSMS does not complain, warn, or reject the connection.</strong></p>
  
  <p><a href="https://i.stack.imgur.com/yDNqg.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/yDNqg.png" alt="Trust server certificate is unchecked"></a></p>
  
  <p>So by default SQL Server is completely susceptible to MITM attacks because clients do nothing to verify the certificate from SQL Server. The certificate shouldn't have to be signed by a CA: the certificate should have to be configured as a trusted certificate on the client. If that's not true, what is the "Trust server certificate" checkbox for?</p>