fixed in version 5.4.1applies to the use or non-use of TLS v1.0 with the RMS component.

Never gave it much thought - the investigating I did after reading your post suggests that the (presumably deprecated) SQLOLEDB provider can't connect when TLS v1.0 (and lower protocols) is disabled. Wonder how deprecated deprecated is.

I'm trying to get this working as well and I reached out to one of the Sophos engineer's and it seems that in order for this to work, the Sophos Management Service (MgntSvc.exe) must be setup to use a different SQL Provider in order to use TLS 1.1 or 1.2.

Verified database can be reached using TLS 1.2 and SQL Native Client with UDL file

All services start EXCEPT the Sophos Management Service

Is MgntSvc.exe built on .net 4 or .net 4.5? From my research, I’ve gathered that .net 4 applications will not use TLS 1.2 unless the following code is at the beginning of the application:ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

And then the following REG Key set: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319: SchUseStrongCrypto to DWORD 1

SQL Version is the 2012 version which SEC 5.5 installs. I then updated it with the latest services packs and updates required for TLS 1.2. The SQL instance is not the problem because the SQL Native Client has no issues connecting to the database. Changing the TCP and Named Pipes did not make any difference. I currently have everything enabled. I also tried changing the string to the server name instead of local because that's how the UDL sets it but still nothing.

If I enable TLS 1.0 and then change the Provider back to Microsoft OLE DB then the servive starts without any problems.

It also doesn't matter if I leave TLS 1.0 enabled and try starting MgntSvc.exe using the SQL Native Client Provider, it still results in the same .net run time error.

My best guess is that MgntSvc.exe has only been officially tested by Sophos using the Microsoft OLE DB Provider and does not work if you attempt to change the provider. If we can get MgntSvc.exe to load using the SQL Server Native Client Provider, then TLS 1.0 can be disabled.

has only been officially testedit's not a question of tested. One might expect that databases would be fully abstracted (as far as this is possible) by a framework like .NET. They aren't - won't go into details here but each provider has its own namespace. If the application isn't written to work with different providers just specifying a different provide in the ConnectionString won't make it use this provider, instead - as you've seen - an error will be thrown.

has only been officially testedit's not a question of tested. One might expect that databases would be fully abstracted (as far as this is possible) by a framework like .NET. They aren't - won't go into details here but each provider has its own namespace. If the application isn't written to work with different providers just specifying a different provide in the ConnectionString won't make it use this provider, instead - as you've seen - an error will be thrown.

Christian

Thanks Christian. Then I think in conclusion, it's safe to say that SEC, or at least the management services, are not not capable of using another provider and therefore, cannot work with TLS 1.0 disabled.

It sounds like we'd need the Sophos developers to actually re-code or update the code of the Sophos Management Service to support a TLS 1.2 compatible provider. Until then, not possible.

thanks for the information. When first published the article stated SEC 5.6.0 instead of future release. Can't say what this signifies - that'd take some time so it might not come with 5.6.0 (whatever this one will include), that it's not decided whether it'll be numbered 5.6 or 6.0, or that it might even be brought forward to (the already WIP) 5.5.1.