问题描述
我的环境是作为应用程序服务器的Maven项目和Wildfly(8.2.1).我需要使用SOAP将传入的REST调用与第三方服务器连接.我需要SSL客户端身份验证；因此，我有自己的KeyStore和TrustStore.因此，我创建了自己的SSLContext，需要让WebService使用此SSLContext.
My environment is a Maven Project and Wildfly (8.2.1) as Application Server. What I need is to connect wihin a incoming REST call to a third party server using SOAP. I need SSL Client Authentication; therefore, I have my own KeyStore and TrustStore. I create therefore my own SSLContext and need to let the WebService use this SSLContext.
Wildfly出现问题，并且使用了JAXWS的实现(Apache CXF?)-我在这里进行了描述(但还有解决该问题的另一种方法；因此，这不是重复的帖子！ ):
Wildfly:如何使用JAXWS -RI代替Apache CXF(仅WebService客户端)
There is a problem with Wildfly and it's used implementation of JAXWS (Apache CXF?) - I described it here (but with another aproach to solve the problem; therefore it is not a duplicate post!):
Wildfly: How to use JAXWS-RI instead of Apache CXF (WebService client only)
主要问题之一似乎是Wildfly中使用的JAXWS似乎忽略了使用属性com.sun.xml.internal.ws.transport.https.client.SSLSocketFactory设置自己的SSLContext:
One of the main problems seems to be that JAXWS used in Wildfly seems to ignore setting the own SSLContext with property com.sun.xml.internal.ws.transport.https.client.SSLSocketFactory:
MyWS_Service service = new MyWS_Service(null, new QName("http://...", "MyWS"));
MyWS port = service.getMyWSSOAP();
BindingProvider bindingProvider = (BindingProvider) port;
bindingProvider.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "https://hostname:443/.../...");
// the following setting is ignored!
bindingProvider.getRequestContext().put("com.sun.xml.internal.ws.transport.https.client.SSLSocketFactory", mySslSocketFactory);
// in some posts, we see that we need to eliminate 'internal' in the property. This does not help!
bindingProvider.getRequestContext().put("com.sun.xml.ws.transport.https.client.SSLSocketFactory", mySslSocketFactory);
被忽略的证据是，如果我使用HttpsURLConnection.setDefaultSSLSocketFactory(mySslSocketFactory)来设置SSLContext，它确实可以工作-意味着SSL连接的建立归功于导入到SSLContext中的自定义TrustStore设置的根CA.
The proof that it is ignored is that if I use HttpsURLConnection.setDefaultSSLSocketFactory(mySslSocketFactory) to set the SSLContext, it does work - means the SSL connection is established thanks to the imported root CA to the customized TrustStore setup in the SSLContext.
如果我们查看其他帖子(例如如何以编程方式设置JAX-WS客户端的SSLContext?)，此属性应该有效(即使是Wildfly，根据那里的一些评论).但这不是我的情况.可能是什么原因造成的?
If we look at other posts (e.g. How to programmatically set the SSLContext of a JAX-WS client?) this property should work (even for Wildfly according some comments there). But it does not in my situation. What can be the cause of this?
推荐答案
问题显然是Apache CXF忽略的
The problem is definitifely that Apache CXF ignores
bindingProvider.getRequestContext().put(
"com.sun.xml.[internal.]ws.transport.https.client.SSLSocketFactory", mySslSocketFactory);
在某些地方有一些评论.
in oposite to some comments some where.
因此，我的最终解决方案是以编程方式设置所使用的HTTPConduit(而不是在cxf.xml文件中设置配置).
So my final solution is to programmatically setup the HTTPConduit used (rather than set a config in a cxf.xml file).
// Set custom SSLContext.
HTTPConduit conduit = (HTTPConduit) ClientProxy.getClient(port).getConduit();
TLSClientParameters tlsClientParameters = new TLSClientParameters();
tlsClientParameters.setSSLSocketFactory(customSSLContext.getSocketFactory());
conduit.setTlsClientParameters(tlsClientParameters);
我希望这可以帮助遇到类似问题的人...
I hope that this helps someone having similar issues...
这篇关于Wildfly的JAXWS实现似乎忽略了bindingProvider属性com.sun.xml.ws.transport.https.client.SSLSocketFactory的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！