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)

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.

Tom Elrod
added a comment - 25/May/06 1:33 AM 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.

Ovidiu Feodorov
added a comment - 25/May/06 1:54 PM 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.