Monday, 4 December 2017

JKS Keystores - Pain with Passwords

I had a requirement to demonstrate how one could easily change the password of a JKS keystore that is being used by WebSphere Liberty Profile.

However, I kept seeing an annoying exception once I changed the password.

This was what I did: -

Create Keystore

/opt/ibm/WebSphere/Liberty/bin/securityUtility createSSLCertificate --server=defaultServer --password=passw0rd --validity=365

Created SSL certificate for server defaultServer. The certificate is created with CN=rhel7.uk.ibm.com,OU=defaultServer,O=ibm,C=us as the SubjectDN.

Add the following lines to the server.xml to enable SSL:

    <featureManager>
        <feature>ssl-1.0</feature>
    </featureManager>
    <keyStore id="defaultKeyStore" password="{xor}Lz4sLChvLTs=" />


I happily added the suggested lines to server.xml and all was well.

I then progressed: -

Validate Old Password

keytool -list -keystore /opt/ibm/WebSphere/Liberty/usr/servers/defaultServer/resources/security/key.jks -storepass passw0rd

Change the keystore password

keytool -storepasswd -new davehay -keystore /opt/ibm/WebSphere/Liberty/usr/servers/defaultServer/resources/security/key.jks -storepass passw0rd

Validate New Password

keytool -list -keystore /opt/ibm/WebSphere/Liberty/usr/servers/defaultServer/resources/security/key.jks -storepass davehay -v

This in effect changes the password FROM passw0rd TO davehay.

Generate the XOR Encoded version of the new password

/opt/ibm/WebSphere/Liberty/bin/securityUtility encode

which results in: -

{xor}Oz4pOjc+Jg==

which I entered into my server.xml

However, when I restarted Liberty and checked the messages.log file, I saw: -

[04/12/17 13:43:27:640 GMT] 0000001b com.ibm.ws.ssl.provider.AbstractJSSEProvider                 E CWPKI0813E: Error while trying to initialize the keymanager for the keystore [/opt/ibm/WebSphere/Liberty/usr/servers/defaultServer/resources/security/key.jks]. The private key password is not correct or the keystore has multiple private keys with different passwords.  This keystore can not be used for SSL.  Exception message is: [Cannot recover key].
[04/12/17 13:43:27:651 GMT] 0000001b com.ibm.ws.logging.internal.impl.IncidentImpl                I FFDC1015I: An FFDC Incident has been created: "java.security.UnrecoverableKeyException: Cannot recover key: invalid password for key in file '/opt/ibm/WebSphere/Liberty/usr/servers/defaultServer/resources/security/key.jks' com.ibm.ws.ssl.provider.IBMJSSEProvider getKeyTrustManagers" at ffdc_17.12.04_13.43.27.0.log
[04/12/17 13:43:27:684 GMT] 0000001b com.ibm.ws.logging.internal.impl.IncidentImpl                I FFDC1015I: An FFDC Incident has been created: "java.security.UnrecoverableKeyException: Cannot recover key: invalid password for key in file '/opt/ibm/WebSphere/Liberty/usr/servers/defaultServer/resources/security/key.jks' com.ibm.ws.ssl.config.SSLConfigManager initializeServerSSL" at ffdc_17.12.04_13.43.27.1.log


It took me a while, and then I realised what was going on.

When I created the keystore, the process also created a public/private key pair, which it stored within the … KEY STORE, using the SAME password id est passw0rd.

When I changed the password of the KEY STORE, I did NOT also change the password of the KEY itself.

So I updated my process: -

Change to new Password - storepass

keytool -storepasswd -new davehay -keystore /opt/ibm/WebSphere/Liberty/usr/servers/defaultServer/resources/security/key.jks -storepass passw0rd

Change to new Password - keypass

keytool -keypasswd -all -new davehay -keystore /opt/ibm/WebSphere/Liberty/usr/servers/defaultServer/resources/security/key.jks -keypass passw0rd -storepass davehay

Note that I'm using the OLD keystore password - passw0rd - as the OLD key password whilst setting the NEW key password with the NEW keystore password.

Simple eh ?

Validate New Password

keytool -list -keystore /opt/ibm/WebSphere/Liberty/usr/servers/defaultServer/resources/security/key.jks -storepass davehay -v

In summary, there's a KEYSTORE password and a KEY password; if you want them to be the same, you need to change BOTH.

Otherwise, I'd have to configure Liberty for TWO different passwords.

Easy when you know how :-)


No comments:

Yay, VMware Fusion and macOS Big Sur - no longer "NAT good friends" - forgive the double negative and the terrible pun ...

After macOS 11 Big Sur was released in 2020, VMware updated their Fusion product to v12 and, sadly, managed to break Network Address Trans...