The good news is I have managed to unpick the various TLS issues I've
been struggling with.

The Chrome not selecting the user cert issue looks to be related to how
many of the fields were complete in the DN. That has been resolved by
recreating the test keys and certs I have been using.

I was also seeing some ugly stack traces in the console during
renegotiation. The root cause is the final issue in this mail but the
stack traces were a sign of some edge cases in the error handling. These
have been fixed in r1804463.

NIO and NIO2 with JSSE work as expected.

NIO and NIO2 with OpenSSL mostly work as expected. The only glitch is
that because we don't specify a set of trusted certs, OpenSSL doesn't
send any CA names to the user agent which in turn opts to display all of
the available client certs. This is more a usability issue for users
with lots of certs than a bug. I'll create a Bugzilla entry for this one.

The final issue is the one I have tried, and failed, to solve. The
renegotiation sequence with APR/native doesn't work as expected. I've
been debugging may way through the call to SSL.renegotiate(long) and
this is what happens:

SSL_renegotiate() returns 1 (success)
SSL_do_handshake() returns 1 (success)
SSL_is_init_finished() returns 1 (success)
SSL_peek() returns -1 (failure)
  At this point the client prompts the user to select a certificate
  The return code is not currently tested so the code continues
  (If SSL_get_error() is called here, SSL_ERROR_WANT_READ is returned)
SSL_is_init_finished() returns 1 (success)

Execution returns to the Java code where no certs are found on the
connection so a 401 response is sent back to the client.

Shortly afterwards the user selects a certificate, the handshake
continues and then the connection fails as soon as the handshake completes.

I think the behaviour we are seeing is because the connection is in
non-blocking mode. I have tried various ways to handle this without success.

Help with a solution very much appreciated.


To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to