It's all about the answers!

Ask a question

Problems with "use another repository" - SSL Handshake

Peter Turvey (995) | asked Jan 08 '19, 6:40 a.m.

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/jtsand”.
i.e. The new Jazz Team Server is using Fully Qualified Domain Name but the old one uses the shortened name format.

“stream1_oldserver” has a few components.
“stream1_newserver” hasn’t got any components yet.

I also have a workstation on the network with an Eclipse client v602 with connections to both “myuser@jts_old” and “”.

‘myuser’ is a Jazz Admin (defined in Active Directory)
‘myuser’ is using RTC Developer Tokens (defined in both “jts_old” and “jts_new”).
‘myuser’ has a role that has the permissions for all of the Source Control settings including “Replicate change sets” and “Save Components”.

I have a self-signed SSL certificate for “jts_old”  which is valid until 18th December 2019.
I have a self-signed SSL certificate for “” which is valid until 26th November 2019.
Both of these certificates are in the Trusted Root Certification Authorities store of my workstation.

And both of these certificates are also in the Trusted Root Certification Authorities store of “jts_old” and “”.

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

  1. Use the Eclipse client with connections to both jazz team servers.

  2. Create a repository workspace of “stream1_oldserver” and during the creation pick the option to “Use another repository” = ‘’

But I get an error when I try to save this repository workspace
Problems occurred running creating ‘myuser duplicate of stream1_oldserver workspace’.
Error invoking remote service at
https://old_server:9443/ccm/ : Received fatal alert: handshake failure.

The “.metadata.log” file contains a block of error messages each time I try and fail to create this repository workspace beginning with the :

Error invoking remote service at
https://old_server:9443/ccm/ : Received fatal alert: handshake failure.

then :
!STACK 0 Error invoking remote service at
https://old_server:9443/ccm/ : Received fatal alert: handshake failure.

Any help will be gratefully received.
Thanks Peter

The article I read was this one

Accepted answer

permanent link
Peter Turvey (995) | answered Jan 23 '19, 10:22 a.m.

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.
If more detail would be useful let me know but it was a bit of a hack.

Ralph Schoon selected this answer as the correct answer

2 other answers

permanent link
Ralph Schoon (58.1k23642) | answered Jan 08 '19, 8:32 a.m.
edited Jan 08 '19, 8:34 a.m.


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 for some surprising findings I had recently.

Ralph Schoon commented Jan 08 '19, 8:35 a.m.

Also make sure to use a 6.0.2 Eclipse client ideally running on the same latest Java version. 

Peter Turvey commented Jan 08 '19, 11:23 a.m.

Thanks for that Ralph. I've done a bit more investigation.
I'll post an update soon.
It seems to be something to do with the Ciphers being incompatible.

Peter Turvey commented Jan 09 '19, 5:28 a.m.

I must have typed too much to post another comment here. So I have used the "answer" box to continue the original question.

permanent link
Peter Turvey (995) | answered Jan 09 '19, 5:26 a.m.

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 “” to copy across components from “jts_old”, I did the opposite: i.e., created a Repository Workspace on “jts_old” to copy components from “”. 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 “” (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 “” 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 “” was followed by a successful TLS negotiation.  The server response from “” accepted the “jts_old”’s Client Hello offer of cipher TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and “supported group”/”named curve” secp256r1.
There were two areas of difference between the SUCCESSFUL Client Hello from “jts_old” and the FAILED Client Hello from “” 

Firstly, the 15 Cipher Suites listed in the Client Hellos output by “” and “jts_old” had some overlap but were not identical.

The “” 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 “” 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 ?

In an ideal world we don’t want to change anything on the old server, even if that were to mean temporarily “weakening” the new server so it could connect to the old server.

                Peter Turvey

Your answer

Register or to post your answer.