Problems with "use another repository" - SSL Handshake
I am trying to copy components from one Jazz Team Server (“jts_old”) to another one (“jts_new”). “jts_old” is a v6.0.2 jazz team server and “jts_new” is v6.0.6. “jts_old” and “jts_new” are both on the same network and use the same Active Directory for user authentication.
The Public URIs of the Jazz Team Servers are “https://jts_old:9443/jts” and “https://jts_new.xyz.local:9443/jts”.
“stream1_oldserver” has a few components.
I also have a workstation on the network with an Eclipse client v602 with connections to both “myuser@jts_old” and “myuser@jts_new.xyz.local”.
I have a self-signed SSL certificate for “jts_old” which is valid until 18th December 2019.
And both of these certificates are also in the Trusted Root Certification Authorities store of “jts_old” and “jts_new.xyz.local”. If I use a web-browser on my workstation I can access the Jazz Team Server web-sites and I do not have any certificate errors. i.e I get the padlock icon at the top of the page; not the red cross. Following info from a link I was given in an earlier thread my plan is
But I get an error when I try to save this repository workspace
The “.metadata.log” file contains a block of error messages each time I try and fail to create this repository workspace beginning with the :
Any help will be gratefully received. Thanks Peter
The article I read was this one
|
Accepted answer
|
Thanks for your reply Ralph. You can mark this thread as resolved now if you like. In the end we found a not entirely satisfactory work around by allowing some previously blocked Ciphers on the newer machine. So, effectively weakening the newer server to bring it into line with the older one.
Ralph Schoon selected this answer as the correct answer
|
2 other answers
Ralph Schoon (63.6k●3●36●46)
| answered Jan 08 '19, 8:32 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited Jan 08 '19, 8:34 a.m. Peter,
I don't know if this contributes, but I would suggest to make sure you know which Java versions are used where and ideally use the latest versions. See https://rsjazz.wordpress.com/2018/11/23/rtc-extensions-workshop-how-to-fix-ssl-protocol-errors-preventing-connection-to-jetty-debug-server/ for some surprising findings I had recently.
Comments Also make sure to use a 6.0.2 Eclipse client ideally running on the same latest Java version. Thanks for that Ralph. I've done a bit more investigation.
I must have typed too much to post another comment here. So I have used the "answer" box to continue the original question. |
|
CONTINUATION OF EARLIER POSTING : (i.e. this is not an answer) Following my earlier posting I have done a bit more investigation. I successfully created the workspace the “other way round”; that is instead of creating a Repository Workspace on “jts_new.xyz.local” to copy across components from “jts_old”, I did the opposite: i.e., created a Repository Workspace on “jts_old” to copy components from “jts_new.xyz.local”. This was a SUCCESS. I dumped the network traffic between the old and new jazz servers and compared the TLS behaviour when attempting to create a repository workspace on “jts_new.xyz.local” (FAIL) with the behaviour when creating a repository workspace on “jts_old” (SUCCESS). Both old and new servers produced TLS 1.0 “Client Hellos”. In the FAIL case, the TLS “Client Hello” from “jts_new.xyz.local” to “jts_old” was immediately followed by “jts_old” replying with “Fatal Alert – Handshake failure”
For the SUCCESS case, the Client Hello from “jts_old” to “jts_new.xyz.local” was followed by a successful TLS negotiation. The server response from “jts_new.xyz.local” accepted the “jts_old”’s Client Hello offer of cipher TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and “supported group”/”named curve” secp256r1.
Firstly, the 15 Cipher Suites listed in the Client Hellos output by “jts_new.xyz.local” and “jts_old” had some overlap but were not identical. The “jts_new.xyz.local” and “jts_old” Client Hellos both listed e.g., “TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA”; “jts_old” uniquely listed a number of …3DES… ciphers, whereas “jts_new.xyz.local” uniquely had some …AES_256… ciphers. As stated above for the SUCCESS case, the old server’s Client Hello to the new server offered TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. In the FAIL case too, the very same cipher appeared in the Client Hello sent by the new server to the old server. The other area of difference in the Client Hellos concerned the “supported groups” extension. The old server’s SUCCESSFUL Client Hello offered 11 supported groups to the new server … as stated above, secp256r1 (0x0017) was accepted by the new server. The new server’s Client Hello, rejected by the old server, offered only 4 supported groups, but this did include the same secp256r1 (0x0017).
In summary, both old and new servers generate a TLS 1.0 Client Hello that offers TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and secp256r1. This is accepted by the new server but rejected by the old one.
Do you have any ideas as to how we can proceed from here ?
Thanks
|
Your answer
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.