Bug 1028463 - Check that keystore/truststore is accessible during JSSE configuration
Summary: Check that keystore/truststore is accessible during JSSE configuration
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Installer
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: CR3
: EAP 6.2.0
Assignee: Thomas Hauser
QA Contact: Petr Kremensky
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-08 14:09 UTC by Petr Kremensky
Modified: 2017-10-10 00:18 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-15 16:23:37 UTC
Type: Bug


Attachments (Terms of Use)

Description Petr Kremensky 2013-11-08 14:09:57 UTC
Description of problem:
 We should add some validation for Keystore/Truststore URL field on JSSE configuration screen.

Version-Release number of selected component (if applicable):
 EAP 6.2.0.ER7

How reproducible:
 Always

Steps to Reproduce:
 1. Run GUI installer. Go to Post-Install configuration screen using default values.
 2. Select to Add a security-domain.
 3. Press next on Security domain configuration screen to get to JSSE screen. 
 4. Check to "add jsse option" to show other values.
 5. Choose to either "Add keystore element", or "Add truststore element" option.
 6. Enter some values to password fields and keystore/truststore URL field.

Actual results:
 keystore/truststore URL field could contain any non empty value.

Expected results:
 We should verify that URL is accessible.

Comment 1 Thomas Hauser 2013-11-14 20:02:07 UTC
I was looking into this today. I was thinking of going beyond the "is it accessible" to actually checking the password given, to see if the keystore can be accessed through the Java KeyStore APIs. However, there seem to be a myriad of keystore types that the user could be using; 

Should I attempt to check all possible keystore types that the JRE is aware of (requires more work) 

Or should I just attempt with the type JKS, and warn if this fails? (This is already implemented and requires a little tuning, that's it, as well as localization)

Thanks,
Tom

Comment 2 Petr Kremensky 2013-11-15 14:46:52 UTC
Hi Tom,
I guess that checking of JKS is enough.
Petr

Comment 3 Thomas Hauser 2013-11-18 14:27:34 UTC
Check implemented. If validation fails, the user is warned that they may have entered the wrong password, but it cannot be guaranteed unless the keystore is of type JKS.

Comment 4 Petr Kremensky 2013-11-22 08:56:26 UTC
I found an issue while testing this. The "accessibility check" itself works fine, but I found a case which can walk-around it. Truststore validation is bypassed once I enter valid keystore element.

Way to reproduce:
 1. Go to Security-domain configuration screen with JSSE configuration.
Select to "Add jsse element", "Add keystore element" and "Add truststore element".
 2. Enter valid values into Keystore password and keystore URL so the accessibility check will pass.

Now you can enter arbitrary truststore password (must match) and Truststore URL, and validation will always pass. Once you un-select "Add keystore element" option the truststore validation works as expected.

Comment 6 Petr Kremensky 2013-11-27 08:26:50 UTC
Verified on EAP 6.2.0.CR.3.1 (re-spin caused by BZ1007833) installer.


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