Problems on downloads in docker based on windowsservercore (Appveyor, Visual Studio 2017)

Question

I have a small question about file downloads on windowsservercore docker image. I have a small docker image listed here: https://github.com/EndurantDevs/sonarqube-mysql-windows-docker

As you can see - there are four similar Docker files: 2 versions of SonarQube that are based on 2 versions of Windows containers (nanoserver and windowsservercore, through openjdk image )

During the Build process, downloads of required files on nanoserver go well.

However, on windowsservercore images I get this problem:

Invoke-WebRequest : The underlying connection was closed: An unexpected error  occurred on a send. At line:1 char:1
+ Invoke-WebRequest https://sonarsource.bintray.com/Distribution/sonarq ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:Htt     pWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShe     ll.Commands.InvokeWebRequestCommand

So, the issue appears on download of the same files from the same servers that work well from nanoserver.

Applying all known fixes including the Tls12 didn't help. I would assume this is a problem on the host machine on Appveyor side. However, even fixes for registry I tried didn't help also.

Here is builds information to compare: https://ci.appveyor.com/project/dnikolayev/sonarqube-mysql-windows-docker/build/1.0.53

Answer 1

Try adding [Net.ServicePointManager]::SecurityProtocol command before Invoke-WebRequest to display protocols enabled on docker instance and compare "good" and "bad" one. After comparison you can make a decision how to update SSL settings.

Most forgiving would be allow all by setting [Net.ServicePointManager]::SecurityProtocol = 'Ssl3', 'Tls', 'Tls11', 'Tls12'. This will not necessary compromise your security as this will allow client to negotiate any security protocol with the server, but it will try use highest possible anyway. But sure you can be more restrictive and comparison of "good" and "bad" builds with [Net.ServicePointManager]::SecurityProtocol command will give you an idea.