Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1149186

Summary: Cannot reuse existing client keystores
Product: [Retired] JBoss BPMS Platform 6 Reporter: Tomas Livora <tlivora>
Component: InstallerAssignee: Miroslav Sochurek <msochure>
Status: CLOSED EOL QA Contact: Dominik Hanak <dhanak>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1.0CC: kverlaen
Target Milestone: ER2   
Target Release: 6.1.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-27 20:11:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Installation Log none

Description Tomas Livora 2014-10-03 12:50:10 UTC
Created attachment 943712 [details]
Installation Log

Description of problem:
In version 6.1.0 a new feature has been added to the 'Configure JMS SSL keystores' page. It is now possible to import the server certificate into an existing client keystore. The problem is that this feature does not work at all and I am also not sure what the correct behavior should be.

Version-Release number of selected component (if applicable):
6.1.0 DR3

Steps to Reproduce:
1. Run the installer, generate new client keystores and finish the installation.
2. Run the installer again and try to reuse the generated client keystores.

Actual results:
The installation fails. See the attached installation log.

Expected results:
The installer should either allow to select the client keystore file and import the server certificate into it or it should be possible to select the whole folder containing multiple client keystores and import the certificate into all of them.

Comment 1 Thomas Hauser 2014-10-03 15:21:40 UTC
The feature is meant to allow the user to specify a specific keystore to use instead of having the installer generate all of them; If we allow the user to specify a directory containing keystores, I suppose we can just assume the same password for all and throw an error. I'll fix the feature and also add in the ability to specify a directory instead of just a singular keystore.

Comment 2 Tomas Livora 2014-11-10 08:36:40 UTC
If I understand it correctly, now it is only possible to enter a directory where client keystores are located and it does not matter how many of them are there. And it is not possible to specify a single file. If you want to do that, you have to select its directory. Am I right?

In that case, I would recommend to change some of the labels like this:

1) "Import the server certificate into existing client keystores" instead of "Import the server certificate into an existing keystore"

2) "Provide the path to the existing client keystores directory" instead of "Provide the path to the existing keystore"

I would also recommend to mention this new feature in the description at the beginning of the page.

Comment 3 Thomas Hauser 2014-11-10 21:09:13 UTC
You can specify a single file. However, testing with the DR4 installer resulted in an error, which I have fixed for ER1. There are a few scenarios for this screen now:

1) User generates keystores in default directory
2) User indicates a non-existing directory into which to generate a single new keystore
3) User chooses an existing directory containing any number of keystores which should all have the server certificate imported into them
4) User chooses a single keystore file to import the server certificate into

I have updated the labels and error messages to be more clear about this.

Comment 4 Tomas Livora 2014-11-14 15:44:47 UTC
Verified on BPMS 6.1.0 ER2

However, there is a typo that needs to be fixed in the newly added paragraph which contains description of reusing existing client keystores. There should be 'provided' instead of 'provded' on the third line.

Comment 5 Thomas Hauser 2014-11-14 15:55:26 UTC
Corrected the typo going forward. :(