Using Ivercy with Sourcegear Vault MSSCCI-Provider and TLS 1.2
In general, using Ivercy with Sourcegear Vault has been a straight and simple affair for many years. It usually worked right out of the box without any special configuration needs except for the registry settings for the MSSCCI-Provider.
In recent month however, we received some new support requests. One of them is related to the TLS encryption for the connection between the Access/Ivercy and the Sourcegear Vault repository.
Using the Sourcegear Vault MSSCCI-Provider with TLS 1.2
Due to increased sophistication of security threats, the once reasonable encryption protocols SSL 3.0 and TLS 1.0. are no longer considered secure enough for sensitive data. Instead the newer TLS 1.2 protocol version is recommended as the new minimum version for secure HTTPS connections. Many organizations are required to use it due to compliance requirements.
The Problem with TLS encryption
In general, that is not a big deal as most network clients support TLS 1.2 for some time now. The Sourcegear Vault MSSCCI-Provider however was built against the Microsoft .Net Framework 2.0. When .Net 2.0 was released, the TLS 1.1 and TLS 1.2 protocols did not exist yet. Thus, the Vault MSSCCI-Provider cannot connect to Vault servers, which enforce the use of TLS version 1.1 or newer.
The Symptoms
If you know for sure your server is enforcing TLS 1.1 or TLS 1.2, you can skip further diagnosis, and scroll down to the solution right away. Otherwise check if these symptoms match your situation.
You cannot connect to your Vault server using the MSSCCI-Provider with Ivercy and see error messages like this:
Or you check the MSSCCI-Provider log file (Default: %TEMP%\VaultIDEClient.txt) and find error messages like these (excerpts):
8/12/2020 2:24:10 PM <generic>: [<No Name>:1] [System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.
at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)
[…]
at VaultClientNetLib.VaultConnection.Login(String strURLBase, String strUserLogin, String strPassword)] The request was aborted: Could not create SSL/TLS secure channel.
02.09.2020 17:31:06 <generic>: [System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
[…]
at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
at System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size)
at System.Net.ConnectStream.WriteHeaders(Boolean async)] Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
These error message appear to differ somewhat depending on the version of .Net Framework you run the code in, the operating system or possibly the version of Sourcegear Vault. The common denominator with all incarnations of the problem is that you can connect to the Vault server using the Vault GUI Client, but you cannot connect using the MSSCCI-Provider with identical connection settings.
Solution for TLS 1.1 and TLS 1.2 MSSCCI Connections to Vault
Sourcegear is planning an improved version of the Vault MSSCCI-Provider for the future Vault 11 release. However, as of August 2020 there is no release date announced yet.
Sourcegear support claims there is no other solution to the problem other than waiting for the new release because of the dependency of the MSSCCI-Provider on the .Net 2.0 Framework.
Luckily, this is incorrect. Microsoft meanwhile released updates to the .Net Framework 2.0 and 3.5.1 that allow these to use TLS 1.1. or 1.2 encryption. I do not provide links to the actual updates here because they are out-of-date for some time. If you regularly update your operating system including the .Net Framework you have these updates installed already.
The important part is that with these updates you can add a registry setting to tell the .Net 2.0/3.5 Framework to use the default TLS protocol version from your Microsoft Windows configuration, even if that protocol version did not exist at the time the .Net Fx was originally released.
Add the following entries to the Windows Registry:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001The first entry is relevant for Windows 32bit installations and for 64bit Access on 64bit Windows. The second entry is relevant for 32bit Access on 64bit Windows.
You need to restart Microsoft Access but not Windows for these changed settings to take effect. After that, you will be able to connect to a Vault server enforcing TLS 1.1 or 1.2 with Ivercy and the Vault MSSCCI-Provider.