My client(java 1.8) is trying to set up a TLS connection with a remote server using TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
as cipher suite.
But throws an java.lang.IllegalStateException
HashAlgorithm.sha256(4) is not being tracked
The used crypto material used shall be based on a brainpool curve. The client uses BouncyCastleJsseProvider crypto provider. Following system properties have been set
System.setProperty("jdk.tls.ephemeralDHKeySize", "2048");
System.setProperty("jdk.tls.server.defaultDHEParameters",
"{ " + "FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 "
+ "29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD "
+ "EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 "
+ "E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED "
+ "EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D "
+ "C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F "
+ "83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D "
+ "670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B "
+ "E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 "
+ "DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 "
+ "15728E5A 8AACAA68 FFFFFFFF FFFFFFFF, 2}");
System.setProperty("jdk.tls.namedGroups", "brainpoolp256r1,brainpoolP384r1");
For debugging purposes the handshake has been sniffed with WireShark:
.
It can be seen in the screenshot that the client is requesting the correct cipher suite.
Client Hello - Signature hash algorithms:
The server accepts the suite and the handshake is handled up until the client generates server certificates verification message, which leads into the previously mentioned java.lang.IllegalStateException. Since the exception message reads 'HashAlgorithm.sha256(4) is not being tracked'. I am assuming that, for some reason, the client does not use sha384 for the generation of 'certificate Verify' but sha256.
I am assuming that I might have missed some client configuration step, to make sha384 available. Sadly I've not found a hint which could provide me with some helpful information. Can someone reach me a helping hand in that question?
P.S. If TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
is chosen instead of TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
the handshake operation is successful, but this suite does not make use of sha384 for calculating the contents of the certificate verification message.
P.S.S Since it seems that the client does not provide Signature Hash algorithms for (sha256(4), ecdsa(3)) and (sha384(5), ecdsa(3)) as stated in https://www.rfc-editor.org/rfc/rfc5246#section-7.4.1.4.1, is there some option to programmatically provide support of these algorithms?
P.S.S.S. Screenshot of Server Certificate Request WireShark protocol added.