RACF keystores and the KeyStore store() method
The update model for a JCERACFKS keystore is an update model. It was implemented in this way to avoid the effect described previously. If a change is made to an existing KeyStore entry, the existing version of the entry is disconnected from the keyring, the data for the new entry is added to the RACF® database, and then the new entry is connected to the keyring. Even if the update is a delete operation, whether deleteEntry() or keytool -delete, the data is not removed from the RACF database, it is only disconnected from the keyring represented by the KeyStore. To delete data from the RACF database, you must use the RACF utility RACDCERT.
- An entry with an expired certificate cannot be updated.
- An entry cannot be updated with an expired certificate.
- A certificate entry cannot be replaced with a key entry.
- A key entry cannot be replaced with a certificate entry.
- An entry cannot be updated unless the public key in the new version matches the public key in the existing version.
- Although a single certificate can be connected to many keyrings, there can be only one copy of it in the RACF database and it will be stored with only one label.
When the IBMJCE security provider can detect an update that will not be allowed by RACF, an exception is thrown when the KeyStore entry update is attempted. In some cases, the IBMJCE security provider can not predict that a RACF database update will be unsuccessful. One consequence of this is that a KeyStore update may be successful but an error or warning is reported during the store() operation.
- The previous version of the entry is disconnected from the keyring and the new version is not connected to the keyring.
- A certificate may be connected to the keyring using a label other than the one specified in the KeyStore update.
If there are unintended and undesired changes to a keystore, it might be necessary to reconnect or to update keyring entries using the RACF utility RACDCERT.