Closed KoFrank closed 2 years ago
We ran into this error as well. I suspect the ltsc2016 images from Microsoft will fall back on Tls10
but to download the signing tools, now TLS 1.2 is expected.
Our work-around was to add the following to our scripts right before Sign-BcContainerApp
is invoked:
Invoke-ScriptInNavContainer -containerName $containerName -scriptblock {
Write-Host "Setting security protocol to Tls12"
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12;
}
I think the docker images should be updated to default to Tls12
.
Hello, Faced the same issue yesterday and to solve it temporary and urgently as workarround I modified code of installed BcContainerHelper module function script Sign-NavContainerApp.ps1 to add Tls12:
Invoke-ScriptInBcContainer -containerName $containerName -ScriptBlock { Param($appFile, $pfxFile, $pfxPassword, $timeStampServer, $digestAlgorithm)
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls -bor [Net.SecurityProtocolType]::Tls11 -bor [Net.SecurityProtocolType]::Tls12
Write-Host "$([Net.ServicePointManager]::SecurityProtocol)"
...
Yes, MS disabled tls1.0 support on the servers and if you are using Windows 2016 for the containers, they have no TLS enabled by default. I have used this to enable it during container creation:
-myScripts @(@{"AdditionalSetup.ps1"={
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -name 'Enabled' -value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -name 'DisabledByDefault' -value 0 -PropertyType 'DWord' -Force | Out-Null
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -name 'Enabled' -value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -name 'DisabledByDefault' -value 0 -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -name 'SchUseStrongCrypto' -value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -name 'SystemDefaultTlsVersions' -value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v2.0.50727' -name 'SchUseStrongCrypto' -value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v2.0.50727' -name 'SystemDefaultTlsVersions' -value '1' -PropertyType 'DWord' -Force | Out-Null
$TLS12Protocol = [System.Net.SecurityProtocolType] 'Ssl3 , Tls12'
[System.Net.ServicePointManager]::SecurityProtocol = $TLS12Protocol
Write-Host "Tls12 Enabled"
}})
You can use something similar, e.g. invoke-scriptinbccontainer after creation. It should enable the TLS by default for the current and any next session in the container.
Thanks for sharing - will consider adding this workaround to containerhelper
@kine - I cannot see why all of these statements are needed? What Windows Server 2016 build are you running?
I have tried generic image with Windows Server 2016 build 10.0.14393.3384 (from the original bug) - on this one, it is sufficient to use
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12
when creating the session. On build 10.0.14393.4946 - same thing On the oldest available build 10.0.14393.2906 - same thing
Will close this issue with the checkin done two days ago.
Included in latest prerelease
That's great news! Thank you @freddydk for your quick reaction.
Shipped in 3.0.5
@kine - I cannot see why all of these statements are needed? What Windows Server 2016 build are you running?
I have tried generic image with Windows Server 2016 build 10.0.14393.3384 (from the original bug) - on this one, it is sufficient to use
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12
when creating the session. On build 10.0.14393.4946 - same thing On the oldest available build 10.0.14393.2906 - same thing
Will close this issue with the checkin done two days ago.
It is solving different things for different apps. It is just collection of "hacks" which helped to solve TLS things in different cases. Sorry for that. It grew itself during the time... :-) was not sure which one is the correct for this specific case.
I know what you mean - I am sure that I also have workarounds in place in various places which is no longer necessary It is just scary to remove them, not knowing whether you will break 1000s of pipelines tomorrow...
PLEASE DO NOT INCLUDE ANY PASSWORDS OR TOKENS IN YOUR ISSUE!!!
Describe the issue Trying to sign our extensions on a freshly created container fails with an SSL/TLS error on download of Sign-Tools
Scripts used to create container and cause the issue
Full output of scripts
Screenshots If applicable, add screenshots to help explain your problem.
Additional context