I want to check that my RDP sessions to a windows server 2012 use SSL/TLS 1.0. I found hints about using tools for Windows 2008 that do not exist anymore on Windows Server 2012 and above.

So my question is: how can I be sure (Log--Entries, Session-Monitoring...) that my RDP connection is properly encrypted with TLS 1.x?

Some information: - No server role for remote sessions installed, just RDP for administrative purposes under "System properties" -> "Remote" (NLA required). - In Local Computer Policy Manager I have set the client connection encryption level to "High Level", Require use of specific security layer for RDP connections to "SSL (TLS 1.0)" and Require user authentication for remote connection by using NLA to enabled. - no specific key or certificate created nor installed (I did not manage to find understandable guides on this)

I would like to be sure that encryption actually is used. Thanks a lot! Aurel


You've got to trace it and this can be done in Windows.

C:\Windows\System32> netsh trace start capture = yes ipv4.address = <IP>
  Trace File: <filepath>\NetTrace.etl
C:\Windows\System32> mstsc -v <IP>
C:\Windows\System32> netsh trace stop
  Tracing session was successfully stopped.

Open the saved NetTrace.etl file Microsoft Message Analyzer and look for the Client Handshake

enter image description here

  • What a great answer, thank you very much! I had a moment to figure out why it did not work on my system. I then realized that I need to connect without a VPN tunnel (when working at home I need a VPN tunnel to get to the office and from there I can access the servers). But when I started the RDP connection from a computer at the office, everything worked like a charm! Now my sleep will be better at night, thanks a lot! – Aurelius Baier Nov 15 '17 at 8:56
  • Great answer, however if I try to run the above netsh command on an elevated cmd I get access denied, anything special I need to do? – EricSP May 1 '18 at 19:09
  • Not on a vanilla installation. Netsh is a network shell capable of editing the firewall, ipsec, and adapters so it may be restricted. Check the ACL on the executable. – spacenomyous May 3 '18 at 1:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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