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

          Matthew Mitchell created issue -
          Matthew Mitchell made changes -
          Description Original: 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.
          New: 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.
          Matthew Mitchell made changes -
          Summary Original: Windows powershell throws 'The request was aborted: Could not create SSL/TLS secure channel' when accessing Jenkins after 2.73.1 update New: .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.
          Oleg Nenashev made changes -
          Labels New: winsw

          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"
          Matthew Mitchell made changes -
          Assignee New: Matthew Mitchell [ mmitche ]

          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
          Matthew Mitchell made changes -
          Resolution New: Not A Defect [ 7 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]

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

              Created:
              Updated:
              Resolved: