microsoft / navcontainerhelper

Official Microsoft repository for BcContainerHelper, a PowerShell module, which makes it easier to work with Business Central Containers on Docker.
MIT License
382 stars 246 forks source link

Sign-NavContainerApp fails with SSL/TLS error in Sign-tool download #2388

Closed KoFrank closed 2 years ago

KoFrank commented 2 years ago

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

Container Creation:
$artifactUrl = Get-BCArtifactUrl -type OnPrem -version "19.0.0.0" -select Closest -country "w1"

$licenseFile = "<Path to license file>"
$ContainerName = 'runtime'
$UserName = 'user'
$Password = ConvertTo-SecureString 'password' -AsPlainText -Force
$Credential = New-Object System.Management.Automation.PSCredential ($UserName,$Password)

New-NavContainer `
     -accept_eula `
    -accept_outdated `
    -containerName $ContainerName `
    -artifactUrl $artifactURL `
    -licenseFile $licenseFile `
    -auth NavUserPassword `
    -Credential $Credential `
    -useBestContainerOS `
    -doNotExportObjectsToText `
    -assignPremiumPlan `

Signing call:
Sign-NavContainerApp -containerName runtime -appFile $file.FullName -pfxFile $cert -pfxPassword $certPassword -Verbose

Full output of scripts

Container Creation: 
Default parameter UpdateHosts = True
Default parameter Isolation = Process
Default parameter Multitenant = False
BcContainerHelper is version 3.0.3
BcContainerHelper is running as administrator
Host is Microsoft Windows Server 2016 Standard - ltsc2016
Docker Client Version is 20.10.9
Docker Server Version is 20.10.9
Removing container runtime
Removing runtime from container hosts file
Removing runtime-* from container hosts file
Removing C:\ProgramData\BcContainerHelper\Extensions\runtime
Fetching all docker images
Fetching all docker volumes
Using image mcr.microsoft.com/businesscentral:10.0.14393.3384
Creating Container runtime
Style: onprem
Multitenant: No
Version: 19.0.29894.30693
Platform: 19.0.29884.30666
Generic Tag: 1.0.2.1
Container OS Version: 10.0.14393.3384 (ltsc2016)
Host OS Version: 10.0.14393.3384 (ltsc2016)
Using Process isolation
Using locale en-US
Disabling the standard eventlog dump to container log every 2 seconds (use -dumpEventLog to enable)
Using license file C:\Export\NET.flf
Files in C:\ProgramData\BcContainerHelper\Extensions\runtime\my:
- AdditionalOutput.ps1
- license.flf
- MainLoop.ps1
- SetupNavUsers.ps1
- SetupVariables.ps1
- updatehosts.ps1
Creating container runtime from image mcr.microsoft.com/businesscentral:10.0.14393.3384
0ec8d3a354b89d540da913ba7e0850b7851f9e01359091b2495660cac0e74ea2
Waiting for container runtime to be ready
Using artifactUrl https://bcartifacts.azureedge.net/onprem/19.0.29894.30693/w1
Using installer from C:\Run\150-new
Installing Business Central
Installing from artifacts
Starting Local SQL Server
Starting Internet Information Server
Copying Service Tier Files
c:\dl\onprem\19.0.29894.30693\platform\ServiceTier\Program Files
c:\dl\onprem\19.0.29894.30693\platform\ServiceTier\System64Folder
Copying PowerShell Scripts
c:\dl\onprem\19.0.29894.30693\platform\WindowsPowerShellScripts\Cloud\NAVAdministration
c:\dl\onprem\19.0.29894.30693\platform\WindowsPowerShellScripts\WebSearch
Copying dependencies
Copying ReportBuilder
Importing PowerShell Modules
Determining Database Collation from c:\dl\onprem\19.0.29894.30693\w1\database\Demo Database BC (19-0).bak
Restoring CRONUS Demo Database
Setting CompatibilityLevel for CRONUS on localhost\SQLEXPRESS
Modifying Business Central Service Tier Config File for Docker
Creating Business Central Service Tier
Installing SIP crypto provider: 'C:\Windows\System32\NavSip.dll'
Copying Web Client Files
c:\dl\onprem\19.0.29894.30693\platform\WebClient\Microsoft Dynamics NAV
Copying Client Files
c:\dl\onprem\19.0.29894.30693\platform\LegacyDlls\program files\Microsoft Dynamics NAV
c:\dl\onprem\19.0.29894.30693\platform\LegacyDlls\program files\Microsoft Dynamics NAV
c:\dl\onprem\19.0.29894.30693\platform\LegacyDlls\systemFolder
Copying ModernDev Files
c:\dl\onprem\19.0.29894.30693\platform
c:\dl\onprem\19.0.29894.30693\platform\ModernDev\program files\Microsoft Dynamics NAV
Copying additional files
Copying ConfigurationPackages
C:\dl\onprem\19.0.29894.30693\platform\ConfigurationPackages
Copying Test Assemblies
C:\dl\onprem\19.0.29894.30693\platform\Test Assemblies
Copying Applications
C:\dl\onprem\19.0.29894.30693\platform\Applications
Starting Business Central Service Tier
Importing license file
Stopping Business Central Service Tier
Installation took 127 seconds
Installation complete
Initializing...
Setting host.containerhelper.internal to 172.20.192.1 in container hosts file
Starting Container
Hostname is runtime
PublicDnsName is runtime
Using NavUserPassword Authentication
Creating Self Signed Certificate
Self Signed Certificate Thumbprint 89108195FFED54F1D73B12F4B6735C92B964F21D
DNS identity runtime
Modifying Service Tier Config File with Instance Specific Settings
Starting Service Tier
Registering event sources
Creating DotNetCore Web Server Instance
Using license file 'c:\run\my\license.flf'
Import License
Creating http download site
Setting SA Password and enabling SA
Creating admin as SQL User and add to sysadmin
Creating SUPER user
Assign Premium plan for ADMIN
Container IP Address: 172.20.198.206
Container Hostname  : runtime
Container Dns Name  : runtime
Web Client          : http://runtime/BC/
Dev. Server         : http://runtime
Dev. ServerInstance : BC
Setting runtime to 172.20.198.206 in host hosts file

Files:
http://runtime:8080/ALLanguage.vsix

WARNING: You are running a container which is 499 days old.
Microsoft recommends that you always run the latest version of our containers.

Container Total Physical Memory is 6.0Gb
Container Free Physical Memory is 2.6Gb

Initialization took 31 seconds
Ready for connections!
Reading CustomSettings.config from runtime
Creating Desktop Shortcuts for runtime
Container runtime successfully created

Afterwards signing the extension:

Copying certificate file to container
Downloading Signing Tools
Exception calling "DownloadFile" with "2" argument(s): "The request was aborted: Could not create SSL/TLS secure channel."
at <ScriptBlock>, <No file>: line 24
at Invoke-ScriptInBcContainer, C:\Program Files\WindowsPowerShell\Modules\BcContainerHelper\3.0.3\ContainerHandling\Invoke-ScriptInNavContainer.ps1: line 43
at Sign-BcContainerApp, C:\Program Files\WindowsPowerShell\Modules\BcContainerHelper\3.0.3\AppHandling\Sign-NavContainerApp.ps1: line 86
at <ScriptBlock>, C:\Users\vmAdmin\Desktop\Skripte für Docker VM\Release BC 19 VJS.ps1: line 49
Sign-NavContainerApp Telemetry Correlation Id: b787d0e9-dee0-45a9-941c-0ff1beaaed03
Exception calling "DownloadFile" with "2" argument(s): "The request was aborted: Could not create SSL/TLS secure channel."
At C:\Program Files\WindowsPowerShell\Modules\BcContainerHelper\3.0.3\ContainerHandling\Invoke-ScriptInNavContainer.ps1:44 char:13
+             throw $_.Exception.Message
+             ~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Exception calli...ecure channel.":String) [], RuntimeException
    + FullyQualifiedErrorId : Exception calling "DownloadFile" with "2" argument(s): "The request was aborted: Could not create SSL/TLS secure channel."

Screenshots If applicable, add screenshots to help explain your problem.

Additional context

rvanbekkum commented 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.

pmatsconsulting commented 2 years ago

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)"
...
kine commented 2 years ago

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.

freddydk commented 2 years ago

Thanks for sharing - will consider adding this workaround to containerhelper

freddydk commented 2 years ago

@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.

freddydk commented 2 years ago

Included in latest prerelease

KoFrank commented 2 years ago

That's great news! Thank you @freddydk for your quick reaction.

freddydk commented 2 years ago

Shipped in 3.0.5

kine commented 2 years ago

@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.

freddydk commented 2 years ago

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...