Status: Closed (View Workflow)
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
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.
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)
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.
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.
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.