我有两个应用程序，一个提供 Web 服务(我们称它为 ws-provider)，另一个是该 Web 服务的客户端(称它为 ws -客户端)。
此通信通过双向 SSL 进行保护。两台服务器都已针对此 secret 性限制进行了正确配置(证书安装、SSL 配置、Tomcat 参数化...)
服务器在 Tomcat(5.5 for ws-provider，6 for ws-client)、Java 6 上运行，并使用 Jax-WS 提供/使用网络-服务。
当用户连接到ws-client 应用程序并执行调用ws-provider 网络服务的操作时，后一个操作通常 失败并出现以下错误:
com.sun.xml.ws.client.ClientTransportException: The server sent HTTP status code 400: No client certificate chain in this request
at com.sun.xml.ws.transport.http.client.HttpClientTransport.checkResponseCode(HttpClientTransport.java:218)
at com.sun.xml.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:137)
at com.sun.xml.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:74)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:559)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:518)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:503)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:400)
at com.sun.xml.ws.client.Stub.process(Stub.java:234)
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:120)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:230)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:210)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:103)
at $Proxy33.createOrRenewRequest(Unknown Source)
at my.app.MyPushRequest.sendXMLRequest(MyPushRequest.java:29)
at my.app.MyRequestCreation.sendRequestForDraftApproval(MyRequestCreation.java:284)
在 ws-provider 上，我得到这个错误:
WARNING: Exception getting SSL attributes
java.net.SocketException: SSL Cert handshake timeout
at org.apache.tomcat.util.net.jsse.JSSE14Support.synchronousHandshake(JSSE14Support.java:101)
at org.apache.tomcat.util.net.jsse.JSSE14Support.handShake(JSSE14Support.java:67)
at org.apache.tomcat.util.net.jsse.JSSESupport.getPeerCertificateChain(JSSESupport.java:121)
at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:1127)
at org.apache.coyote.Request.action(Request.java:349)
...
现在，奇怪的是我刚才说调用网络服务时通常失败。 由于某些原因，有时我在调用网络服务时会成功尝试。如果用户在登录应用程序后的一分钟内启动操作，通常会发生这种情况(不，我不知道为什么!)...
网络服务请求包含一个附件。这个附件是一个不超过 15Kb 的 PDF 文件(至少在我所有的测试中，无论成功还是失败，都没有超过这个大小)。
所以经过多次测试，我尝试调用相同的网络服务而不附加任何 PDF 文件，调用成功。
供您引用，如果在 ws-provider 上禁用安全约束(即我们不再使用双向 SSL 连接)，则网络服务调用永远不会失败。
所以我想我必须在我的网络服务或 Tomcat(或？)上配置一些东西才能使系统正常工作。 任何想法？
Java代码
这里是提供ws-client方法调用的Java接口(interface)(如你所见，用于WS的核心Java类是由Jax-WS库生成的):
/**
* This class was generated by the JAX-WS RI.
* JAX-WS RI 2.1.3-b02-
* Generated source version: 2.1
*
*/
@WebService(name = "PushServicePortType", targetNamespace = "http://my.app.ws/PushService")
@XmlSeeAlso({
ObjectFactory.class
})
public interface PushServicePortType {
@WebMethod
@WebResult(name = "response", targetNamespace = "")
@RequestWrapper(localName = "createOrRenewRequest", targetNamespace = "http://my.app.ws/CwfPushService", className = "my.app.CreateOrRenewRequest")
@ResponseWrapper(localName = "createOrRenewRequestResponse", targetNamespace = "http://my.app.ws/CwfPushService", className = "my.app.CreateOrRenewRequestResponse")
public String createOrRenewRequest(
@WebParam(name = "xmlMessageContent", targetNamespace = "")
String xmlMessageContent,
@WebParam(name = "version", targetNamespace = "")
String version,
@WebParam(name = "attachments", targetNamespace = "")
List<DataHandler> attachments);
}
ws-client 的调用如下(xmlFile 包含请求的 XML，datahandler 是一个 javax.包含 PDF 附件的 activation.DataHandler):
PushServicePortType pushServicePort = new PushService(new URL("url/to/wsdl"), new QName("http://my.app.ws/PushService", "PushService")).getPushServiceSOAP(new MTOMFeature());
PushRequest push = new PushRequest();
responseXML = push.sendXMLRequest(pushServicePort, xmlFile, datahandler);
有很多配置文件、日志或 Java 类。因此，如果需要，请不要犹豫，询问更多详情!
编辑 1
我试图通过定义 MTOM threshold 来强制将 PDF 文件集成到 SOAP 消息中到 2Mb:
在 ws-client 上:
PushServicePortType pushServicePort = new PushService(new URL("url/to/wsdl"), new QName("http://my.app.ws/PushService", "PushService")).getPushServiceSOAP(new MTOMFeature(2097152));
在 ws-provider 上，我使用 @MTOM(threshold=2097152) 配置了 MTOM 注释
很遗憾，此更正没有解决我的问题......
编辑2
我已经从我的网络服务中删除了所有的 PDF 附件，现在它也失败了但有不同的消息:
javax.xml.ws.soap.SOAPFaultException: Failed to read a response: javax.xml.bind.UnmarshalException
- with linked exception:
[javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,3834]
Message: XML document structures must start and end within the same entity.]
at com.sun.xml.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:173)
at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:102)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:240)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:210)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:103)
at $Proxy33.createOrRenewRequest(Unknown Source)
at my.app.CWFPushRequest.sendXMLRequest(PushRequest.java:29)
...
Caused by: com.sun.xml.ws.encoding.soap.DeserializationException: Failed to read a response: javax.xml.bind.UnmarshalException
- with linked exception:
[javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,3834]
Message: XML document structures must start and end within the same entity.]
at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:235)
at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:74)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:559)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:518)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:503)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:400)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:229)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:430)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:230)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:121)
at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:115)
at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:146)
at com.sun.xml.ws.transport.http.servlet.WSSpringServlet.doPost(WSSpringServlet.java:52)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at sun.reflect.GeneratedMethodAccessor330.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:276)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:162)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:262)
at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:52)
at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:171)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:167)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.valves.FastCommonAccessLogValve.invoke(FastCommonAccessLogValve.java:482)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685)
... 1 more
Caused by: javax.xml.bind.UnmarshalException
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamException(UnmarshallerImpl.java:397)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:335)
at com.sun.xml.bind.v2.runtime.BridgeImpl.unmarshal(BridgeImpl.java:84)
at com.sun.xml.bind.api.Bridge.unmarshal(Bridge.java:197)
at com.sun.xml.ws.server.sei.EndpointArgumentsBuilder$DocLit.readRequest(EndpointArgumentsBuilder.java:492)
at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:233)
... 41 more
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,3834]
Message: XML document structures must start and end within the same entity.
at com.sun.xml.stream.XMLReaderImpl.next(XMLReaderImpl.java:563)
at com.sun.xml.ws.encoding.MtomCodec$MtomXMLStreamReaderEx.next(MtomCodec.java:413)
at com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:188)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:333)
... 45 more
我已经尝试记录 ws-client 发送的 SOAP 消息，但我没有发现其中有任何问题...
最佳答案
我可能已经找到了解决问题的方法。
如前所述，ws-provider Tomcat 给我以下错误:
java.net.SocketException: SSL Cert handshake timeout
at org.apache.tomcat.util.net.jsse.JSSE14Support.synchronousHandshake(JSSE14Support.java:101)
at org.apache.tomcat.util.net.jsse.JSSE14Support.handShake(JSSE14Support.java:67)
at org.apache.tomcat.util.net.jsse.JSSESupport.getPeerCertificateChain(JSSESupport.java:121)
所以我查看了 synchronousHandshake 方法(Tomcat 5.5.23):
private void synchronousHandshake(SSLSocket socket) throws IOException {
InputStream in = socket.getInputStream();
int oldTimeout = socket.getSoTimeout();
socket.setSoTimeout(1000);
byte[] b = new byte[0];
listener.reset();
socket.startHandshake();
int maxTries = 60; // 60 * 1000 = example 1 minute time out
for (int i = 0; i < maxTries; i++) {
if (logger.isTraceEnabled())
logger.trace("Reading for try #" + i);
try {
int x = in.read(b);
} catch (SSLException sslex) {
logger.info("SSL Error getting client Certs", sslex);
throw sslex;
} catch (IOException e) {
// ignore - presumably the timeout
}
if (listener.completed) {
break;
}
}
socket.setSoTimeout(oldTimeout);
if (listener.completed == false) {
throw new SocketException("SSL Cert handshake timeout");
}
}
如您所见，超时 的想法并不是真正的超时问题，至少在我看来是这样。错误的发生似乎是因为我们从SSLSocket读取数据，最后，我们认为握手没有正确完成。
另一件事是我在 WS 调用中删除 PDF 附件时遇到了另一个问题。此错误表示 XML 解析失败。所以我怀疑由于某些原因，ws-provider 端接收到的数据被分块了。
然后，终于在Tomcat Connector中发现了一个有趣的参数，就是maxSavePostSize :
The maximum size in bytes of the POST which will be saved/buffered by the container during FORM or CLIENT-CERT authentication. For both types of authentication, the POST will be saved/buffered before the user is authenticated. For CLIENT-CERT authentication, the POST is buffered for the duration of the SSL handshake and the buffer emptied when the request is processed. For FORM authentication the POST is saved whilst the user is re-directed to the login form and is retained until the user successfully authenticates or the session associated with the authentication request expires. The limit can be disabled by setting this attribute to -1. Setting the attribute to zero will disable the saving of POST data during authentication. If not specified, this attribute is set to 4096 (4 kilobytes).
所以我决定修改 Tomcat 连接器配置以设置 maxSavePostSize="-1"(即缓冲区不再限于 4Kb)。
我不是 100% 确定这是适用于我的情况的正确修复，但我今天所做的所有测试(带有 PDF 附件)都是成功的，即使是之前总是失败的测试......
关于java - 带附件的 Web 服务在 2 路 SSL 连接上失败，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3650404/