If E got the public key of the server, then he would be able to authenticate certificates signed by the server. The 'secret' or 'private' key is what's needed to create a signature for a certificate, and without it it's impossible to perform the proof that the private key is known to E. (sure, E could present that certificate -- but the next step of the TLS protocol is to verify that E has the private key associated with the public key embedded in the certificate, and E would not be able to do that and the handshake would fail.)
In any case, though, the security of the system does not depend on the public key being limited to only 'trusted' entities. I recommend that you look at a text on asymmetric ciphers, or public-key cryptography, to better understand this concept. -Kyle H On Wed, Apr 9, 2008 at 2:44 PM, Julian <[EMAIL PROTECTED]> wrote: > If E got ahold of this key it could complete a handshake to the server get > sensitive data? > > > > > The 'key' that you need to include with your binary is actually the > > CA's certificate (which contains the CA's public key). You don't need > > to include any 'trusted' information in the client other than that, > > and you don't need to include any 'secret' information at all. > > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
