JBoss Remoting
  1. JBoss Remoting
  2. JBREM-470

javax.net.ssl.SSLException: No available certificate corresponds to the SSL cipher suites

    Details

    • Type: Bug Bug
    • Status: Closed Closed (View Workflow)
    • Priority: Blocker Blocker
    • Resolution: Done
    • Affects Version/s: 2.0.0.Beta1
    • Fix Version/s: 2.0.0.Beta2 (Boon)
    • Component/s: None
    • Security Level: Public (Everyone can see)
    • Labels:
      None
    • Similar Issues:
      Show 10 results 

      Issue Links

        Activity

        Hide
        Tom Elrod
        added a comment -

        Think this might be due to JBREM-464 (which has been fixed). If issue still remains, do you have a remoting test case that demonstrates the issue?

        Show
        Tom Elrod
        added a comment - Think this might be due to JBREM-464 (which has been fixed). If issue still remains, do you have a remoting test case that demonstrates the issue?
        Hide
        Ovidiu Feodorov
        added a comment -

        This is how you replicate the exception:

        1. Update the jms head from CVS
        2. Set the JBOSS_HOME to point to the JBoss installation to test with. It should 4.0.4.GA, 4.0.3 and lower won't work.
        3. cd jboss-head/jms/tests/smoke
        4. ant ssh

        You will see something similar to:

        ......
        identify:
        [echo] ############################################################################
        [echo] # Running the SECURE SOCKET example #
        [echo] ############################################################################
        [echo] The queue: SmokeTestQueue

        sanity-check:

        init:
        [mkdir] Created dir: C:\work\src\cvs\jboss-head\jms\docs\examples\secure-socket\output
        [mkdir] Created dir: C:\work\src\cvs\jboss-head\jms\docs\examples\common\output

        compile:
        [javac] Compiling 2 source files to C:\work\src\cvs\jboss-head\jms\docs\examples\common\output
        [javac] Compiling 1 source file to C:\work\src\cvs\jboss-head\jms\docs\examples\secure-socket\output

        deploy:
        [copy] Copying 1 file to C:\work\src\jboss-4.0.4.GA-src\build\output\jboss-4.0.4.GA\server\messaging-smoke-test\deploy\jboss-messaging.sar
        [copy] Copying 1 file to C:\work\src\jboss-4.0.4.GA-src\build\output\jboss-4.0.4.GA\server\messaging-smoke-test\deploy

        sleep:
        [echo] Sleeping for 10 seconds ...

        run:
        [java] Queue /queue/SmokeTestQueue exists
        [java] 21:51:06,987 ERROR @SocketServerInvoker#0-2941 [SSLSocketServerInvoker] SSLServerSocket error
        [java] javax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled.
        [java] at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303)
        [java] at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253)
        [java] at org.jboss.remoting.transport.socket.SocketServerInvoker.run(SocketServerInvoker.java:383)
        [java] at java.lang.Thread.run(Thread.java:595)
        [java] The message was successfully sent to the SmokeTestQueue queue
        [java] 21:51:08,880 ERROR @SocketServerInvoker#0-2942 [SSLSocketServerInvoker] SSLServerSocket error
        [java] javax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled.
        [java] at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303)
        [java] at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253)
        [java] at org.jboss.remoting.transport.socket.SocketServerInvoker.run(SocketServerInvoker.java:383)
        [java] at java.lang.Thread.run(Thread.java:595)
        [java] Received message: Hello!
        [java] The example connected to JBoss Messaging version 1.0.1.CR2 (1.0)

        [java] #####################
        [java] ### SUCCESS! ###
        [java] #####################
        .....

        Show
        Ovidiu Feodorov
        added a comment - This is how you replicate the exception: 1. Update the jms head from CVS 2. Set the JBOSS_HOME to point to the JBoss installation to test with. It should 4.0.4.GA, 4.0.3 and lower won't work. 3. cd jboss-head/jms/tests/smoke 4. ant ssh You will see something similar to: ...... identify: [echo] ############################################################################ [echo] # Running the SECURE SOCKET example # [echo] ############################################################################ [echo] The queue: SmokeTestQueue sanity-check: init: [mkdir] Created dir: C:\work\src\cvs\jboss-head\jms\docs\examples\secure-socket\output [mkdir] Created dir: C:\work\src\cvs\jboss-head\jms\docs\examples\common\output compile: [javac] Compiling 2 source files to C:\work\src\cvs\jboss-head\jms\docs\examples\common\output [javac] Compiling 1 source file to C:\work\src\cvs\jboss-head\jms\docs\examples\secure-socket\output deploy: [copy] Copying 1 file to C:\work\src\jboss-4.0.4.GA-src\build\output\jboss-4.0.4.GA\server\messaging-smoke-test\deploy\jboss-messaging.sar [copy] Copying 1 file to C:\work\src\jboss-4.0.4.GA-src\build\output\jboss-4.0.4.GA\server\messaging-smoke-test\deploy sleep: [echo] Sleeping for 10 seconds ... run: [java] Queue /queue/SmokeTestQueue exists [java] 21:51:06,987 ERROR @SocketServerInvoker#0-2941 [SSLSocketServerInvoker] SSLServerSocket error [java] javax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled. [java] at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303) [java] at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253) [java] at org.jboss.remoting.transport.socket.SocketServerInvoker.run(SocketServerInvoker.java:383) [java] at java.lang.Thread.run(Thread.java:595) [java] The message was successfully sent to the SmokeTestQueue queue [java] 21:51:08,880 ERROR @SocketServerInvoker#0-2942 [SSLSocketServerInvoker] SSLServerSocket error [java] javax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled. [java] at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303) [java] at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253) [java] at org.jboss.remoting.transport.socket.SocketServerInvoker.run(SocketServerInvoker.java:383) [java] at java.lang.Thread.run(Thread.java:595) [java] Received message: Hello! [java] The example connected to JBoss Messaging version 1.0.1.CR2 (1.0) [java] ##################### [java] ### SUCCESS! ### [java] ##################### .....
        Hide
        Ovidiu Feodorov
        added a comment -

        Made it blocker as it's the only issue that holds Messaging 1.0.1.CR2

        Show
        Ovidiu Feodorov
        added a comment - Made it blocker as it's the only issue that holds Messaging 1.0.1.CR2
        Hide
        Tom Elrod
        added a comment -

        Test case: org.jboss.test.remoting.transport.socket.ssl.builder.SSLSocketInvokerTestCase

        Show
        Tom Elrod
        added a comment - Test case: org.jboss.test.remoting.transport.socket.ssl.builder.SSLSocketInvokerTestCase
        Hide
        Tom Elrod
        added a comment -

        The real issue with this case is that is using push callbacks without having both keystore and truststore on both the client and the server. With traditional push callbacks, a new physical network connection is made from the server instance (via the callback client) to the client instance (via the callback connector). If using SSL in this traditional case, will need to setup ssl config just as is done with normal client to server invocations (e.g. having keystore on the server and truststore on the client).

        One way to avoid this would be to let remoting take care of managing callbacks internally so would poll internally for uni-directional transports, but emulate push callback behavior (see JBREM-363 for more info on this behavior).

        However, if really want to have true push callbacks when using ssl, but not be forced to place keystores on the client instance, is now possible (per this issue) to have the callback client (on the server instance) to use the ssl client mode and for the callback connector (on the client instance) to turn off client mode. This will allow the client to send the ssl info need to complete the ssl handshake (thus leaving keystore on server instance and truststore on client instance).

        How to configure:
        To do this, need to add the key of 'useClientMode' and value of 'true' to the configuration map passed to the callback Connector constructor (see org.jboss.test.remoting.transport.socket.ssl.builder.SSLSocketInvokerTestClient for example).

        How it works:
        By setting the 'useClientMode' value to 'true' within the callback Connector, the SSLServerSocket it uses to receive network communication will have it's mode set to client mode. On the server side, when a push callback client is created internally, it will check to see if the server invoker that owns it has a configuration setting for 'serverSocketFactory'. If it does, it will then check to see if the server socket factory configured is based of SSLSocketBuilder. If this is also true, it will create a SSLSocketFactory wrapper around the same SSLSocketBuilder instance and set the client mode for SSLSockets created to be false.

        Important notes:
        This has currently only been tested to work with 'sslsocket' transport. Other transports may work, but have not been tested for this behavior and probably won't work (see JBREM-491 for status on implementing within all other transports). Also, this behavior will only be valid when using configuration for the 'serverSocketFactory' in the remoting server where the value for this configuration property is an ObjectName referencing an instance of the org.jboss.remoting.security.SSLServerSocketFactoryServiceMBean (otherwise no way to get a reference to the SSLSocketBuilder). An example of the server configuration needed can be found within org.jboss.test.remoting.transport.socket.ssl.builder.SSLSocketInvokerTestServer.

        Show
        Tom Elrod
        added a comment - The real issue with this case is that is using push callbacks without having both keystore and truststore on both the client and the server. With traditional push callbacks, a new physical network connection is made from the server instance (via the callback client) to the client instance (via the callback connector). If using SSL in this traditional case, will need to setup ssl config just as is done with normal client to server invocations (e.g. having keystore on the server and truststore on the client). One way to avoid this would be to let remoting take care of managing callbacks internally so would poll internally for uni-directional transports, but emulate push callback behavior (see JBREM-363 for more info on this behavior). However, if really want to have true push callbacks when using ssl, but not be forced to place keystores on the client instance, is now possible (per this issue) to have the callback client (on the server instance) to use the ssl client mode and for the callback connector (on the client instance) to turn off client mode. This will allow the client to send the ssl info need to complete the ssl handshake (thus leaving keystore on server instance and truststore on client instance). How to configure: To do this, need to add the key of 'useClientMode' and value of 'true' to the configuration map passed to the callback Connector constructor (see org.jboss.test.remoting.transport.socket.ssl.builder.SSLSocketInvokerTestClient for example). How it works: By setting the 'useClientMode' value to 'true' within the callback Connector, the SSLServerSocket it uses to receive network communication will have it's mode set to client mode. On the server side, when a push callback client is created internally, it will check to see if the server invoker that owns it has a configuration setting for 'serverSocketFactory'. If it does, it will then check to see if the server socket factory configured is based of SSLSocketBuilder. If this is also true, it will create a SSLSocketFactory wrapper around the same SSLSocketBuilder instance and set the client mode for SSLSockets created to be false. Important notes: This has currently only been tested to work with 'sslsocket' transport. Other transports may work, but have not been tested for this behavior and probably won't work (see JBREM-491 for status on implementing within all other transports). Also, this behavior will only be valid when using configuration for the 'serverSocketFactory' in the remoting server where the value for this configuration property is an ObjectName referencing an instance of the org.jboss.remoting.security.SSLServerSocketFactoryServiceMBean (otherwise no way to get a reference to the SSLSocketBuilder). An example of the server configuration needed can be found within org.jboss.test.remoting.transport.socket.ssl.builder.SSLSocketInvokerTestServer.
        Hide
        Ovidiu Feodorov
        added a comment -

        One tiny bit was missing from ServerInvokerCallbackHandler and I added it:

        server.getAttribute(serverSocketFactoryObjName, "SSLSocketBuilder") in configureSocketFactory() returns a SSLSocketBuilderMBean proxy, not a SSLSocketBuilder instance, hence the ClassCastException.

        I modified the code to use a SSLSocketBuilderMBean.

        Show
        Ovidiu Feodorov
        added a comment - One tiny bit was missing from ServerInvokerCallbackHandler and I added it: server.getAttribute(serverSocketFactoryObjName, "SSLSocketBuilder") in configureSocketFactory() returns a SSLSocketBuilderMBean proxy, not a SSLSocketBuilder instance, hence the ClassCastException. I modified the code to use a SSLSocketBuilderMBean.

          People

          • Assignee:
            Tom Elrod
            Reporter:
            Ovidiu Feodorov
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: