I have a validation question regarding implementation of TLS 1.2.

What tools, scripts, processes, etc.. can be used to validate that TLS 1.2 is working when clients, webserver, and SQL Servers are communicating between each other?

Do I need to perform network packet sniffing, run traces, use process explorer? Is there a verbose option somewhere that can be turned on with logs reviewed?

Note: if it makes a difference, the SQL Servers involved run a variety of versions: 2008R2, 2012, and 2014.


1 Answer 1


First, see Aaron Bertrand's answer on TLS 1.2 with older SQL Server, and/or Aaron's SentryOne blog post.

If you're talking about the normal SQL Server connection encryption (SQL Server Configuration manager, Force Encrypt yes), with modern SQL Server, then there are two steps:

  • select encrypt_option, count(*) from sys.dm_exec_connections GROUP BY encrypt_option
    • If there are any FALSE results, you have unencrypted connections. Fix that.
    • If there are 100% TRUE or NULL results, continue.
  • With buy-in from and in coordination with your IT Security team, download Microsoft Message Analyzer, Microsoft's Windows packet sniffer, and watch some connections. You're looking for the ClientHello and ServerHello messages, within which you can see cipher suites offered and which one happened to be accepted.
    • It's a combination of registry and group policy changes to adjust that at the Windows OS level of your SQL Server installations.


Lots of it does NOT support TLS of ANY kind, much less TLS 1.2, either in the application, or, much more often, during one or more parts of the installation and/or upgrade process. The vendor will be clueless if you ask beforehand, and just as clueless watching it happen in front of them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.