It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,884
×6,034

question asked: Apr 24 '14, 2:22 p.m.
question was seen: 5,554 times
last updated: Apr 28 '14, 4:10 p.m.

Related questions

[closed] CertificateException Exception on cross-server delivery

0
Kevin Ramer (4.5k●9●186●201) | asked Apr 24 '14, 2:22 p.m.
closed Apr 28 '14, 4:10 p.m.
User reports that after we jazz admins got our new SSL certificates that the delivery to a remove component fails with the following:

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

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Abraham Sweiss (2.4k●13●31) | answered Apr 24 '14, 3:26 p.m.
Hi Kevin,

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
Kevin Ramer commented Apr 24 '14, 3:32 p.m.

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.

Abraham Sweiss commented Apr 24 '14, 3:47 p.m.
  1. Were the new certs added to both the jts and ccm key stores?
  2. 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

Kevin Ramer commented Apr 25 '14, 8:45 a.m.

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.

Abraham Sweiss commented Apr 25 '14, 10:59 a.m.

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.

0
permanent link
Kevin Ramer (4.5k●9●186●201) | answered Apr 26 '14, 5:30 a.m.
I removed the OSLC Friends and Consumers from each end of this relatiionship and re-established them.  User reports that now the distributed SCM is again working.