Web sites use certificates to create SSL sessions. When a user clicks a HTTPS link, it initiates the SSL handshake process.
The web site will then send the client a certificate with a public key that can be used in the asymmdtric portion of the SSL session to create a session key. (The session key will then be used in the symmetric portion of the SSL session.) The client needs to verify the certificate is trusted and valid:
Trusted. First, the certificate must have been issued from a trusted certificate authority (CA). A list of trusted CAs can be viewed in Internet Explorer by clicking Tools -> Internet Options, selecting the Content tab, click the Certificates button, and selecting Trusted Root Certification Authorities. If the certificate was issued to the web site from a company with a certificate in the Trusted Root Certification Authority store, it will be trusted. If the certificate is not trusted, the user will be notified that it's not trusted and encouraged not to continue.
Valid. Next, the client attempts to validate the certificate. CAs can revoke certificates if they become compromised in some way. A revoked certificate is considered invalid and shouldn't be used. Revoked certificates are published on a certificate revocation list (CRL). Clients can check if a certificate is valid using one of two methods:
- Requesting the CRL. The client requests a copy of the CRL from the CA. The CA sends the CRL and the client then checks the CRL to see if the certificate is on the list. If it's on the list, it's considered invalid and wouldn't be used.
- Online Certificate Status Protocol (OCSP). OCSP is an improved streamlined process. Instead of the client requesting a copy of the CRL, the client queries the CA about the certificate. Certificates are uniquely identified with a serial number. The CA then replies indicating the certificate is healthy (not revoked), not healthy (revoked), or unknown (the serial number is not known by the CA.
At this point, only the client knows the session key. The encrypted session key is sent back to the web server. Since this key was encrypted with the public key (which is matched to the private key held by the server and unknown to anyone else) it can't be decrypted if anyone intercepts it. When the web server receives the encrypted key, it decrypts it with the private key. Use of the public and private key is known as asymmetric encryption.
For the remainder of the session, the client and server use the session key (symmetric encryption).