This post is part of a series exploring the unique aspects and capabilities of WebSphere Liberty when running on z/OS.
We'll also explore considerations when moving from WebSphere traditional on z/OS to Liberty on z/OS.
To start at the beginning, follow this link to the first post.
---------------
As we’ve discussed in earlier posts, Liberty will default a lot of the server configuration if you let it. Sometimes this has some odd side effects. If you care about security (and if you’re reading this blog you’re probably on z/OS so we’ll just assume the answer to that is ‘yes’) then you’ve probably got some server configuration that requires a keystore. Usually on z/OS those are kept in a SAF based keyring. However, on those platforms not lucky enough to have SAF and RACF (or an equivalent security product) you might use a file based keystore. And to try to make things easy for you, Liberty will set up a default keystore (with the id ‘defaultkeystore’).
If you don’t configure that default keystore, Liberty may configure it for you. And if the file it points to doesn’t exist Liberty will try to go ahead and create it for you. File based keystores have passwords. One thing the default keystore’s default configuration won’t include is (thank goodness) a default password. Default passwords are terrible because everybody forgets to change them.
Ok, so Liberty may, with no help from you, try to create a default key store that is a file based key store using a password that won’t default. That won’t work well. And so you’ll get CWPKI0819I which says that the default keystore wasn’t created because a password wasn’t specified for it.
Well, if you aren’t using the default keystore setup you won’t have configured it. So this is all fine. Liberty tried to be helpful but didn’t have a password to use so it gave up and just kicked out this message to let you know it tried.
If the message bothers you, well, you could configure a default keystore. You could even let Liberty set up a file based keystore that you don’t use, but you’d have to give it a password. It doesn’t really matter what it is because you don’t use it. But you’ll have a password right there in the server configuration (you can encrypt it, but still). Having a password, even one you don’t use, in the config will get flagged by somebody and force you to go to a meeting to explain yourself.
One approach I’ve seen taken is to set the password to ‘password’ which is so obviously awful a password that, maybe with a helpful comment, might keep the enforcers of password security at bay.
Or maybe just live with the message. It is informational, after all.