I think that the error is in Apache and the SSL renegoation bug. I will be upgrading apache tomorrow.
it looks like there is a problem using jboss against apache.
I have now updated apache and i can use SSLSocketFactory width client certificate without using the system property sun.security.ssl.allowUnsafeRenegotiation=true.
but when i use a bindingprovider in jboss in a servlet i get "Re-negotiation handshake failed: Not accepted by client" in the apache log.
so either the problem is in jboss or in apache.
after more googling i think the problem is in jboss.
i think that the code
UserInterface ui = new SoapService().getUserInterfacePort();
BindingProvider bp = (BindingProvider) ui;
actually dont send the certificate AT ALL.
so my original question stands: how do i use different certificates against different web services?
my related question
I've found that with 3.4.1, org.jboss.ws.* settings don't apply to SSL connections, only for WS securty.
Add the javax.net.ssl settings to System properties
this will not answer your question directly but a strong (or even super strong) recommendation is to not expose your JBoss instance to the public at all. JBoss is full with a lot of useful functionality, but that will also make JBoss more unsecure. A faster solution (read more performant, believe me or not) is to setup an Apache HTTPD server using mod_proxy directed to your JBoss. Then you configure and terminate your SSL request in the Apache HTTPD. If you really need SSL on your internal network I suggest you to setup a local instance of the Apache HTTPD and make the proxy call to localhost to not expose the proxy traffic on the network. Why do this?
1. Apache HTTPD is much faster than JBoss in serving HTTP(S) and SSL (it is mainly written for forwarding HTTP)
2. Using Apache HTTPD as a proxy is more or less the standard way of doing such things you are asking for
3. Apache HTTPD is much more secure due to less functionality. Used with a few modules, Apache HTTPD is one of the most secure market standard web server software.
3. Apache HTTPD is a standard product that may be organized by your hosing partner/department from a standard view.
Note! If you don't like Apache HTTP you might have a look at nginx (www.nginx.org) that is smaller and even faster than Apache HTTPD.
So, this is not a direct answer to your question, but I hope it help you solving your problem.
I'm writing this tip because I believe that many people think that shall configure things in JBoss just because they _can_ do it in JBoss, but I do not always agree with that kind of thinking. I like to use market standards, as much as I can so other people can take care of what I've done when I hand over my solution to the hosting partner. DS.
We are not really exposing jboss to the public since we are talking server to server webservices with firewalls, ipadress checks and maybe even VPN tunnel.
Yes, you could use Apache as a proxy but then you will need to add the different certificates to Apache and configure Apache so it uses the correct certificate against different urls.
Our solution in this case was to use Apache CXF, that is much more mature then jax-ws.
JAX-WS is a specification, not an implementation
I think you ment to say that CXF is more mature and JbossWS-Native?
Regardless, there is a related JIRA for this that does actually solve the problem. Basically, the attached file will check the context map for ssl parameters first, then system.getproperties. Again, this is just for SSL related issues, message level encryption/certificates are a different story