The problem lies in our use of javax.net.ssl.SSLSocketFactory.getDefault() internally when explicit ssl config is missing (more on this in a min), which can be found within org.jboss.remoting.security.SSLSocketBuilder (line 421). The jdk (at least Sun's implementation) will cache this factory once created, including the system property values used to create it. Therefore, once a transporter client is created using ssl based transport, this default SSLSocketFactory is created and will be re-used for any other transporter clients created using a ssl based transport. Unfortunately, can't do much about jdk's default SSLSocketFactory not re-checking the system properties after it has been created once. However, will add to the remoting transporter client code so can pass in explicit ssl configuration, so don't have to rely on the default ssl socket factory (see http://jira.jboss.com/jira/browse/JBREM-652). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995102#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...