idm.jksPurpose of new Keystore in IDM 4.72.

It looks like IDM 4.72 introduces a 4th potential keystore to manage.

 

Currently there are:

/opt/netiq/idm/apps/tomcat/conf/tomcat.ks
Private key of tomcat, eDir Tree pub key, OSP Pub key (Good)
/opt/netiq/idm/apps/osp/osp.jks
Private key of OSP, eDir tree key, and Tomcat pub key (Good)
/opt/netiq/idm/common/jre/lib/security/cacerts
Tomcat, OSP, eDir pub keys (good)

But there is also the idm.jks created, and referenced in the ism config file as:

DirectoryService/realms/jndi/params/KEYSTORE_PATH = /opt/netiq/idm/apps/tomcat/conf/idm.jks

 

Mine had the eDir tree CA and some GeoTrust CA public keys, which was a bit odd.  Adding in the Tomcat public key made my UA Integration Activities work (Had been failing before this).

 

So who makes this, why does it make it, what is it meant for?

 

I should note that OSP 6.3.1 for IDG 3.5.x now has a configupdade.sh that allows you to segment the keystores into app keystores seperate from the private key keystores.  But I am not talking about that here.  This is purely IDM.

  • Hi Geoff,

    the idea is for idm.jks to be the default truststore for custom CA certificates. You should have a

    -Djavax.net.ssl.trustStore=$CATALINA_BASE/conf/idm.jks

    in your /opt/netiq/idm/apps/tomcat/bin/setenv.sh.

    That way you don't have to worry about lib/security/cacerts during JRE updates.

    In the Authorizaion Code Grant Oauth flow the OAuthServlet does a back-channel request to OSP's token end-point. Since that is an HTTPS connection, it needs to validate the server cert. The OAuthServlet uses {com.netiq.idm.osp.ssl-keystore.file} as its truststore. By default, that points to tomcat.ks - tomcat's keystore. In a setup with proper 3rd party CA certificates it should probably point at idm.jks as well.

    Norbert