I had a similar issue with an Android app I was working on.
It turned out that I had to specifically turn off TLS 1.0, which then allowed newer version of TLS to be tried. I thought it was a stupid problem to have, but what I ended up doing worked, so I wasn't going to complain too hard.
This first article includes a lot of links to pages about auditing your code to see if a method you are using specifically locks you into TLS 1.0, as if you have accidentally hard coded it in.
If you're using a custom binding:
- Configure WCF to allow the OS to choose the best security protocol by
setting SslProtocols to use SslProtocols.None.
- Or configure the protocol used with the configuration path system.serviceModel/bindings/customBinding/binding/sslStreamSecurity:sslProtocols.
If you're not using a custom binding and you're setting your WCF binding using configuration, set the protocol used with the configuration path system.serviceModel/bindings/netTcpBinding/binding/security/transport:sslProtocols.
For .NET Framework 4.6 - 4.6.2 and not WCF
Set the DontEnableSystemDefaultTlsVersions AppContext switch to false. See Configuring security via AppContext switches.
For WCF using .NET Framework 4.6 - 4.6.2 using TCP transport security with Certificate Credentials
You must install the latest OS patches. See Security updates.
The WCF framework automatically chooses the highest protocol available up to TLS 1.2 unless you explicitly configure a protocol version. For more information, see the preceding section For WCF TCP transport using transport security with certificate credentials.
https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls
The above page links to the below link, which is specific to removing TLS 1.0 dependencies from your project in an effort to move to TLS 1.2+.
https://www.microsoft.com/en-us/download/details.aspx?id=55266
- Identify all instances of AcquireCredentialsHandle(). This helps reviewers get closer proximity to code blocks where TLS may be hardcoded.
- Review any instances of the SecPkgContext_SupportedProtocols and SecPkgContext_ConnectionInfo structures for hardcoded TLS.
- In native code, set any non-zero assignments of grbitEnabledProtocols to zero. This allows the operating system to use its default TLS version.
- Disable FIPS Mode if it is enabled due to the potential for conflict with settings required for explicitly disabling TLS 1.0/1.1 in this document. See Appendix B for more information.
- Update and recompile any applications using WinHTTP hosted on Server 2012 or older.
a. Applications must add code to support TLS 1.2 via WinHttpSetOption
- To cover all the bases, scan source code and online service configuration files for the patterns below corresponding to enumerated type values commonly used in TLS hardcoding:
a. SecurityProtocolType
b. SSLv2, SSLv23, SSLv3, TLS1, TLS 10, TLS11
c. WINHTTP_FLAG_SECURE_PROTOCOL_
d. SP_PROT_
e. NSStreamSocketSecurityLevel
f. PROTOCOL_SSL or PROTOCOL_TLS
That's the meat of the document, but there's more to it than that. I'd suggest checking it out and making sure you aren't accidentally making a mistake or you have legacy code that's preventing you from moving forward. This might be a bit of a rewrite, rather than just a setting, so good luck!