Using trusted certificates to avoid

Question

I have a certain presumption I wish to confirm.
Presumption: When an SSL client attempts to make a connection to a remote host, once that connection is made, the client says (i.e, behaves as if he says), "I know what site I want to connect to. I have attempted a connect to that URL. I am now connected to some site but I will not allow this connection to proceed unless the remote host presents evidence he is who I think he is." whereupon the remote host presents all the certificates he has available (from jssecacerts file, I think). The client host compares each presented certificate in turn to the list of trusted certificates he has in his keystore (cacerts). When he finds one that is a match the client says, "Okay, I will allow this connection to proceed." and moves on. If the client does not find a match he aborts the connection and throws the exception which reports "unable to find a valid path to the requested target."
Now, my presumption is that the remote host may have purchased a certificate from one of the "trusted authorities" such as verisign, thawte, geotrust, etc. and have imported that certificate into his jssecacerts file. Therefore presenting that certificate, among others, when asked by the enquiring client. The client compares that certificate to his cacerts file and finds there a base certificate (by following the "trust chain") from, say, verisign from which his presented certificate has been derived. Therefore the client is able to follow the "trust chain" up from the remote server's certificate to the trusted base certificate already existing in the client's cacerts keystore and, therby, be able to accept the connection to the remote host.
Is that the way it works? So I can avoid either causing the client visiting my server site to throw the "unable to find ... to requested target" exception and to prevent the client which may be connectiong via a browser from having to ask the user to say, "Yes. I am willing to accept this unknown site as a trusted site."
Correct?
Thanks.

Answer 1

Is that the way it works?Yes.
So I can avoid either
causing the client visiting my server site to throw
the "unable to find ... to requested target"
exception and to prevent the client which may be
connectiong via a browser from having to ask the user
to say, "Yes. I am willing to accept this unknown
site as a trusted site."Yes.
However note that what SSL is doing here is authentication, i.e. proving that the site is who it says it is. Whether that's the site you want, i.e. whether you want to authorize communications with that host, is ineradicably up to the application. And that's what handshake completion listeners and HostnameVerifiers are for.
Too many people in these forums try to achieve authorization via the SSL truststore. That's not what it's for.