How to cleanly solve "RSA token failed validation" between jazz applications ?
Kevin Ramer (4.5k●9●185●201)
| asked Sep 18 '14, 2:37 p.m.
edited Nov 11 '14, 4:15 p.m. by Stef van Dijk (2.0k●1●7●9)
As our journey using 100% WebSphere goes along, we see more things to chase down. I have another post asking SSL related questions ( https://jazz.net/forum/questions/163472/should-rfc1323-be-1-related-to-remote-host-closed-connection-during-handshake ) and this is similar but slightly different.
Scenario: 29 WebSphere 8.5.5.2 base profiles setup with a common SSO key [which works splendidly and has eased the discomfort of web users immensly ]. Those 29 profiles have from simple jts to full CLM ( jts, ccm, qm, rm, admin ) and points in between. As websphere admin we are seeing this message between the various profiles ( likely due to either JTS<>APP or APP<>APP connections [APP is one of the jazz applications ] ) 9/17/14 10:21:17:091 EDT] 000000c5 RSAPropagatio E JSAS0803E: The received admin RSA token failed validation. The exception message is: The certificate issued by CN=rtp-rtc1, OU=Root Certificate, OU=rtp-rtc1Node01Cell, OU=rtp-rtc1Node01, O=IBM, C=US is not trustedI've seen corrective suggestions also within the WebSphere logs saying add the signer certificate to the NodeDefaultTrustStore by doing the "Retrive from port". So, some simple math means I'd need to do this 812 times. =:o ( 28 times on each of the 29 profiles ). I cannot tell that the JSAS0803E is causing any issues, but as we do have an active PMR dealing with SSLHandshakeException, I'd like to purify the SSL environment. I do have separate SSL certificates from a central ( internal ) authority. The personal certificate from that authority is attached to the NodeDefaultSSLSettings for both the client and server certificates. Could those personal and root certificates from that CA replace the personal and root certificates in the "RSA token keystores" making the change much more manageable ? TIA Kevin
showing 5 of 6
show 1 more comments
|
Be the first one to answer this question!
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
Ok, this just in.... Using a tool I have I can connect to specific host/port and get a summary of the certificates ( if applicable ). Doing this for the SOAP port ( which appears to be associated with the RSA token(s) I get handed the certificate I would expect to get ! I.e. the assigned certificate for the host in the WebSphere profile.
These RSA tokens seem to be solely in use for "Administrative Authentication". There is an option to use the the "current application authentication" (in this case LTPA). It also seems possible to exchange keys betwixt servers.
What I'm not understanding is why one jazz server is making an "administrative" connection to another.
Just a thought. It appears that you're using self-signed certificates. Have you considered using your own CA? If every machine in your organization has your own CA as the root CA (not hard to do), all certificates signed by this CA will be trusted. OpenSSL comes in handy for such jobs.
These RSA keys are created when the websphere profile is created as part of the 'registerNode' This link ( albeit for z/os websphere ) describes:
http://www-01.ibm.com/support/knowledgecenter/SS7K4U_8.0.0/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/tsec_7config_admin_auth.html?cp=SS7K4U_8.0.0%2F2-8-32-2-6
http://www-01.ibm.com/support/knowledgecenter/SSCKBL_8.5.5/com.ibm.websphere.nd.doc/ae/tsec_7config_rsa_token_auth.html warns:
The Rivest Shamir Adleman (RSA) token uses certificates in a similar way that Secure Sockets Layer (SSL) uses them. However, the trust established for SSL and RSA are different, and RSA certificates should not use SSL certificates and vice versa. The SSL certificates can be used by pure clients, and when used for the RSA mechanism would allow the client to send an RSA token to the server. The RSA token authentication mechanism is purely for server-to-server requests and should not be used by pure clients. The way to prevent this is to control the certificates used by RSA in such as a way so they are never distributed to any clients. There is a different root certificate for RSA that prevents trust being established with clients who only need SSL certificates.
For what it's worth: Adding the exported signer certificate from one WAS profile an importing into Keystores / RSA keystores / NodeRSATruststore as signer certificate makes the JSAS0803E error disappear.