Connecting Ivercy to Azure DevOps Services with TLS 1.2

On January 31st, 2022, Microsoft disabled the encryption protocols TLS 1.0 and 1.1 on the Azure DevOps platform. Only TLS 1.2 is currently supported for connections to Azure DevOps.

Visual Studio 2013 and the TFS MSSCCI-Provider by default do not use TLS 1.2 and connecting are to Azure DevOps will fail with the error:

TF400324: Team Foundation services are not available from server dev.azure.com/YourOrgName.
Technical information (for administrator):
 The underlying connection was closed: An unexpected error occurred on a send.

The same error will happen if you use YourOrgName.visualstudio.com to connect to Azure DevOps.

Microsoft recommends upgrading to the most recent version of Visual Studio 2022 to solve the issue.

Unfortunately, to use the Microsoft TFS MSSCCI-Provider you must use Visual Studio 2013. Later versions of Visual Studio don't include the libraries and components required for the MSSCCI-Provider. – This is very inconvenient, but this decision is Microsoft's not ours.

Configuring the .NET 4.x Framework to use the default TLS version of the operating system

We were able to fix the issue on our test systems using .NET 4.0 by adding the following key to the Windows registry. With these registry changes, we can successfully connect to Azure DevOps with Access/Ivercy using the Microsoft Team Foundation Server MSSCCI-Provider and also directly with Visual Studio 2013.

(These recommendations are based on Microsoft’s information in Enable support for TLS 1.2 in your environment for Azure AD TLS 1.1 and 1.0 deprecation.)

For Access 64bit on 64-bit operating systems

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001 "SchUseStrongCrypto"=dword:00000001

For Access 32bit on 64-bit operating systems

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001 "SchUseStrongCrypto"=dword:00000001

Here is a screenshot as an example for 32bit Access on 64bit Windows:

For Access 32bit on 32-bit operating systems

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001 "SchUseStrongCrypto"=dword:00000001

Configuring the .NET 2.0 and 3.5 Framework to use the default TLS version of the operating system

We’ve currently got no testing environment available to verify, but the above fix should in principle also work if you are still using the .NET Framework 2.0. To use this fix for .NET 2.0 you must replace the version number in the above-mentioned registry paths with v2.0.50727. – This also applies to .NET 3.5, which is only an extension to .Net 2.0.

Adding the registry settings should be enough in most cases. If you haven’t updated your .NET 2.0/3.5 installation in a very, very long time,  you might also need to download and install the update described here: Support for TLS System Default Versions included in the .NET Framework 3.5

Enabling TLS 1.2 on Windows 7

The above fix depends on TLS 1.2 being enabled as default TLS version for your computer in the Windows registry. This should be the case for all computers running Windows 8 and newer.

If you are still running Windows 7, you might need to adjust some additional registry settings to enable TLS 1.2 by default. See Update to enable TLS 1.1 and TLS 1.2 as default secure protocols in WinHTTP in Windows for details.