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

jenkins.war 2.303.3 bundles remoting.jar with an expired self-signed certificate

    • 2.323

      As per https://www.jenkins.io/changelog-stable/ release 2.249.1 "switches agent.jar and remoting.jar to a code-signing certificate owned by the CDF". This is indeed the case as can be verified by downloading the said jenkins.war, unzipping it and running 

       

      jarsigner -verbose:summary -verify WEB-INF\lib\remoting-4.5.jar

       

      This certificate is used up until release 2.303.2 but then for some reason in 2.303.3 this happens:

      jarsigner -verbose:summary -verify WEB-INF\lib\remoting-4.10.1.jar

      s 131429 Fri Oct 22 16:49:26 EEST 2021 META-INF/MANIFEST.MF
      131410 Fri Oct 22 16:49:26 EEST 2021 META-INF/JENKINS.SF (and 1 more)
      0 Fri Oct 22 16:49:08 EEST 2021 META-INF/ (and 80 more)
      sm 1137 Fri Oct 22 16:48:42 EEST 2021 META-INF/annotations/org.kohsuke.accmod.Restricted (and 942 more)

      s = signature was verified
      m = entry is listed in manifest
      k = at least one certificate was found in keystore

      • Signed by "CN=Unknown, OU=Jenkins project, O=Continuous Integration Server, L=San Jose, ST=California, C=US"
        Digest algorithm: SHA-256
        Signature algorithm: SHA256withDSA, 1024-bit key

      jar verified.

      Warning:
      This jar contains entries whose signer certificate has expired.
      This jar contains entries whose certificate chain is invalid. Reason: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
      This jar contains entries whose signer certificate is self-signed.
      This jar contains signatures that do not include a timestamp. Without a timestamp, users may not be able to validate this jar after any of the signer certificates expire (as early as 2021-01-30).

      Re-run with the -verbose and -certs options for more details.

          [JENKINS-67227] jenkins.war 2.303.3 bundles remoting.jar with an expired self-signed certificate

          Daniel Beck added a comment -

          Sorry about that. I forgot that we're signing remoting, and staged it from a separate environment as preparation for the delivery of security fixes in and related to that component.

          Daniel Beck added a comment - Sorry about that. I forgot that we're signing remoting, and staged it from a separate environment as preparation for the delivery of security fixes in and related to that component .

          Jeff Thompson added a comment -

          I guess some people are actually checking or using that.

          Jeff Thompson added a comment - I guess some people are actually checking or using that.

          Daniel Beck added a comment -

          Daniel Beck added a comment - https://github.com/jenkinsci/jenkins/pull/5983 (weekly, 2.323 or 2.324) + https://github.com/jenkinsci/jenkins/pull/5984 (hopefully towards 2.319.1)

          Jesse Glick added a comment -

          Reporter, out of curiosity, why were you checking the signature on this JAR to begin with? AFAIK the signature is not used by any product feature.

          Jesse Glick added a comment - Reporter, out of curiosity, why were you checking the signature on this JAR to begin with? AFAIK the signature is not used by any product feature.

          After making updates including Jenkins version upgrade in our environment we started getting this 

          when using JNLP and then started investigating what was going and discovered what was then eventually reported in this ticket.

          In one of our automation setups this has been the go-to method to run Windows GUI automation.

          We fixed the problem by downgrading to 2.303.2.

          Jani Koivulainen added a comment - After making updates including Jenkins version upgrade in our environment we started getting this  when using JNLP and then started investigating what was going and discovered what was then eventually reported in this ticket. In one of our automation setups this has been the go-to method to run Windows GUI automation. We fixed the problem by downgrading to 2.303.2.

          Jesse Glick added a comment -

          OK, so you were actually using Java Web Start. We do not recommend use of JWS for launching agents—there are better ways, like the Windows service wrapper, or just do-it-yourself java -jar remoting.jar -jnlpUrl …—and JWS was dropped from Java after 8 anyway.

          At any rate, did you try simply clicking I accept the risk and want to run this application.? There is no real risk here—if you trusted jenkins.war, there is no reason to apply further checks to the remoting.jar it bundles. In the fact the whole point of the critical security update in 2.303.3 was to close some loopholes in the system by which you can trust the controller (jenkins.war) but not trust agents (remoting.jar), so downgrading because of this dialog box is especially perverse.

          Jesse Glick added a comment - OK, so you were actually using Java Web Start. We do not recommend use of JWS for launching agents—there are better ways, like the Windows service wrapper, or just do-it-yourself java -jar remoting.jar -jnlpUrl … —and JWS was dropped from Java after 8 anyway. At any rate, did you try simply clicking I accept the risk and want to run this application. ? There is no real risk here—if you trusted jenkins.war , there is no reason to apply further checks to the remoting.jar it bundles. In the fact the whole point of the critical security update in 2.303.3 was to close some loopholes in the system by which you can trust the controller ( jenkins.war ) but not trust agents ( remoting.jar ), so downgrading because of this dialog box is especially perverse.

          Thanks, that is understood. I'm not familiar with the background of the Jenkins deployment by our customer. I just helped them analyze why their GUI-automation stopped working because there were dialog boxes they had not seen before. I was not there to ask them to "accept the risk and run the application", the message that triggered the investigation just talked about an "expired certificate". The above dialog came after the fact.

          Jani Koivulainen added a comment - Thanks, that is understood. I'm not familiar with the background of the Jenkins deployment by our customer. I just helped them analyze why their GUI-automation stopped working because there were dialog boxes they had not seen before. I was not there to ask them to "accept the risk and run the application", the message that triggered the investigation just talked about an "expired certificate". The above dialog came after the fact.

            jthompson Jeff Thompson
            jamppajanik Jani Koivulainen
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: