On Fri, Mar 03, 2006 at 12:11:24PM -0500, Xie Grace Jingru-LJX001 wrote: > I generated the key and self-signed certificate by doing the following: > > openssl genrsa -out privkey.pem 2048 > openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095 > > I install the cert and key on my HTTPS server. From a browser, I entered > https://serverIPaddress on the browser, the certificate then is loaded > and accepted by the browser. The HTTPS server and the client (browser) > can now talk via HTTPS connection. > > Could you explain -- > > (1) what was just going on during the negotiation and security > connection setup? The sequence of the handshaking. > (2) Is the public key part of the certificate being passed to the > client? > (3) Did the server authenticate the client in this process? or there is > no authentication in this type of handshaking? > (4) What does the server do with the key generated (privkey.pem)? Is > this the private key? Does the client need to know about this key? > (5) Do both the server and client use the key to encrypt and decrypt the > data packets? Which key do they use? > > Could you recommend any docs that explain all these.
Here are some good sources of information: http://www.cs.auckland.ac.nz/~pgut001/tutorial/ http://www.modssl.org/docs/2.8/ssl_faq.html And also I'd highly recommend the book "Applied Cryptography" by Bruce Schneier (for principles, rather than specifics of SSL) To answer your point (2), a certificate contains: 1. A public key 2. An identity (subject name) 3. An expiry date 4. A signature (from an issuer) So yes, it contains the server's public key. The certificate is basically a declaration from the issuer, saying "the person holding the private key corresponding to this public key is known to me, and has the identity shown". The client needs to have the *issuer's* public key, in order to check the signature. So to answer your point (4), the server *does* need to hold the private key, in order to prove its identity to the client. It can prove that it possesses the private key corresponding to the one in the certificate, without actually revealing it. To answer (3), it's optional as to whether the client proves its identity to the server with its own certificate, or not. You can configure the server to require the client to do so. To answer (5), the actual keys used to encrypt data are agreed upon separately. The certificates are used to prove the identities to each side, so that you know the data you read is from the right place, and so you don't send data to someone who shouldn't be seeing it. That's a very rough and ready description, but maybe accurate enough for your purposes :-) Regards, Brian. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
