We have a requirement to create TLSv1.2-enabled SSL client connections from the snap-in. Using a freshly installed Windows 10.0.19042 (the current Hyper-V "quick create" Win10 dev image), the max TLS level of connections created by the snap-in is TLSv1.0. OTOH, a console or windows program assembly targeting .NETv4.7 running on the same machine (but not hosted by MMC) creates TLSv1.2 client requests perfectly.
We discovered two unsatisfactory ways to modify Windows which allow the snap-in to create TLSv1.2 connections:
By modifying MMC's application configuration file (`mmc.exe.config`), merging the following fragment:
<runtime> <AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols=false;Switch.System.Net.DontEnableSchUseStrongCrypto=false;Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false;Switch.UseLegacyAccessibilityFeatures.3=false"/> </runtime>(what's the deal with the MD previewer, I hope the post looks better!)
Since both options may induce unforeseen side effects in other programs, they are not generally viable. Why doesn't this "just work", especially given that we have followed all the known "best practices"?:
`SslStream` connection initiation methods do not specify the
The snap-in assembly targets .NET 4.7 as per documented guidance.
Useful code modifications have eluded us as well, such as explicitly specifying
SslProtocols.Tls12 (this fails with
This seems like a bug with the way
mmc.exe is hosting the CLR.
Is there really no way to do this programmatically and in-proc? Must we force users to perform Windows hacks? If so can we at least assure them that the SChannel client always negotiates down from TLSv1.2 to TLSv1.0 in the legacy cases, so their other programs are "probably OK"?