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

Error occurred during the SSL handshake after P4 plugin is upgraded to 1.11.0 from 1.10.14

    XMLWordPrintable

Details

    • Task
    • Status: Closed (View Workflow)
    • Minor
    • Resolution: Fixed
    • p4-plugin
    • Jenkins Version: 2.235.5 docker image jenkins/jenkins:2.235.5
      P4 plugin version that has issue: 1.11.0

    Description

      Error occurred during the SSL handshake after P4 plugin is upgraded to 1.11.0 from 1.10.14

      Error:

      [Pipeline] p4sync
      11:43:26  WARNING: Unknown parameter(s) found for class type 'org.jenkinsci.plugins.p4.populate.ForceCleanImpl': modtime,replace,tidy
      11:43:29  Executor number at runtime: 0
      11:43:29  P4: Connection retry: 1
      11:43:32  Error occurred during the SSL handshake: invalid SSL session
      

      Attachments

        Activity

          shivaji_thanneeru Shivaji Thanneeru created issue -
          p4karl Karl Wirth added a comment -

          The new version of the plugin upgraded the base TLS version used. From the release notes:

              https://github.com/jenkinsci/p4-plugin/blob/master/RELEASE.md

                    P4Java now defaults to TLSv1.2 for SSL connections (previously TLSv1) to use an older version please refer to our KB article.

          Its possible that your P4D server does not support TLSv1.2 or has been fixed at TSLv1 so you may need to try the workaround mention in the KB article to downgrade the version of TLS used by P4Jenkins.

          p4karl Karl Wirth added a comment - The new version of the plugin upgraded the base TLS version used. From the release notes:     https://github.com/jenkinsci/p4-plugin/blob/master/RELEASE.md           P4Java now defaults to TLSv1.2 for SSL connections (previously TLSv1) to use an older version please refer to our KB article . Its possible that your P4D server does not support TLSv1.2 or has been fixed at TSLv1 so you may need to try the workaround mention in the KB article to downgrade the version of TLS used by P4Jenkins.
          p4karl Karl Wirth added a comment - - edited

          Additional note. TLS 1.2 support was added in Perforce in 2016.2  2018.1 (See Paul's comment below):

          Bugs fixed in 2016.2 Patch 2
          
          #1481077, #1481305, #1483342 (Bugs #89051, #90160) * ** ***
          	    SSL connections now allow use of TLSv1.1 and TLSv1.2 in addition
          	    to the existing support for TLSv1.0.  Clients and servers will
          	    choose the highest TLS version supported by both ends of the
          	    connection; thus old clients and old servers will always use
          	    TLSv1.0, and by default new clients connecting to new servers
          	    will use TLSv1.2.	    Two new configurables are provided to restrict the allowed TLS
          	    versions when a new client connnects to a new server:
          	        ssl.tls.version.min    [default=10]
          	        ssl.tls.version.max    [default=12]
          	    These default settings allow TLSv1.0, TLSv1.1, and TLSv1.2.	    Each of these configurables can take one of the following
          	    values:
          	        10 specifies TLSv1.0
          	        11 specifies TLSv1.1
          	        12 specifies TLSv1.2
          	   ssl.tls.version.min specifies the lowest TLS version that
          	   will be accepted, and ssl.tls.version.max specifies the
          	   highest TLS version that will be accepted.	   Changes to these configurables on a server will not take
          	   effect until the server is restarted.	   Thus, to force use of a new client, the server can set
          	       ssl.tls.version.min=11    (or 12)
          	   because old clients support only TLSv1.0.	   To force the use of TLSv1.1, set
          	        ssl.tls.version.min=11
          	        ssl.tls.version.max=11	   To force the use of TLSv1.2, set
          	        ssl.tls.version.min=12
          	        ssl.tls.version.max=12	    To allow TLSv1.1 or TLSv1.2 but exclude TLSv1.0, set
          	        ssl.tls.version.min=11
          	        ssl.tls.version.max=12	    These configurables are designed to allow the server to restrict
          	    the set of allowed TLS protocol versions, but they can be used
          	    by clients as well; this is probably useful mostly for testing,
          	    although it can be use to prevent connecting to potentially
          	    vulnerable servers.  When used by a client these configurables
          	    specify the lowest and highest TLS versions that will be offered.	    Values of either configurable outside of the legal range will be
          	    treated as if they were pinned to the nearest end of the range.
          	    Thus values below 10 will be treated as 10; values above 12 will
          	    be treated as 12.	    Be careful not to set ssl.tls.version.min > ssl.tls.version.max
          	    because then no clients will be able to connect.  In this case
          	    you will need to change these settings on the command line, e.g.:
          	        p4d -c"set ssl.tls.version.min=10"
          	        p4d -c"set ssl.tls.version.max=12"
          	    and then restart the server.	    Note that if there are no allowed TLS versions common to the
          	    client and the server, or if the server is not using SSL, then
          	    the client will get an error similar to this:	    Perforce client error:
          	        SSL connect to ssl:host:1666 failed  (Connection reset by peer).
          	        Remove SSL protocol prefix from P4PORT or fix the TLS settings.	    If the client or server does not offer any protocol versions (eg,
          	    because the client set ssl.tls.version.min > ssl.tls.version.max)
          	    then the client will get an error similar to this:	    Perforce client error:
          	        SSL protocol: error:14077102:SSL routines:
          	            SSL23_GET_SERVER_HELLO:unsupported protocol:	    There are only two lines in this error message; the actual error
          	    has the "SSL protocol:" line and the "GET_SERVER_HELLO" line
          	    on a single line, but they are split here for readability.
          

          End of standard maintenance support for P4D 2016.2 was Nov 8, 2018:

             https://www.perforce.com/maintenance-support

           

          p4karl Karl Wirth added a comment - - edited Additional note. TLS 1.2 support was added in Perforce in 2016.2   2018.1 (See Paul's comment below): Bugs fixed in 2016.2 Patch 2 #1481077, #1481305, #1483342 (Bugs #89051, #90160) * ** *** SSL connections now allow use of TLSv1.1 and TLSv1.2 in addition to the existing support for TLSv1.0. Clients and servers will choose the highest TLS version supported by both ends of the connection; thus old clients and old servers will always use TLSv1.0, and by default new clients connecting to new servers will use TLSv1.2. Two new configurables are provided to restrict the allowed TLS versions when a new client connnects to a new server: ssl.tls.version.min [ default =10] ssl.tls.version.max [ default =12] These default settings allow TLSv1.0, TLSv1.1, and TLSv1.2. Each of these configurables can take one of the following values: 10 specifies TLSv1.0 11 specifies TLSv1.1 12 specifies TLSv1.2 ssl.tls.version.min specifies the lowest TLS version that will be accepted, and ssl.tls.version.max specifies the highest TLS version that will be accepted. Changes to these configurables on a server will not take effect until the server is restarted. Thus, to force use of a new client, the server can set ssl.tls.version.min=11 (or 12) because old clients support only TLSv1.0. To force the use of TLSv1.1, set ssl.tls.version.min=11 ssl.tls.version.max=11 To force the use of TLSv1.2, set ssl.tls.version.min=12 ssl.tls.version.max=12 To allow TLSv1.1 or TLSv1.2 but exclude TLSv1.0, set ssl.tls.version.min=11 ssl.tls.version.max=12 These configurables are designed to allow the server to restrict the set of allowed TLS protocol versions, but they can be used by clients as well; this is probably useful mostly for testing, although it can be use to prevent connecting to potentially vulnerable servers. When used by a client these configurables specify the lowest and highest TLS versions that will be offered. Values of either configurable outside of the legal range will be treated as if they were pinned to the nearest end of the range. Thus values below 10 will be treated as 10; values above 12 will be treated as 12. Be careful not to set ssl.tls.version.min > ssl.tls.version.max because then no clients will be able to connect. In this case you will need to change these settings on the command line, e.g.: p4d -c "set ssl.tls.version.min=10" p4d -c "set ssl.tls.version.max=12" and then restart the server. Note that if there are no allowed TLS versions common to the client and the server, or if the server is not using SSL, then the client will get an error similar to this : Perforce client error: SSL connect to ssl:host:1666 failed (Connection reset by peer). Remove SSL protocol prefix from P4PORT or fix the TLS settings. If the client or server does not offer any protocol versions (eg, because the client set ssl.tls.version.min > ssl.tls.version.max) then the client will get an error similar to this : Perforce client error: SSL protocol: error:14077102:SSL routines: SSL23_GET_SERVER_HELLO:unsupported protocol: There are only two lines in this error message; the actual error has the "SSL protocol:" line and the "GET_SERVER_HELLO" line on a single line, but they are split here for readability. End of standard maintenance support for P4D 2016.2 was Nov 8, 2018:    https://www.perforce.com/maintenance-support  
          fl_shiki Kevin Dethoor added a comment -

          Hi,

          I found this issue from JENKINS-26176. As I originally posted there, I encountered the same problems testing SSL connections in Jenkins P4 credential page with Java JRE 1.8.0_261, Jenkins 2.235.5 installed from the war file, P4 Plugin 1.11.0 and a Perforce server 2018.1 (TLS min: 1.0, TLS max: 1.2). I tried the solutions on the KB page, but they didn't work for me. Eventually, downgrading both Jenkins (2.235.5 -> 2.235.1) and the P4 Plugin (1.11.0 -> 1.10.4) did the trick and allowed me to establish a connection.

          Hope this information helps.

          fl_shiki Kevin Dethoor added a comment - Hi, I found this issue from JENKINS-26176 . As I originally posted there, I encountered the same problems testing SSL connections in Jenkins P4 credential page with Java JRE 1.8.0_261, Jenkins 2.235.5 installed from the war file, P4 Plugin 1.11.0 and a Perforce server 2018.1 (TLS min: 1.0, TLS max: 1.2). I tried the solutions on the KB page, but they didn't work for me. Eventually, downgrading both Jenkins (2.235.5 -> 2.235.1) and the P4 Plugin (1.11.0 -> 1.10.4) did the trick and allowed me to establish a connection. Hope this information helps.
          p4paul Paul Allen added a comment -

          You need a P4D Server 18.1 or greater with the patch version greater than 1805524

          	#1805524 (Job #97669) * ** *** ****
          	    SSL connections that negotiated with TLS 1.1 and above handshakes
          	    were rejected as plaintext. This has been fixed.
          	    Note that successful negotiation would still result in the use up
          	    to TLS 1.2 regardless of the version used for negotiation. 
          p4paul Paul Allen added a comment - You need a P4D Server 18.1 or greater with the patch version greater than 1805524 #1805524 (Job #97669) * ** *** **** SSL connections that negotiated with TLS 1.1 and above handshakes were rejected as plaintext. This has been fixed. Note that successful negotiation would still result in the use up to TLS 1.2 regardless of the version used for negotiation.
          fl_shiki Kevin Dethoor added a comment -

          Hi Paul and Karl,

          Thank you very much for your help.

          It was indeed an issue with our server version (2018.1 patch 1715250). I was able to establish a connection using Java 1.8.0_261, Jenkins 2.235.5, P4 Plugin 1.11.0 and adding -DsecureSocketEnabledProtocols=TLSv1 to my Java arguments as prescribed in Perforce Knowledgebase (https://community.perforce.com/s/article/2620). I thought I had tried that previously but I made the mistake of specifying TLSv1.0 instead of TLSv1. With TLSv1, everything works as expected.

          Many thanks again.

           

          fl_shiki Kevin Dethoor added a comment - Hi Paul and Karl, Thank you very much for your help. It was indeed an issue with our server version (2018.1 patch 1715250). I was able to establish a connection using Java 1.8.0_261, Jenkins 2.235.5, P4 Plugin 1.11.0 and adding -DsecureSocketEnabledProtocols=TLSv1 to my Java arguments as prescribed in Perforce Knowledgebase ( https://community.perforce.com/s/article/2620 ). I thought I had tried that previously but I made the mistake of specifying TLSv1.0 instead of TLSv1. With TLSv1, everything works as expected. Many thanks again.  
          p4karl Karl Wirth added a comment -

          Hi fl_shiki,

           

          Thanks and happy to help. Also this has highlighted a problem with our older release notes so we've got the developers investigating so thanks again.

           

          Regards,

          Karl

          p4karl Karl Wirth added a comment - Hi fl_shiki ,   Thanks and happy to help. Also this has highlighted a problem with our older release notes so we've got the developers investigating so thanks again.   Regards, Karl
          latalavera jesus fernandez made changes -
          Field Original Value New Value
          Comment [ I have been using Jenkins on windows as a service (v.2.235) and also I am using P4 plugin. But I need to stop the service and start using jenkins from the cmd so I can have access to execute GUI applications in my pipeline. I downladed the latest jenkins.war(2.263.2 ) and execute it from the cmd, but now again I have the same issue of the SSL handshake, I have check the jenkins.xml file and it is the same as it was:

          <executable>C:\Program Files\Java\jdk1.8.0_261\bin\java.exe</executable>
          <arguments>-DsecureSocketEnabledProtocols=TLSv1 -Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar "C:\Program Files\Jenkins\jenkins.war" --httpPort=8080 --webroot="%LocalAppData%\Jenkinswar"</arguments>

          Actually if closing the cmd and starting the service back again the handshake works just fine. So I am wondering if I need to change the configuration in any other file when running it from the cmd maybe? any help is much appreciated. Thanks ]
          p4karl Karl Wirth made changes -
          Comment [ Hi [~latalavera] ,

          "Now and again" seems strange. If it didnt work at the command line I would say that either the correct SSL libaries were not installed in the Java you were using or it was not picking up the correct arguments from the config file.

          Can you please raise a case with 'support@perforce.com' and include the full console output where it fails and the output from 'p4 -Ztag info' run against your P4D server.

          Thanks in advance,

          Karl

           

            ]
          shentoza Joscha added a comment -

          Hey there, I'm currently experiencing a similar issue. 
          Java 1.80_281, Jenkins 2.276, P4 Plugin 1.11.2  and p4d version (  P4D/NTX64/2018.1/1957529 (2020/05/06) )

          I still have to provice the java args_-DsecureSocketEnabledProtocols=TLSv1_  in order to get the ssl connection running to our main perforce server.
          Changing it to TLSv1.2 or 1.1  will give an ssl session error.    ssl.tls.version of our p4d is *.min:10  *.max:12

          shentoza Joscha added a comment - Hey there, I'm currently experiencing a similar issue.  Java 1.80_281, Jenkins 2.276, P4 Plugin 1.11.2  and p4d version (  P4D/NTX64/2018.1/1957529 (2020/05/06) ) I still have to provice the java args_-DsecureSocketEnabledProtocols=TLSv1_  in order to get the ssl connection running to our main perforce server. Changing it to TLSv1.2 or 1.1  will give an ssl session error.    ssl.tls.version of our p4d is *.min:10  *.max:12
          p4karl Karl Wirth added a comment -

          Hi shentoza - Sorry I missed your message last week. This works OK for me. I'm using:

          Server version: P4D/NTX64/2018.1/1957529 (2020/05/06)

          Jenkins 2.235.1

          P4-Plugin 1.11.2

          C:\> p4 configure show
          P4ROOT=E:\filestore\ws\18.1\p4root (-r)
          P4PORT=ssl:6749 (-p)
          P4NAME=p4d.exe.18.1.1957529 (services registry)
          P4LOG=log (-L)
          server: 1 (P4DEBUG)
          ssl.tls.version.min: 10 (configure)
          ssl.tls.version.max: 12 (configure)
          
          

          The Java I have is the one shipped with Jenkins  - 1.8.0 (252).

          If you are still having problems can you please email 'support@perforce.com' so we can investigate further.

           

           

           

           

          p4karl Karl Wirth added a comment - Hi shentoza - Sorry I missed your message last week. This works OK for me. I'm using: Server version: P4D/NTX64/2018.1/1957529 (2020/05/06) Jenkins 2.235.1 P4-Plugin 1.11.2 C:\> p4 configure show P4ROOT=E:\filestore\ws\18.1\p4root (-r) P4PORT=ssl:6749 (-p) P4NAME=p4d.exe.18.1.1957529 (services registry) P4LOG=log (-L) server: 1 (P4DEBUG) ssl.tls.version.min: 10 (configure) ssl.tls.version.max: 12 (configure) The Java I have is the one shipped with Jenkins  - 1.8.0 (252). If you are still having problems can you please email 'support@perforce.com' so we can investigate further.        
          shentoza Joscha added a comment -

          Hi Karl,
          yeah sorry that one is my fault. I totally missed that our main server is on an older p4d version still, its our replica that has a more recent 2018.1 version.
          Can I easily update the minor versions without too much worries?
          I'd really love to update at least the minor version (honestly also the major version) but I'm too scared about that
          '
          Greetings

          shentoza Joscha added a comment - Hi Karl, yeah sorry that one is my fault. I totally missed that our main server is on an older p4d version still, its our replica that has a more recent 2018.1 version. Can I easily update the minor versions without too much worries? I'd really love to update at least the minor version (honestly also the major version) but I'm too scared about that ' Greetings
          p4karl Karl Wirth made changes -
          Labels p4-plugin P4_A P4_VERIFY p4-plugin
          p4karl Karl Wirth made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Closed [ 6 ]

          People

            Unassigned Unassigned
            shivaji_thanneeru Shivaji Thanneeru
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: