Really useful BPMN stats ....
https://<server>:<port>/teamworks/cs_instrumentation.lsw?userVisibleOnly=false
Showing posts with label bpc. Show all posts
Showing posts with label bpc. Show all posts
Friday, 31 May 2013
Monday, 5 November 2012
WebSphere RAL in BPM Advanced uses CACerts
I found this out when I enabled mutual authentication on the AppTarget cluster in a 4 cluster BPM advanced (751) setup...
I had enabled SSL client authentication for the inbound WC ports on my AppTarget JVM's (it's a long story so I wont go into why I did this).... this meant that anything sending a request to AppTargets WC ports would be asked for a client certificate.
RAL (Remote Artifact Loader) does just this... it's used by BPC explorer (which in my case was running on the Support Cluster) to gather info about a running BPC process running on the AppTarget cluster. (note: RAL traffic cant be pushed through a reverse proxy by design because all URI's are the same regardless of the server component being contacted.. weird design!).
So, in this scenario, with client auth enabled on AppTarget as described, any RAL requests would need to authenticate with a client certificate. So, you would be right to think this would already be taken care of by the fact that NodeDefaultKeyStore contains everything the RAL needs. However, you would be wrong.. it turns out that RAL uses CAcerts for this, and therefore, when you tried to get into about a running process (ir tried to start a new process for that matter) the request would fail.
I'm sure there's a way to force WAS to use the right keystores and truststores... but until I or someone else works out what is is.... you can copy the relevant keypairs around using the ikeycmd commands below
By the way, the Lombardi Process Centre also uses CACerts for trust when deploying to a Process Server. Ironically enough the Lombardi Process Server is better behaved and does not use CACerts when trusting the Process Centre web sending it's heartbeat.. it uses CellDefaultTruststore as one would expect.
I had enabled SSL client authentication for the inbound WC ports on my AppTarget JVM's (it's a long story so I wont go into why I did this).... this meant that anything sending a request to AppTargets WC ports would be asked for a client certificate.
RAL (Remote Artifact Loader) does just this... it's used by BPC explorer (which in my case was running on the Support Cluster) to gather info about a running BPC process running on the AppTarget cluster. (note: RAL traffic cant be pushed through a reverse proxy by design because all URI's are the same regardless of the server component being contacted.. weird design!).
So, in this scenario, with client auth enabled on AppTarget as described, any RAL requests would need to authenticate with a client certificate. So, you would be right to think this would already be taken care of by the fact that NodeDefaultKeyStore contains everything the RAL needs. However, you would be wrong.. it turns out that RAL uses CAcerts for this, and therefore, when you tried to get into about a running process (ir tried to start a new process for that matter) the request would fail.
I'm sure there's a way to force WAS to use the right keystores and truststores... but until I or someone else works out what is is.... you can copy the relevant keypairs around using the ikeycmd commands below
$WAS_HOME/java/jre/bin/ikeycmd -cert -export -label default -type pkcs12
-db $WAS_HOME/profiles/<profile>/config/cells/<cell>/nodes/<node>/key.p12
-pw <password> -target_pw <target password> -target_type jks -target
$WAS_HOME/java/jre/lib/security/cacerts
Subscribe to:
Posts (Atom)