Reasonable SSL handshake timeout (is user interaction feasible?)

Question

I'm writing some code that will connect over https to a JBoss/Wildlfy server. Under certain circumstances, the server may require a client certificate on the SSL connection, in which case I will need to prompt the user for it (in a GUI)

Getting this working involves implementing the X509KeyManager interface, which one supplies to the low-level client code, and the methods on it will be called if the SSL client receives a request for a certificate from the server.

This is all well and good but I assume that if I try and prompt the user for a certificate within the X509KeyManager implementation then I suspect a reasonable amount of time to allow the user to choose a certificate in a UI far exceeds how long one can keep a server waiting during the handshake without it timing out.

The alternative is to bail out at this point, prompt the user to supply a certificate, and then retry connecting - with the X509KeyManager able to respond more or less instantaneously with the pre-chosen certificate. Obviously that means connecting to the server twice (well, 1.5 times), with increased latency.

Does anyone know whether user interaction is feasible? I presume web browsers have the same problem when a client certificate is requested/required, and I suspect they just retry the connection.

Answer 1

The increased latency when reconnecting is far below the time to ask the user for the certificate, let it decide to choose the right one etc. On the other hand you tie up resources at the server if you just hang around connected, waiting for the user to choose a certificate. So I think the best option is to reconnect after the user has chosen the certificate.