Dear folks,

I do have a question about which private/public key pair is used when some browser client connects to a webserver using the ssl protocol.

for example:
I have a webserver with a certificate that has server-authentication as purpose. This certificate is validated against a root certificate which was created by my own certification authority.

Then on the other hand I have a certificate on a client computer with client-authentication and encryption as purpose. Also this certificate has been validated against the root cert from my own ca.

When I connect now to the webserver via ssl, what key is used for the encryption of the traffic? Is it one of the certificate's keys? Or are the keys just used for identification and does the ssl engine (or however it is called) just create some random key for the session which is used for the encryption?

note: In my case, this is a windows server and a linux client but I assume that the process is the same for linux-linux or windows-windows. (?)

Thanks in advance for your answers.

kind regards,

Lieven

Here's the soap...

(1) The bulk of the data that is sent along any secured conversation is encrypted using a randomly-generated "symmetric" (that is, conventional) key. The conversation is encrypted using a well-known symmetric algorithm such as DES3 or AES. The reason for this is simple... speed. The randomly-generated key is produced using a cryptographically strong algorithm that produces "good" random numbers... it's therefore impractical to guess them. The key is used only for THIS conversation and it is never used again.

(2) Obviously, with a symmetric cipher, the correct randomly-generated key must be supplied to the other party in the conversation, and this key must be exchanged securely. The certificate provides the means for them to do this. The random key is sent as the payload of a message that is encrypted using the public-key that is provided in the certificate. For every public key, there is a corresponding (unknown) private key that is held, and closely guarded, by the owner of the certificate. Therefore, only the intended recipient can decrypt the message that contains the randomly-generated key. Upon doing so, both parties now have the correct random-key for this conversation and they can now begin to exchange information. If the conversation continues for a long time, the two parties might decide to "re-key," that is, switch to a new random symmetric-key on the fly.

(3) "Signing" is a method that can be used to avoid accidental use of forged certificates. The signature consists of a checksum that has been encrypted using some other "trusted" key held by a "certifying authority." The public-keys used by those authorities are known, and are used to verify the signature.

(4) I have only described the keying protocol... systems like SSL contain mechanisms that allow us to continuously verify that traffic being exchanged has not been intercepted or modified in transit, and that encrypted matter captured from some previous conversation is not being "re-played" and injected into the stream.

Thank you for this explanations.
I also found the following site which explains some more: (english)
http://tldp.org/HOWTO/Apache-WebDAV-LDAP-HOWTO/ssl.html

kind regards,
Lieven