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 (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
    • Labels:
      None
    • Similar Issues:
      Show 10 results 

      Gliffy Diagrams

        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:

                Development