Details
-
Bug
-
Status: Resolved (View Workflow)
-
Blocker
-
Resolution: Not A Defect
-
Host/client java version "1.8.0_144"
Jenkins version 2.73.1 LTS
Description
After upgrading to 2.73.1, attempts to use Invoke-WebRequest (Windows only) to download from the Jenkins server (basically any request...but in this case it was downloading the slave.jar file) always throw:
The request was aborted: Could not create SSL/TLS secure channel.
This server has https enabled, with http redirecting to https via nginx. Nothing else changed except the upgrade from 2.60.3.
Now, this is quite possible a server configuration error, but I'm looking for some info on what might have caused the regression.
Connections of nodes via SSH, as well as curl on non-Windows platforms seem to be fine. Running inside the browser on Windows seems to be fine too.
Attachments
Activity
Good point. https://jenkins.io/doc/upgrade-guide/2.73/#winstone-4-1-upgrade only mentions the dropped SPDY support. I'll add a note on support for TLS <1.2 dropped as well per https://github.com/eclipse/jetty.project/blob/f107ec8c213cfe73bae067a8984367ac627224d1/VERSION.txt#L607
I realize that this isn't a problem that was created by anything Jenkins, but this broke a bunch of windows node workflows.
I would have liked a lot more visibility into breaking changes with this upgrade.
igycrctl LTS RC testing is a monthly community effort, and you're invited to participate:
https://groups.google.com/d/msg/jenkinsci-dev/MOzX503CVdU/lT8KBCqkBAAJ
Arnt Witteveen
added a comment - This looks a lot like JENKINS-51577 , I think? 
Issue is that TLS1.0 is rejected. Powershell on Windows defaults to TLS1.0. This can be fixed by setting the following registry keys, which enables 1.1 and 2.
new-itemproperty -path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -name "SchUseStrongCrypto" -Value 1 -PropertyType "DWord"; new-itemproperty -path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -name "SchUseStrongCrypto" -Value 1 -PropertyType "DWord"
Not a defect