xRemoteFile fails to download files from GitHub with error "Could not create SSL/TLS secure channel"

[Yvand]

Recently I noticed that the download of binaries from GitHub always fail in my DSC deployment. I seem to repro always on Windows Server 2012 R2 but never on Windows Server 2016. Here is the repro:

xRemoteFile DownloadLdapcp
{
	Uri             = "https://github.com/Yvand/LDAPCP/releases/download/v2017-10/LDAPCP.wsp"
	DestinationPath = "F:\Setup\LDAPCP.wsp"
}

From my tests it seems related to the issue documented in https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-update-1802: "This error occurs because of a recent GitHub support deprecation of the Tlsv1 and Tlsv1.1 cryptographic standards (the default for PowerShell)"

I made a dirty fix by forcing TLS 1.2 protocol directly in xRemoteFile resource and this works:

# Invoke web request
try
{
	# Force protocol TLS 1.2 to avoid TLS/SSL error when downloading from GitHub, as documented in https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-update-1802
	[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
	Write-Verbose -Message "YVANDCHANGE: Force protocol TLS 1.2"
	Write-Verbose -Message $($LocalizedData.DownloadingURI `
		-f ${DestinationPath},${URI})
	Invoke-WebRequest @PSBoundParameters -Headers $headersHashtable -outFile $DestinationPath
}

[RobCannon]

There is a better way of setting this value in this Stack Overflow answer. Stack Overflow

But this is a big issue for PowerShell. It impacts xPackage, installing modules, calling REST APIs, etc.. As more and more sites go to TLS1.2, this will cripple PowerShell unless there is an update to set the defaults.

[RobCannon]

I found that these registry settings fix the issue:

        Registry SchUseStrongCrypto
        {
            Key                         = 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319'
            ValueName                   = 'SchUseStrongCrypto'
            ValueType                   = 'Dword'
            ValueData                   =  '1'
            Ensure                      = 'Present'
        }

        Registry SchUseStrongCrypto64
        {
            Key                         = 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319'
            ValueName                   = 'SchUseStrongCrypto'
            ValueType                   = 'Dword'
            ValueData                   =  '1'
            Ensure                      = 'Present'
        }

[Yvand]

Do you consider that setting those registry entries is a better option than forcing TLS 1.2 in the resource?

[RobCannon]

Yes, because this has such a wide impact. You can Install-Module from a source that has disabled TLS1.1, for instance. Microsoft really needs to patch this to make it the default at this point.

[johlju]

There could potentially be an optional array parameter that has a ValidateSet() for each valid protocol. If assigned the protocol will be changed. This could be used for future protocol versions as well.

[ciberesponce]

I found that these registry settings fix the issue:

        Registry SchUseStrongCrypto
        {
            Key                         = 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319'
            ValueName                   = 'SchUseStrongCrypto'
            ValueType                   = 'Dword'
            ValueData                   =  '1'
            Ensure                      = 'Present'
        }

        Registry SchUseStrongCrypto64
        {
            Key                         = 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319'
            ValueName                   = 'SchUseStrongCrypto'
            ValueType                   = 'Dword'
            ValueData                   =  '1'
            Ensure                      = 'Present'
        }

This fixed it--I searched forever, changing WinHTTP settings, Internet Explorer, SChannel. I should of realized its a .NET setting seeing DSC is PowerShell... thanks for sharing.