Having a SSL certificate will enforce visitors to connect to a website via the HTTPS protocol, which runs on port 443. The server and the visitor will communicate and transmit encrypted data under this protocol. This is a great way to protect sensitive data, such as passwords, or credit card information, since they will appear as garbled and unintelligible strings in the eyes of snoopers. It offers basic protection against man in the middle attacks.

How SSL certificates work

SSL stands for Secure Socket Layer, which is a security protocol for maintaining an encrypted connection between two end-to-end hosts -- typically, this would be the web server (website) and a browser. The server creates an asymmetric key to create and protect the SSL certificates, and a shared symmetric key for data encryption with incoming requests by browsers or other hosts. See Basic Encryption.

Setup

1. A request for a certificate is made by the web server owner. The owner creates a private/public crypto key and a CSR (Certificate Signing Request) is also created using the public key.
2. The CSR is now sent to a CA or Certificate Authorities (i.e. DigiCert, Comodo).
3. The CA will now issue you a SSL certificate based on the payload of the CSR. The CA has no knowledge of the owner's private key.
4. The owner installs the SSL certificate onto the server, as well as intermediate certificates that establish the credibility of your certificate and the CA's root certificate.

Requests

1. When a browser connects to the server protected by the SSL protocol, it will attempt to connect using a SSL handshake.
2. The server has already installed the SSL certificate, so now it can make a copy of the SSL certificate and share the public key to the browser.
3. The browser receives the SSL certificate copy and public key. It then checks whether or not the SSL certificate is trusted, by checking against list of trusted CAs.
4. If the certificate is trusted, the browser creates a symmetric session key using the server's public key and sends it to the server.
5. The server is the only entity with the private key. When it receives a symmetric session key from the browser, it decrypts the session key using the private key, and acknowledges the browser as a trusted host.
6. The server and the browser will now encrypt data using the shared symmetric session key. The SSL handshake is complete (and near-instantaneous)

F.A.Q.

• What are example use cases that SSL attempts to resolve?
  • A hacker can eavesdrop a connection between the client and server, and hijack it so that the traffic being sent from the client becomes directed to some other malicious server. The client has no way of knowing whether or not all of the traffic being sent from it is sent to the rightful server.
• So what does the 3rd party SSL certificate giver do in a nutshell?
  • The certificate provider verifies that the HTTPS server legitimately exists on that domain
• Is SSL encryption using public key cryptography or private key cryptography?
  • Actually, it uses both. The server uses public key cryptography to generate a public key, to be shared among the clients (i.e. browsers). If the browser is trusted, it use this public key to encode a secret key that acts as a handshake of trust between the client and server. This handshake key is the private key cryptography; it only generates one key as opposed to two, and it is orders of magnitude faster than public key cryptography. (AES is a popular private key encryption algorithm.) This is ideal since once trust is established between two hosts, data should be transferred as quickly as possible using a faster encryption algorithm.