SSLHandshakeException: no cipher suites in common

31,897

Solution 1

javax.net.ssl.SSLHandshakeException: no cipher suites in common

This has two causes:

  1. The server doesn't have a private key and certificate, and possibly doesn't have a keystore at all. In such a case it can only use the insecure anonymous cipher suites, which are disabled by default, and should stay that way. So there is no cipher suite that it can agree to use with the client.

  2. Excessive restrictions on cipher suites imposed by client or server or both such that there can be no agreement.

Re your keystores and truststores, that all looks OK except that you are doing four import steps where you only need two. You don't need to import the server's certificate into the server's own truststore, or the client's certificate into the client's truststore. You only need this:

Server:

$ keytool -import -v -trustcacerts -alias clientkey -file ../client/client.cer -keystore cacerts.jks -keypass p@ssw0rd -storepass p@ssw0rd

Client:

$ keytool -import -v -trustcacerts -alias serverkey -file ../server/server.cer -keystore cacerts.jks -keypass changeit -storepass changeit

and you only need it because you're using a self-signed certificate. Simple solution: don't. Use a CA-signed certificate, which is trusted by the default truststore shipped with Java.

Solution 2

I got this error when setting up SSL on a Cassandra cluster. The problem turned out to be in the documentation of version 2.0 when describing generating the keys:

keytool -genkey -alias -keystore .keystore

It omits the specification of RSA as the algorithm, should be (see v1.2 docs):

keytool -genkey -alias -keyalg RSA -keystore .keystore

Share:
31,897
Astron
Author by

Astron

Updated on July 11, 2022

Comments

  • Astron
    Astron almost 2 years

    Followed the instructions here and recreated certificates that I previously incorrectly created. Something has changed as I am now seeing javax.net.ssl.SSLHandshakeException: no cipher suites in common on the server and javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure on the client. Instead of the errors this question

    The server is ClassFileServer.java and the respective client SSLSocketClientWithClientAuth.java

    Any tips on getting the two ends to play nicely, note that I am using localhost so I would assume the cipher capabilities are the same.


    Update:

    Here are the steps I have used to generate the files, I may be confusing the key and truststore.:

    On the server (following by this guide):

    $ keytool -genkey -alias serverkey -keyalg RSA -keypass p@ssw0rd -storepass p@ssw0rd -keystore keystore.jks

    $ keytool -export -alias serverkey -storepass p@ssw0rd -file server.cer -keystore keystore.jks

    $ keytool -import -v -trustcacerts -alias clientkey -file ../client/client.cer -keystore cacerts.jks -keypass p@ssw0rd -storepass p@ssw0rd

    On the client-side (by this guide):

    $ keytool -genkey -alias clientkey -keyalg RSA -keypass changeit -storepass changeit -keystore keystore.jks

    $ keytool -export -alias clientkey -storepass changeit -file client.cer -keystore keystore.jks

    $ keytool -import -v -trustcacerts -alias serverkey -file ../server/server.cer -keystore cacerts.jks -keypass changeit -storepass changeit

    Had to use another medium as the debugging exceeded the body limit of this site:

    Client debug error: http://pastebin.com/mHCmEqAk

    Server debug error: http://pastebin.com/YZbh7H8f

  • Astron
    Astron about 12 years
    I removed the extraneous entries and I am still receiving the same error. I tried importing the respective certs into the keystore per the comment here: stackoverflow.com/questions/9547980/…. I may still be confusing trust and keystores. Also, please note these are self-signed certificates.
  • user207421
    user207421 about 12 years
    @Astron (1) have you changed the code line 'ks.load(new FileInputStream("testkeys"), passphrase)' to load the respective keystores instead of 'testkeys', and (2) can you run the client with -Djavax.net.debug=ssl,handshake and edit the result into your post.
  • Astron
    Astron about 12 years
    The trustStore needs to be specified for client/server as they are using the default trustStore, causing failure. Using -Djavax.net.ssl.trustStore=/home/share/samples/sockets/clien‌​t/cacerts.jks -Djavax.net.ssl.trustStorePassword=changeit on the client and similar respective code for the server allows the session to complete. Strange that the application supports client authentication but does not have a trustStore provision in the client/server code. Thanks for the debugging info, that helped tremendously! Add the debugging recommendation to you answer.
  • user207421
    user207421 about 4 years
    This is all true but the problem is with the keystore, not the truststore.
  • Vineet Menon
    Vineet Menon about 4 years
    @user207421, you need to ask a separate question for your issue.