Description of problem: signer certificate expired in signed .jars in JON 3 CR2 Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. jarsigner -verify rhq-core-util-4.2.0.JON300.CR2.jar 2. 3. Actual results: signer certificate expired in signed .jars in JON 3 CR2 Expected results: signer certificate not expired Additional info: attachment includes information from -verbose option
Created attachment 537591 [details] details of jarsigner -verbose -cert
This is a consequence of our brew signing system. The current policy is that all products based off of EAP 5.x will use and be signed by the 2009 certificate, which is currently expired. The newer certificate is only being applied to EAP 6.x stream products. While JON is not tightly bound to the EAP 5.x stream, the JON 3 product does build off of and include SOA/BRMS 5.2.x which is based off of the 5.x stream. So it looks like we should continue to use the expired certificates. It appears that all brew components built recently will necessarily have this restriction. I'm going to continue to dig into this as I'm not clear what the right path is moving forward. It is interesting to note as well that because of how JON interacts with EAP 4.x/5.x/6.x that we should not necessarily be tightly bound to a specific EAP stream as we've put effort into supporting multiple streams simultaneously through various management interfaces. This will either simplify or drastically complicate our signing requirements.
See this thread on the brew mailing list: http://post-office.corp.redhat.com/archives/mead-list/2011-September/msg00007.html It looks like we're going to need to update our documentation to let the customers know that the jar sign warnings are expected. Interesting question is whether SOA/BRMS will be putting out new versions when EAP 6 is out early next year? This might need to bubble back up to project management.
not for jon 3 ga
With further analysis it looks like the "expired certification" is acceptable and a part of using certificates verified by external Cert entities. The expired certificate does not mean that the 'signing' is invalid in any way, just that the time frame for which this specific certificate was purchased to be valid has ended. Customers can still verify that these jars are in fact correctly signed by Redhat and that they have not been tampered with. The expired notice should be taken more as a warning to the end user that their code base is a little dated and nothing more. This is a necessary consequence of producing software that is supported for many years. The integrity of the process is not invalidated by the passage of time alone. Redhat products based on EAP 6 and beyond will have valid signing until 2036 but any of those components used after that time will still display the same notification about the certificate's intended support range. If customer's complain we should add some note to the FAQ, but this is low priority. Lowering priority of this issue.