Issue Details (XML | Word | Printable)

Key: GLASSFISH-16473
Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: kumarjayanti
Reporter: kumarjayanti
Votes: 0
Watchers: 1

If you were logged in you would be able to see more operations.

Introduce a default CertStore in GlassFish that can be used by JSR196 CertStoreCallback

Created: 27/Apr/11 03:57 AM   Updated: 18/Oct/12 09:22 PM
Component/s: security
Affects Version/s: 4.0
Fix Version/s: future release

Time Tracking:
Not Specified

Tags: ee7ri_cleanup_deferred
Participants: kumarjayanti and Tom Mueller

 Description  « Hide

In Metro Security there is a usecase which requires that the Server store the Client Certificates and Vice-Versa. In such situations today we store the client certificate in the Server Truststore and similarly the Server Certificate is stored in the Client Truststore. Storing non-CA certificates in TrustStore is not a good idea from a security perspective.

The Java CertStore ( is an appropriate place to store such other-party non-CA certificates. The JSR196 CertStoreCallback in GlassFish however returns the GF truststore as the CertStore.

As a first step we would like to introduce a new keystore in the domain config that will be exposed as a CertStore via the JSR196 Default CallbackHandler in GlassFish. In a later release (if developers really ask for it) we could think of a CertStore configuration element under security-service. That would allow more flexibility on what the CertStore backend really is (for example an LDAP). Today Metro developers have the option of overriding the whole GlassFish JSR-196 CallbackHandler, and this would allow them to have any arbitary CertStore implementation.

kumarjayanti added a comment - 27/Apr/11 04:01 AM


Since Keystore contents are really not managed by Admin GUI/CLI today so adding a new keystore to the domain config does not cause any impact on Admin.

Impact on Cluster Replication Framework

The Cluster replication framework should apply the same rules for this new keystore (named certstore.jks) as it does for the GF keystore and truststore. IOW, instance config's should have a copy of the certstore.jks. And updates to certstore.jks on the DAS followed by touching domain.xml should cause the updated certstore.jks to be synced to the instances upon cluster restart.

Tom Mueller added a comment - 18/Oct/12 09:22 PM

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issue was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.