Problems with "use another repository" - SSL Handshake

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.

 Peter,

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.
There were two areas of difference between the SUCCESSFUL Client Hello from “jts_old” and the FAILED Client Hello from “jts_new.xyz.local”.  

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 ?

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.

Thanks
                Peter Turvey