Edward Diener wrote: > In this last case I do not understand how the client can encrypt data > going to the server if it has no private key of its own.
Your question is kind of puzzling. Why would the client needs its own private key in order to encrypt data going to the server? In general, private keys are used for decrypting. During the SSL session establishment phase, the client can encrypt data using the server's public key. Basically, it goes like this: 1) The client connects to the server. 2) The server sends the client its public key and certificate(s). 3) The client validates the certificates and public key and confirms that it has reached the correct server. At this point, the client has the server's public key and knows that it has the public key of the server it wishes to talk to. So it can encrypt data using that public key and send it securely to the server. Since only the appropriate server has the corresponding private key (that's what the CA has attested to, at least), the client knows that only its intended recipient can decrypt what it sends. This completes the first phase of the session establishment. Logically the phases are (assuming a typical SSL use -- a browser connects to a secure web server with a certificate issued by a typical CA): 1) The client connects to the server. 2) The server sends the client the server's public key and certificate. 3) The client verifies the certificate's validity and appropriateness: Is it for the web site we intended to reach? Was it issued by a CA we trust? Does the public key given match the certificate? 4) The client challenges the server to decrypt something that the client has encrypted using the server's public key. 5) The server proves to the client that it can decrypt what the client sent and establishes a shared secret with the client. The client now knows that it is talking to an entity that owns the private key correspondending to the public key it knows belongs to the server it wishes to talk to. 6) The client and server use the new shared secret to converse securely using a symmetric encryption scheme. Note that the server has no idea who it is talking to. Typically, the client will validate its identity using a username and password sent over the secure connection. But SSL does support the client sending its own certificate and proving that it owns the private key corresponding to the public key in the client's certificate (using more or less the same process used above). In that case, each party knows who it is speaking to when session establishment completes. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
