When you connect to an HTTPS Web site which uses a "problematic certificate" (e.g. one which is not issued by a recognized CA, an expired certificate, or a certificate which does not contain the server name as it appears in the URL), the browser asks for confirmation from the user. This can happen only after the server certificate has been retrieved, as part of a SSL handshake. This accounts for at least one initial connection with handshake.
Keeping a SSL connection open uses up some resources on the server; so servers auto-close connections after some inactivity, and browsers try not to keep connections open for too long. Displaying the warning about the invalid certificate implies waiting for the human user to come to a decision (to click or not to click, that is the question). This will take some time; humans are slow. Therefore, the browser will first close its initial SSL connection, the one it used to obtain the server certificate -- not HTTP has occurred yet, though, only the SSL handshake. When the human user finally decides to connect despite the scary warning, the browser will open a new connection, with a new SSL handshake, and in that one there will be some HTTP (as "application data").
As for the other connection (the "initial connection" is actually two connections made in parallel): Chrome is known to open speculative connections so as to speed up subsequent requests; in general, a Web page includes images which will have to be downloaded promptly. Chrome appears to be overzealous at times. The plausible scenario is then:
- Chrome opens two connections with SSL handshakes.
- Chrome notices that the certificate is flaky, and requires human intervention. It closes the two connections without doing any HTTP within the SSL tunnels.
- When the user decides to open the page, Chrome opens a third connection, does a SSL handshake, and this time follows on with the HTTP dialog.