Closed bdanse closed 4 years ago
@bdanse Is .NET 3.5 installed on the machine you're testing from? I was only able to replicate your issue on a 2016 server that had both the .NET Framework 4.7+ and 3.5 features enabled
As documented, NET Framework 4.6.2 and later supports TLS 1.1 and TLS 1.2. Confirm the registry settings, but no additional changes are required..
While I could be missing it, when I look at the SChannelSettings Module, I'm not seeing any logic to take into account a server that has both a version of .NET higher than 4.6.2 as well as 3.5 installed.
If I'm understanding correctly, what this DSC resources should therefore be doing is adding the registry keys for .NET 3.5, even if it excludes the registry keys for .NET 4.6.2+
Assuming .NET 3.5 is enabled on the server you're referencing: if you manually add the registry keys for .NET 3.5 without the keys for .NET 4.6.2+, does the problem resolve?
@bdanse Did some testing myself and I am able to confirm the same behavior your are seeing. I agree that it would be best to remove the .Net check.
@aydeisen Good spot, currently if .Net 3.5 is installed next to .Net 4.6.2+ this code won't update the v3.5 settings. The above change will also fix this issue!
v1.2.1 has been released
Details of the scenario you tried and the problem that is occurring
Due to an error in retrieving a module from the powershell gallery I stumbled upon an issue with regards to the SchannelSettings code. For example:
And I am sure it is there. Checking Tls settings I found they where set to the default values.
Explicite setting of protocol to tls12 restored the working of Find-Module.
Checking HKLM:\SOFTWARE\Microsoft.NETFramework\v4.0.30319 I found that SchUseStrongCrypto was not set. Even though we use SChannelSettings resource.
So to verify this was the issue is had set the keys SystemDefaultTlsVersions and SchUseStrongCrypto a new session to verify these settings and Find-Module works correctly without setting TLS via the ServerPointManager.
Verbose logs showing the problem
The log states ".Net Framework 4.6 or higher used, TLS 1.2 state not applicable". This may be the case for .net apps. Though when SchUseStrongCrypto and SystemDefaultTlsVersions are not set Powershell seems to switch to default "Ssl3, Tls"
And since the WMF 5.1 document states it needs .NET Framework 4.5 my assumption is it uses the "older" mechanism.
Suggested solution to the issue
Maybe removing the if statement and alway testing these setting would solve the issue as SChannelSettings will always Test and Set the values accordingly.
The DSC configuration that is used to reproduce the issue (as detailed as possible)
See description
The operating system the target node is running
OsName : Microsoft Windows Server 2016 Datacenter OsOperatingSystemSKU : DatacenterServerEdition OsArchitecture : 64-bit WindowsBuildLabEx : 14393.3808.amd64fre.rs1_release.200707-2105 OsLanguage : en-US OsMuiLanguages : {en-US}
Version of Windows that is used (e.g. Windows Server 2016)
Windows Server 2016
Version and build of PowerShell the target node is running
Name Value
PSVersion 5.1.14393.3471 PSEdition Desktop PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...} BuildVersion 10.0.14393.3471 CLRVersion 4.0.30319.42000 WSManStackVersion 3.0 PSRemotingProtocolVersion 2.3 SerializationVersion 1.1.0.1
Version of the DSC module that was used
1.1.0.0. Checked 1.2.0.0 it contains same code with regards to SchUseStrongCrypto and SystemDefaultTlsVersions