Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-46968

.NET Framework http connections throw 'The request was aborted: Could not create SSL/TLS secure channel' when accessing Jenkins after 2.73.1 update

    • Icon: Bug Bug
    • Resolution: Not A Defect
    • Icon: Blocker Blocker
    • core
    • Host/client java version "1.8.0_144"
      Jenkins version 2.73.1 LTS

      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.

          [JENKINS-46968] .NET Framework http connections throw 'The request was aborted: Could not create SSL/TLS secure channel' when accessing Jenkins after 2.73.1 update

          Daniel Beck added a comment -

          Anything in either nginx or Jenkins logs? What URL are you requesting? Etc., this bug report is pretty anemic.

          Daniel Beck added a comment - Anything in either nginx or Jenkins logs? What URL are you requesting? Etc., this bug report is pretty anemic.

          Matthew Mitchell added a comment - - edited

          @Daniel Beck.  Yeah sorry, there wasn't much that I could find.  Nothing in the Jenkins log, and the nginx log only shows anything when attempting to use http, since it's doing the redirection to https.

          My hunch here is that the upgrade of Jetty or WinStone changed something, I'm just not sure what.  Here is how we are launching the container.

          JENKINS_ARGS="-webroot=/var/cache/$NAME/war --httpPort=-1 --httpsPort=8443 --httpsKeyStore=<keystore> httpsKeyStorePassword=<pass> -handlerCountMax=512 --sessionTimeout=120"

          Matthew Mitchell added a comment - - edited @Daniel Beck.  Yeah sorry, there wasn't much that I could find.  Nothing in the Jenkins log, and the nginx log only shows anything when attempting to use http, since it's doing the redirection to https. My hunch here is that the upgrade of Jetty or WinStone changed something, I'm just not sure what.  Here is how we are launching the container. JENKINS_ARGS="-webroot=/var/cache/$NAME/war --httpPort=-1 --httpsPort=8443 --httpsKeyStore=<keystore> httpsKeyStorePassword=<pass> -handlerCountMax=512 --sessionTimeout=120"

          I'm taking a look at the wireshark logs + jetty debug info.

          Matthew Mitchell added a comment - I'm taking a look at the wireshark logs + jetty debug info.

          danielbeck Alright, it's because in this case, the powershell client is explicitly asking for TLS 1.0.  So that's not great, and I think that can be fixed.  However, I think this implies that the jetty upgrade may have disabled TLS1.0.  If this is true, it might be good to note this in the upgrade guide, and provide a workaround in cases where clients couldn't be changed.

          Matthew Mitchell added a comment - danielbeck Alright, it's because in this case, the powershell client is explicitly asking for TLS 1.0.  So that's not great, and I think that can be fixed.  However, I think this implies that the jetty upgrade may have disabled TLS1.0.  If this is true, it might be good to note this in the upgrade guide, and provide a workaround in cases where clients couldn't be changed.

          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

          Matthew Mitchell added a comment - 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

          Daniel Beck added a comment -

          Daniel Beck added a comment - 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 PR at https://github.com/jenkins-infra/jenkins.io/pull/1143

          Paul LeTang added a comment -

          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. 

          Paul LeTang added a comment - 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. 

          Daniel Beck added a comment -

          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

           

          Daniel Beck added a comment - 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  

          This looks a lot like JENKINS-51577, I think?

          Arnt Witteveen added a comment - This looks a lot like JENKINS-51577 , I think?

            mmitche Matthew Mitchell
            mmitche Matthew Mitchell
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: