Bug 757804 - signer certificate expired in signed .jars in JON 3 CR2
Summary: signer certificate expired in signed .jars in JON 3 CR2
Status: ON_DEV
Alias: None
Product: RHQ Project
Classification: Other
Component: Core Server   
(Show other bugs)
Version: 4.2
Hardware: Unspecified Unspecified
low vote
Target Milestone: ---
: ---
Assignee: Simeon Pinder
QA Contact: Mike Foley
Depends On:
TreeView+ depends on / blocked
Reported: 2011-11-28 18:28 UTC by Mike Foley
Modified: 2011-12-16 16:51 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
details of jarsigner -verbose -cert (50.69 KB, text/plain)
2011-11-28 18:29 UTC, Mike Foley
no flags Details

Description Mike Foley 2011-11-28 18:28:06 UTC
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 
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

Comment 1 Mike Foley 2011-11-28 18:29:14 UTC
Created attachment 537591 [details]
details of jarsigner -verbose -cert

Comment 2 Simeon Pinder 2011-11-28 22:51:22 UTC
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.

Comment 3 Simeon Pinder 2011-11-28 23:18:02 UTC
See this thread on the brew mailing list: 

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.

Comment 4 Mike Foley 2011-11-30 15:47:19 UTC
not for jon 3 ga

Comment 5 Simeon Pinder 2011-12-16 16:51:00 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.