Question about keystore/truststore (wlp)
Posted: Sat Apr 06, 2019 4:29 am
Before I get to my questions, first little environment/setup:
We have infosphere server we're migrating to, it's using websphere liberty profile. We've asked support to get a certificate from a trusted certificate authority and update infosphere server/wlp. Our server had default install - the keystore (iis-server-keystore.p12) and truststore (iis-server-truststore.jks) are in /opt/IBM/InformationServer/wlp/usr/servers/iis/resources/security (call it 'defaultDir').
My limited (high level) understanding of what they needed to do would be:
- obtain a certificate (call it 'cert1') from the trusted certificate authority
- use the keytool command to import 'cert1' into keystore 'iis-server-keystore.p12'
- if the certificate from the trusted certificate authority doesn't exist in 'iis-server-truststore.jks' then import it into that keystore
It's taken a while for someone in support to focus on this (not sure of their experience level), I just looked at the server and it appears they did this:
Created new files in the 'defaultDir', the files are
- trustkey.jks (appears to be a new truststore)
- key.jks (appears to be the new certificate from the certificate authority)
They made quite a few modifications to server.xml (in ./wlp/usr/servers/iis)
- Removed variable references related to '<ssl' and '<keystore' and hard code references to sslProtocol, keystore/truststore location and hardcoded the passwords for the keystore/truststore.
My questions:
- This doesn't seem right to me, I don't know why they couldn't just update the existing keystore/truststore and why they needed to monkey with the server.xml file and hardcoded values (now clear text as opposed to encrypted values from a properties file)
- Not sure why they have keystore in jks format as opposed to p12 (pkcs12), is that an issue
- I have heirarchical ds jobs that have the truststore location/pw specified so that they can validate restful endpoints... they'd have to change to point to new truststore (this is just stmt)
- The server has about 500 ds jobs, I'm not sure if any of them would be affected by this change (other than heirarchical jobs). Is testing that I can: 1) get to server from windows DS client, 2) bring up launchpad and 3) spot test some jobs sufficient for testing their change?
Guess the net of it: I'm not sure of the implications of what they've done... doesn't seem right to me, but unless I can say it's wrong I doubt I can get them to change it.
I'm sorry for the long post, but hoping others a lot smarter than me can chime in with their thoughts/comments.
We have infosphere server we're migrating to, it's using websphere liberty profile. We've asked support to get a certificate from a trusted certificate authority and update infosphere server/wlp. Our server had default install - the keystore (iis-server-keystore.p12) and truststore (iis-server-truststore.jks) are in /opt/IBM/InformationServer/wlp/usr/servers/iis/resources/security (call it 'defaultDir').
My limited (high level) understanding of what they needed to do would be:
- obtain a certificate (call it 'cert1') from the trusted certificate authority
- use the keytool command to import 'cert1' into keystore 'iis-server-keystore.p12'
- if the certificate from the trusted certificate authority doesn't exist in 'iis-server-truststore.jks' then import it into that keystore
It's taken a while for someone in support to focus on this (not sure of their experience level), I just looked at the server and it appears they did this:
Created new files in the 'defaultDir', the files are
- trustkey.jks (appears to be a new truststore)
- key.jks (appears to be the new certificate from the certificate authority)
They made quite a few modifications to server.xml (in ./wlp/usr/servers/iis)
- Removed variable references related to '<ssl' and '<keystore' and hard code references to sslProtocol, keystore/truststore location and hardcoded the passwords for the keystore/truststore.
My questions:
- This doesn't seem right to me, I don't know why they couldn't just update the existing keystore/truststore and why they needed to monkey with the server.xml file and hardcoded values (now clear text as opposed to encrypted values from a properties file)
- Not sure why they have keystore in jks format as opposed to p12 (pkcs12), is that an issue
- I have heirarchical ds jobs that have the truststore location/pw specified so that they can validate restful endpoints... they'd have to change to point to new truststore (this is just stmt)
- The server has about 500 ds jobs, I'm not sure if any of them would be affected by this change (other than heirarchical jobs). Is testing that I can: 1) get to server from windows DS client, 2) bring up launchpad and 3) spot test some jobs sufficient for testing their change?
Guess the net of it: I'm not sure of the implications of what they've done... doesn't seem right to me, but unless I can say it's wrong I doubt I can get them to change it.
I'm sorry for the long post, but hoping others a lot smarter than me can chime in with their thoughts/comments.