[closed] CertificateException Exception on cross-server delivery
Could not initialize component sync contextError invoking remote service at https://rtc6:9443/jazz/: java.security.cert.CertificateException: Certificate doesn't match, expected a 37 8e 7c ce 9e ec [SNIP] 8 d4 66 cd but server presented 63 c5 12 [SNIP] e5 2e 47
The "63 c5 12" is part of the new certificate. Now, I know that the RTC client hangs on to SSL certificates and I've as yet to confirm that submitter can and has connected RTC client to both ends of this deliver equation.
I'm hoping it's as simple as that as I can find no errors or warnings in either RTC server's log file. Nor can I find what look to be stashed certificates lying about in the home directory of the ID running our applications or the install location of the source end server.
Any suggestions?
The question has been closed for the following reason: "Self answered" by yzwkzfn Apr 28 '14, 4:10 p.m.
2 answers
If this is a WAS install I would clean out the WSTemp and Temp directories of the profile where CLM is installed. This will require a server stop/restart.
The other thing I would look at is to ensure the signer (public) cert has been copied to the trust stores of the other servers which connect to the server who's certs have been updated.
And if IHS is in the topology, make sure the plugin key store has been updated with the signer certs
Comments
The only involvement with WAS is the JTS for the source end of the delivery pair. The rtc6 is Tomcat hosted. No IHS.
I've never had to add any certificates to trust ( exception ldap host certificate ) to much of anything. I do know how to inject certificates into $JAVA_HOME/lib/security/cacerts but that doesn't seem applicable given the history.
- Were the new certs added to both the jts and ccm key stores?
- Was the jts wstemp and temp directories cleared out? Just want to eliminate any unexpected behavior in case the old cert is still referenced in the cache.
3. I take it the client is getting the error within the eclipse RTC client. Have they tried creating a new workspace to see if that resolves the issue
I looked in the WebSphere default trustStore. The key as "expected" is not in the WebSphere keystore. I just examined the old keystore of the rtc6 and its signature matches the "expected" signature as reported by the user. Only the JTS is within WAS for this scenario, the RTC applications are Tomcat hosted, one in the WAS'd JTS the other a separate JTS (also Tomcat).
Does friending an application squirrel the key for the remote application ? My thought is to unfriend the two and recreate if that is the case.
unfriending and refriending should not make a difference but can not hurt.
However if the certs were updated in RTC, then the certs should be added to the WAS key/trust stores. This will ensure that RTC and jts can communicate with each other over https.