What is SSL?

 

SSL (Secure Sockets Layer) and its successor, TLS (Transport Layer Security), are protocols for establishing authenticated and encrypted links between networked computers. Although the SSL protocol was deprecated with the release of TLS 1.0 in 1999, it is still common to refer to these related technologies as “SSL” or “SSL/TLS.” The most current version is TLS 1.3, defined in RFC 8446 (August 2018).

Read on to find out more about:

Or, for a quick TL;DR introduction to SSL, just jump ahead to watch a short video.

Keys, Certificates, and Handshakes

 

SSL/TLS works by binding the identities of entities such as websites and companies to cryptographic key pairs via digital documents known as X.509 certificates. Each key pair consists of a private key and a public key. The private key is kept secure, and the public key can be widely distributed via a certificate.

The special mathematical relationship between the private and public keys in a pair mean that it is possible to use the public key to encrypt a message that can only be decrypted with the private key. Furthermore, the holder of the private key can use it to sign other digital documents (such as web pages), and anyone with the public key can verify this signature.

For a detailed comparison of the two most widely-used digital signature algorithms used in SSL/TLS, please read our article, Comparing ECDSA vs RSA.

If the SSL/TLS certificate itself is signed by a publicly trusted certificate authority (CA), such as SSL.com, the certificate will be implicitly trusted by client software such as web browsers and operating systems. Publicly trusted CAs have been approved by major software suppliers to validate identities that will be trusted on their platforms. A public CA’s validation and certificate issuance procedures are subject to regular, rigorous audits to maintain this trusted status.

Via the SSL/TLS handshake, the private and public keys can be used with a publicly trusted certificate to negotiate an encrypted and authenticated communication session over the internet, even between two parties who have never met. This simple fact is the foundation of secure web browsing and electronic commerce as it is known today.

Not all applications of SSL/TLS require public trust. For example, a company can issue its own privately-trusted certificates for internal use. For more information, please read our article on Private vs. Public PKI.

SSL/TLS and Secure Web Browsing

 

The most common and well-known use of SSL/TLS is secure web browsing via the HTTPS protocol. A properly-configured public HTTPS website includes an SSL/TLS certificate that is signed by a publicly trusted CA. Users visiting an HTTPS website can be assured of:

  • Authenticity. The server presenting the certificate is in possession of the private key that matches the public key in the certificate.
  • Integrity. Documents signed by the certificate (e.g. web pages) have not been altered in transit by a man in the middle.
  • Encryption. Communications between the client and server are encrypted.

Because of these properties, SSL/TLS and HTTPS allow users to securely transmit confidential information such as credit card numbers, social security numbers, and login credentials over the internet, and be sure that the website they are sending them to is authentic. With an insecure HTTP website, these data are sent as plain text, readily available to any eavesdropper with access to the data stream. Furthermore, users of these unprotected websites have no trusted third-party assurance that the website they are visiting is what it claims to be.

Look for the following indicators in your browser’s address bar to be sure that a website you are visiting is protected with a trusted SSL/TLS certificate (screenshot from Firefox 70.0 on macOS) :

address bar

  • A padlock icon to the left of the URL. Depending on your browser and the type of certificate the website has installed, the padlock may be green and/or accompanied by identifying information about the company running it.
  • If shown, the protocol at the beginning of the URL should be https://, not http://. Note that not all browsers display the protocol.

Modern desktop browsers also alert visitors to insecure websites that do not have an SSL/TLS certificate. The screenshot below is of an insecure website viewed in Firefox, and shows a crossed-out padlock to the left of the URL:Firefox 69 (macOS)

Obtaining an SSL/TLS Certificate

 

Ready to secure your own website? The basic procedure for requesting a publicly trusted SSL/TLS website certificate is as follows:

  • The person or organization requesting the certificate generates a pair of public and private keys, preferably on the server to be protected.
  • The public key, along with the domain name(s) to be protected and (for OV and EV certificates) organizational information about the company requesting the certificate, is used to generate a certificate signing request (CSR).
    • Please see this FAQ for instructions on generating a keypair and CSR on many server platforms.
  • The CSR is sent to a publicly trusted CA (such as SSL.com). The CA validates the information in the CSR and generates a signed certificate that can be installed on the requester’s web server.
    • For instructions on ordering SSL/TLS certificates from SSL.com, please see this how-to.

SSL/TLS certificates vary depending on the validation methods used and the level of trust they confer, with extended validation (EV) offering the highest level of trust. For information on the differences between the major validation methods (DV, OV, and EV), please refer to our article, DV, OV, and EV certificates.

Video

Thank you for choosing SSL.com! If you have any questions, please contact us by email at Support@SSL.com, call 1-877-SSL-SECURE, or just click the chat link at the bottom right of this page.