*** Bug 1013805 has been marked as a duplicate of this bug. ***

The vault feature now generates a new keystore for the user. Thus, validation of the existing keystore no longer needs to happen.

Since the vault is now generated, this BZ is outdated. Perhaps just verify that Vault keystores are generated? :D

Hi Thomas,

how can I verify that the keystore is generated correctly? 

I tried to list the entries (`keytool -list -keystore vault.keystore`) in the generated keystore with the following error:

keytool error: java.io.IOException: Invalid keystore format

Hi Pavol,

I see this too, but only with the vault.keystore. The other keystore generated by the installer (overlord-saml.keystore) through identical means is fine: 

[[thauser] [09:49:51] configuration]$keytool -list -keystore overlord-saml.keystore
Enter keystore password:  

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

overlord, Dec 13, 2013, PrivateKeyEntry, 
Certificate fingerprint (SHA1): E6:6F:DF:18:00:BD:C4:69:64:B1:66:03:EA:3D:B4:FE:02:AB:E7:0D


I will investigate the issue further.

This is strange, because the vault is clearly functioning correctly; If it were not, the S-RAMP seeding would fail, and the server startup would fail almost immediately with vault resolution failures.

The keystore is fine, what is happening is that in creating a VaultSession with a given keystore, it is converted to the type JCEKS, while the default type for keytool is JKS:


[[thauser] [13:05:58] configuration]$keytool -list -keystore vault.keystore
keytool error: java.io.IOException: Invalid keystore format


[[thauser] [13:06:41] configuration]$keytool -list -keystore vault.keystore -storetype JCEKS
Enter keystore password:  

Keystore type: JCEKS
Keystore provider: SunJCE

Your keystore contains 1 entry

vault, Dec 16, 2013, SecretKeyEntry,

Great news! Thanks for investigating, Thomas. Verified in ER7 build.