SSL is a very common protocol used these days when browsing the web. The purpose is to provide security to communication, but how does it do it? There are several pieces at work that have to be setup before SSL will even work and it requires both the client and server to be configured properly or no communication will succeed.
PKI - Public Key Infrastructure. The entire environment that generates/maintains keys and certificates.
CA - Certificate Authority. The issuer/signer of public keys that create certificates
Asymmetric Keys - Cryptographic keys that are different but mathematically related
Symmetric Keys - Cryptographic keys that are the same exact key
Public Key - the asymmetric key that is used by public people; generally by the client to encrypt data only (except for digital signature)
Private Key - the asymmetric key that is kept private; used only by the owner to decrypt data only (except for digital signature)
SSL Handshake - the process that happens when a client and server try to establish an SSL connection
Cipher - The cryptographic algorithm used to encrypt data
Hash - Used for message authentication
Cipher Suite - A collection of ciphers and hashs providing a suite of cryptographic services for a message
One way SSL - Client validates who the server is. Server doesn't validate the client
Two way SSL - One way SSL but server validates the client as well. AKA, mutual auth or client auth SSL
The server is providing the service and requires a private key and certificate or else no SSL will be able to take place. A private key/public key pair is generated and using a PKI system, has a CA sign the public key via a CSR. These certificate-key pairs are installed into the server application. In addition to this, the server must be configured with allowed protocols (e.g. SSLv3, TLSv1.0, TLSv1.1, TLSv1.2) and what cipher suites are allowed to be used when talking to the server. Optionally, the server can be configured to validate the clients that connect. If this is done, then the server is required to have the public CA Root and Intermediate certificates of the CA the server is allowed to trust (e.g. Verisign, Entrust, etc.). Lastly though, it should be noted that the certificate should be linked to its issuing CA certificate and in turn to its issuing CA certificate to establish a chain of trust back to the Root CA certificate.
While most clients, typically browsers, "just work", it is because they come pre-configured. This pre-configuration involves the browser being loaded with the CA Root/Intermediate certificates that are common and trustworthy (e.g. Verisign, etc.). Since most servers have certificates signed by a few CAs that are preloaded, no additional configuration is required. However, if the server you need to talk to didn't have their certificate signed by one of these CAs or the client you are using is not a browser, you may need to install the CA Root/Intermediate certificates in order to ensure it will trust the server you're talking to. Optionally, the client can be configured with its own certificate-key pair which can be used when talking to a server; however, just because the server is sent the client's certificate, doesn't mean the server needs to validate the client.
Step 4 is the start of the SSL Handshake. The client doesn't just say hello though, it sends several pieces of information to the server. The key pieces are cipher suites that the client supports, SSL version it can use, and a random number. The random number is used in a later step. Optionally it can send a SSL Session ID but only if it is trying to re-use a previous SSL session.
Step 5 is where the server will tell the client which cipher suite to use and which SSL version it is using. It also passes its certificate, its own random number and a session ID. The session ID is either the one specified by the client in step 4 if a valid session ID for re-use or a new SSL session ID.
Step 6 is where the server passes the client its certificate. Now that the client has the certificate, it will validate the certificate to see if the SSL handshake can proceed. Note. The server can 'link' the certificate to its issuing CA intermediate and even to its root issuing CA certificate. When this is done, the server sends the entire chain of certificates in this message. This is why only the Root CA certificate needs to be trusted. However, if the server certificate is not linked and a chain cannot be determined, the client must be configured explicitly to trust the direct issuing CA of the server certificate. Thus the client could actually trust the Root CA of the server certificate issuer and still not trust it due to a lack of a proper chain.
Step 7. The client creates a pre-master secret, PMS. The PMS is used in combination with the random keys from step 4 and 5 to come up with the symmetric key that will be used later. The client then uses the public key in the certificate received in step 6 to encrypt the PMS and send to the server. The server in turn will decrypt it with its private key and thus compute the same symmetric key as the client because it too has the previously created random numbers. This calculated key is called a master secret.
Steps 8-9 are purely optional. If the server is configured to authenticate the client, it will request that the client send its certificate and the client in turn will send it. Part of this validation is checking the CA's being trusted, but it also involves checking a digital signature of random data the client sent as well. This is to prevent someone from just using the client certificate and not having the private key.
Steps 10-11 are effectively saying that from then on the sending side will only use the calculated symmetric key to send data.
Step 12 is where the encrypted data is being sent between the hosts.