Can you provide the binary network trace by any chance? Using 'close' option should at least work, but may not be that performant.
If it does not I would consider this a bug. -Bernhard On Sun, Feb 5, 2012 at 5:50 PM, JKemp <[email protected]> wrote: > Hmm, the Close option doesn't appear to work. It just makes it so that I > can't reuse the original connection immediately. With the keep alive > option, I could reuse the connection until I exceeded the timeout period, > but with close, the first connection works, but then the second connection > fails immediately. > > Based on a recommendation, I tried setting the allowUnsafeRenegotiation > option to true, but that option doesn't seem to work either. I would > assume > this means that it's the client side certificate that's failing then? > > Here's the logging from the attempt with it set: > > Allow unsafe renegotiation: true > Allow legacy hello messages: true > Is initial handshake: true > Is secure renegotiation: false > Camel (camel-1) thread #0 - ErrorHandlerRedeliveryTask, setSoTimeout(60000) > called > %% Client cached [Session-1, SSL_RSA_WITH_RC4_128_MD5] > %% Try resuming [Session-1, SSL_RSA_WITH_RC4_128_MD5] from port 55483 > *** ClientHello, SSLv3 > > Thanks. > > -- > View this message in context: > http://cxf.547215.n5.nabble.com/Question-on-SSL-caching-tp5455499p5458171.html > Sent from the cxf-user mailing list archive at Nabble.com. > -- IT-Consulting Bernhard Thalmayr - Painstaking Minds - 83620 Vagen (Munich area) Germany
