The best practices paper lists a few options, but my favourite one is the one that consists in simply updating the configuration file associated with the application executable, as it's easy to do and doesn't impact anything else on the machine.įor that, locate the configuration file associated to the executable of the application you want to add TLS 1.2 support to: it's always named. Thankfully, you can also force an existing application to use the system default TLS versions without having to re-compile it (assuming it doesn't explicitly set the SSL/TLS versions it prefers via ServicePointManager). Unfortunately, such an option requires re-compiling the application, which is not always feasible. NET 4.7 applications automatically default to whatever the operating system they run on offers and considers safe (which currently includes TLS 1.2 and will later include TLS 1.3). NET Framework 4.7: in this case, you'll have nothing else to do, as. One of the proposed solutions is to update your project to target.

To make migration a bit less painful, Microsoft published a 'transport security best practices' paper that list a few solutions that help avoid handshake errors related to the use of legacy TLS versions that are no longer considered safe.

NET Framework is not sufficient: it's the version used for compiling your project that actually matters when it comes to selecting the supported TLS versions during the TLS handshake. NET Framework, like 4.0 or 4.5 – experiencing connectivity issues with TLS 1.2 servers are becoming more and more common, specially since installing a more recent version of the. NET applications – compiled with an old version of the. As most servers are moving toward TLS 1.3 and removing TLS 1.0/1.1 support, examples of legacy.

Test tls 1.2 support in net framework