A quick introduction to SSL/TLS encryption: understanding certificates and key pairs

Confused about SSL/TLS certificates? Here is a quick and dirty introduction to SSL/TLS encryption.

Secure Sockets Layer/Transport Layer Security (SSL/TLS) serves two purposes:

• securing network communications between two parties
• establishing the identity of the party which serves the other party a certificate.

SSL/TLS connections rely on the existence of a key pair.

SSL/TLS keys

An SSL/TLS key pair consists of a private key and a public key. These two keys are related to one another by means of a cryptographic algorithm. The private key is “private” to the server which receives the incoming SSL/TLS connection and must be kept secret. The server introduces itself to the client by handing over its certificate. The certificate is a signed (“certified”) container that includes the server’s public key.

SSL/TLS certificates

In order to ensure the authenticity of the public key that is contained in a certificate, the key must be signed by a trustworthy 3rd party party, a Certificate Authority (CA for short).

SSL/TLS certificates fall into one of two categories:

• PFX (.pfx) certificates and
• .cert certificates (.cert, .cer or .crt).

A .pfx file is a PKCS#12 archive.  A .pfx file typically contains a certificate (possibly with additional CA certificates) alongside the corresponding private key. It can also contain additional objects and offers an optional password protection. You would typically extract the certificate and the private key into separate files to use as needed.

A .cert (or .cer or .crt) file usually contains a single certificate, alone and without any wrapping (no private key, just the certificate); it also lacks password protection because there is nothing to protect (the public key does not need protecting).