Replacement for spi-truststore-file-* options?

[bodograumann]

In keycloak 24 it seems, the spi-truststore-file-* options are deprecated.
The documentation seems to read, that pkcs12 truststores are now discovered in and read from the config directory, but are "expected" to be unencrypted.
How can keycloak now handle encrypted pkcs12 stores, that were previously configured with an spi-truststore-file-password option?

[shawkins]

How can keycloak now handle encrypted pkcs12 stores, that were previously configured with an spi-truststore-file-password option?

I don't think a forward looking replacement was considered for this. Can you describe why encryption is required for your public certs? Or do you have a pkcs12 file containing both public and private material?

[shawkins]

Yes there does seem to be usability issues with passwordless keystores. Openssl can create one:

openssl pkcs12 -export -keypbe NONE -certpbe NONE -nomac -passout pass: -out keyStore.p12 -nokeys -in cert.pem

However java will not create an entry in the keystore for that certificate when it is read in, it will instead just throw it away. Apperantly that is only supported on much later versions of openssl, and even then may not be flawless yet - openssl/openssl#22215

Programatically you can create a passwordless keystore in java by setting the system property keystore.pkcs12.certProtectionAlgorithm to NONE. Similarly you can create a passwordless keystore through keytool with:

keytool -importcert -keystore keyStore.p12 -alias x -file cert.pem -noprompt

But it also requires updating jre/conf/security/java.security to include:

keystore.pkcs12.certProtectionAlgorithm=NONE
keystore.pkcs12.macAlgorithm=NONE

Or you can combine the two approaches - create the passwordless keystore using openssl, then import the aliased cert entry with keytool without changing the java.security properties. As long as you are on a newer version of keytool (17+) it will then not require a password.

[kurellajunior]

Hi (same team, I am)
As long as creating/dealing with password-free key stores is tricky (i.e. not desired) it might be good to remain able to read in protected key stores in the first place.
as long as we are in dockerized environments it might be OK to tamper with global java settings. But can we foresee the side effects of those two settings set to NONE?
Is there a pressing need to remove that feature from Keycloak?
~~Jan

[shawkins]

But can we foresee the side effects of those two settings set to NONE?

For creating just truststores? It disables integrety checking and certificate encryption. As long as you are dealing with public certs that should be fine, but I realize that it may not be desirable to change the java.security file in general. It's probably preferable to combine the tools or use a newer version of openssl.

Is there a pressing need to remove that feature from Keycloak?

Beyond consolidating some of the truststore handling, the primary drivers for this direction were to move away from JKS and to add support for pem files. Since pem are not encrypted, and it's not necessary to encrypt something that is strictly a truststore, passwordless pkcs12 was added as well.

cc @vmuzikar @ahus1 @abstractj

[kurellajunior]

If I understand that right, with one of the next versions we would not need a keystore at all, but could use the pem-files with our certificates directly?
Then at least our migration path for the Keycloak library would be clear.

[shawkins]

Yes just using pem files would be a simple option moving forward.