creating jks with pfx works in wm9.5 but not in wm10.3

, ,
1

I have an existing IS java service that is working in wm9.5 environment that creates a jks keystore from pfx files. However, recently when we migrate that same piece of code into wm10.3 environment, certain pfx files are not working in the wm10.3 environment. The error thrown is

Error java.security.KeyStoreException: Cannot store non-PrivateKeys: Service myPackage.services.utils:createUserJavaKeyStoreUI

However when I tried the same service with my own pfx file issued by GlobalSign, it works. The pfx files which didn’t work were issued by PostSignum. Do we need to add the root cert of PostSignum into the jvm truststore (cacerts)? Or could it be due to the different JVM implementation between 10.3 (Azul OpenJDK) and 9.5 (Oracle jvm)?

I’ve already tried adding the root certs for the PostSignum pfx into the jvm cacerts file. Is there something else that I can try to resolve this?

2

Hi,

while searching for “Cannot store non-PrivateKeys” I came across of the following post:

Please check if this might be helpful to you.

Regards,
Holger

3

After adding the root certificates for PostSignum into the default IS truststore, and restarting IS server, it works. This brought up another issue, why the reload of the default IS truststore did not work to load the root certs into memory but requires an IS restart. Any ideas?

4

Hi,

this is correct by design.

The certificate is associated with some settings in IS (i.e. the https port) which cannot be changed while the item is active.
Therefore you need to restart the IS to get these items reinitialized.

Regards,
Holger

5

But removing the needed root certs from the default truststore and only reload without having to restart IS works as expected, i.e. the previous error returned.

6

I need to correct the findings posted on Oct 17 above. It seems not only do I need to add the root certificates to the default IS truststore, but I also need to add the same certificates to the jvm cacerts file for it to work. Is there any way to to avoid this step but to just rely on the IS truststore?

7

Hi

you can create and use your own jks truststore instead of the default truststore.

Remember to specify the “-trustcacerts” option when importing intermediate CAs to your custom truststore.
With this option the cacerts file is automatically used as a base truststore.
Only certificates, which are not present there need to be imported into the truststore except for the server or client certificate itself, which should go to a keystore file instead.

Regards,
Holger