JDK-8133741 : Unable to setup ECDHE_ECDSA cipher suites
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 8u51
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2015-08-17
  • Updated: 2015-10-07
  • Resolved: 2015-10-07
Related Reports
Relates :  
JDK-8133816 - Display server side enabled ciphersuites for debug mode
Relates :  
JDK-8136442 - Don't tie Certificate signature algorithms to ciphersuites
Description
We are are unable to setup ECDHE_ECDSA cipher suites on weblogic 12.1.3
server using Java 8u51.  Although they can use the generated EC keys and
certificates using openssl or nginx with the above cipher type they have been
unable to get it working on weblogic.  The same error appears in the logs but
I do not understand why it appears since the cipher used on the server is one
of the ones being asked by a browser:

ExecuteThread: '0' for queue: 'weblogic.socket.Muxer', fatal: engine already
closed.  Rethrowing javax.net.ssl.SSLHandshakeException: no cipher suites in
common
<Jul 27, 2015 1:02:16 PM EDT> <Debug> <SecuritySSL> <BEA-000000>
<[Thread[ExecuteThread: '0' for queue: 'weblogic.socket.Muxer',5,Thread Group
 for Queue: 'weblogic.socket.Muxer']]weblogic.security.SSL.jsseadapter:
SSLENGINE: Exception occurred during SSLEngine.wrap(ByteBuffer,ByteBuffer).
javax.net.ssl.SSLHandshakeException: no cipher suites in common
Comments
Got help from Dev engineer on this one. Turns out to be an issue with the signature algorithms used on the submitter's certs. Per TLS ECC spec [section 5.3, RFC 4492], [0] ECDHE_ECDSA Certificate MUST contain an ECDSA-capable public key. It MUST be signed with ECDSA. RSA signed EC-key certs cannot be used for ECDHE_ECDSA ciphersuites. The restrictions on the algorithm used to sign certificates are relaxed in TLS 1.2 [RFC 5246]. Certificate signature algorithms are no longer tied to cipher suites. Such restrictions have not been removed in the JDK implementation yet. As the TLS vendor's implementation of RFC 4492 are widely deployed, it's better to use ECDSA signed cert for ECDHE_ECDSA. . [0] https://tools.ietf.org/html/rfc4492#section-5.3 JDK-8136442 will take steps to improve the JDK in this area.
07-10-2015
For a ciphersuite that depends on key material being available, the KeyManager must return a valid alias. A null means that there is no material available, and thus the ciphersuite can't be used. You'll need to check the KeyManager code and find out why the "available" keys aren't valid. Most likely the KeyStore being used isn't the one they thought it was. We see that a lot.
01-09-2015
interesting part of instrumented logs can be found with this output : %% Initialized: [Session-1, SSL_NULL_WITH_NULL_NULL] trySetCipherSuite for :TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 setupPrivateKeyAndChain: algorithm:EC_EC setupPrivateKeyAndChain: alias was null trySetCipherSuite for :TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 fetching RSA certs for K_ECDHE_RSA setupPrivateKeyAndChain: algorithm:RSA setupPrivateKeyAndChain: alias was null trySetCipherSuite for :TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 setupPrivateKeyAndChain: algorithm:RSA setupPrivateKeyAndChain: alias was null trySetCipherSuite for :TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA setupPrivateKeyAndChain: algorithm:EC_EC setupPrivateKeyAndChain: alias was null trySetCipherSuite for :TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA fetching RSA certs for K_ECDHE_RSA setupPrivateKeyAndChain: algorithm:RSA setupPrivateKeyAndChain: alias was null trySetCipherSuite for :TLS_DHE_RSA_WITH_AES_128_CBC_SHA setupPrivateKeyAndChain: algorithm:RSA setupPrivateKeyAndChain: alias was null trySetCipherSuite for :TLS_RSA_WITH_AES_128_GCM_SHA256 setupPrivateKeyAndChain: algorithm:RSA setupPrivateKeyAndChain: alias was null trySetCipherSuite for :TLS_RSA_WITH_AES_128_CBC_SHA setupPrivateKeyAndChain: algorithm:RSA setupPrivateKeyAndChain: alias was null trySetCipherSuite for :SSL_RSA_WITH_3DES_EDE_CBC_SHA setupPrivateKeyAndChain: algorithm:RSA setupPrivateKeyAndChain: alias was null Server handshake: CipherSuites attempted: [] ExecuteThread: '1' for queue: 'weblogic.socket.Muxer', fatal error: 40: no cipher suites in common Our setupPrivateKeyAndChain method is cycling through selected keyExchange algorithms and is not satisfied with any of them. The method has this responsibility : == * Retrieve the server key and certificate for the specified algorithm * from the KeyManager and set the instance variables. == The method consists of this code : X509ExtendedKeyManager km = sslContext.getX509KeyManager(); String alias; if (conn != null) { alias = km.chooseServerAlias(algorithm, null, conn); } else { alias = km.chooseEngineServerAlias(algorithm, null, engine); } if (alias == null) { debugPrint("setupPrivateKeyAndChain: alias was null"); return false; } I don't think a null alias should be returned for the valid case. Some mismatch is going on here. Need to check if weblogic is using a customised X509ExtendedKeyManager.
01-09-2015
instrumented debug patch
01-09-2015