When a security warning is displayed, the user should treat it as a full-scale security emergency and trigger damage containment and recovery procedures. It is well-known that users do not do that; instead, they click OK or Cancel (whichever is nearest to the current mouse pointer position).
In the situation you describe, the user is trying to contact an inexistent site: there is no such thing as an SSL-enabled site2.com
. Because of a quirk of HTTPS, the server cannot return the correct answer (namely "connection refused") and instead initiates a SSL connection with the certificate for site1.com
(hence the warning). Once the SSL handshake is done, the browser sends the actual URL (which contains site2.com
), the server becomes aware of the problem, and courteously offers a redirection to the non-HTTPS site.
If the client browser is recent enough, it may use the Server Name Indication extension, giving an advanced indication of the server name that the browser tries to reach (i.e. site2.com
), which would allow the server to abort the SSL layer early on, avoiding the security warning popup on the client (the server would still have to be configured to implement that behaviour, though).