ansaurus

Question

Web-service with attachment failed on 2-ways SSL connection

Answer 1

A:

I may have found a solution to my problem.

As explained, the ws-provider Tomcat is giving me the following error:

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)

So I had a look on the synchronousHandshake method (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");
    }
}

As you can see, the timeout idea was not a real timeout problem, at least on my case. The error seems to happen because we read data from SSLSocket, and at the end, we do not consider that the handshake was completed correctly.

Another thing is that I got another problem when removing the PDF attachment in my WS call. This error said that the XML parsing failed. So I suspected that the data received on the ws-provider side was chunked, for some reasons.

Then, I finally found an interesting parameter in the Tomcat Connector, which is 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).

So I decided to modify the Tomcat Connector configuration to set the maxSavePostSize="-1" (i.e. the buffer is not limited to 4Kb anymore).

I am not 100% sure that this is the correct fix to apply in my situation, but all the tests I made today (with PDF attachment) were successfull, even the tests that always failed before...

romaintaz 2010-09-09 10:28:08

ansaurus

tags:

views:

answers:

Web-service with attachment failed on 2-ways SSL connection

related questions