However, SystemDefault might be a bit too lenient in it’s declared available protocols. Under normal circumstances, this would be the best option to use, as defaults change based on the current security landscape. NET return no default value, only an enumerated list), and allows your operating system to pick the protocol to best negotiate the connection with. On my Windows 10 system with Powershell v5.1, this returns a value of SystemDefault. The first thing we’ll want to do is figure out what the default security protocol for our system is, and what all versions are supported. Surely there’s a way to give both a minimum version and account for newer protocols once they become available. While explicitly declaring an enumerated protocol list is easy enough, what happens when Tls13 becomes more common, and we want to start utilizing it when it’s available? Then Tls14, and beyond? While TLS is negotiated at the highest level existing on both the server and the client, the minimum protocols defined by Powershell may include ones that you explicitly do not want. If you’ve ever attempted to make a secure connection (for example, an API request) to a service with certain net security requirements, you might have run into this problem. This is a quick post to highlight the nuances of Powershell and protocol management in regard to TLS connections.

Test tls 1.2 powershell