Understanding SSL and TLS Certificates

November 2 2013

Many web developers and sys-admins will from time-to-time have to install SSL certificates on websites to make them secure. This is usually done by searching online for 'Apache SSL HowTo' or similar. Doing it is usually straight-forward, but without fully understanding what you're doing, it can be a dangerous and confusing process.

Understanding SSL and TLS Certificates

I recently had to renew one of my SSL certifcates, so went straight to my notes to find out how I did it last year, but as fate would have it, I didn't make any notes last year.

SSL/TLS Basics

The basic idea behind an SSL certificate (or TLS certificate) is two-fold:

  • Enable encryption between two points, usually between client and server.
  • Provide a mechanism for one party to identify themselves as being who they say they are.


When sending sensitive information over the Internet, it's important to encrypt that information to ensure only the designated recipient can view it.

The original type of encryption involves encrypting data with a private key.  Data can be encrypted and decrypted only by people who have a copy of the private key.

This is a good approach, but getting that private key to the people who need it can be somewhat tricky, especially over the Internet.

Public Key Encryption

An alternative approach to original encryption is known as public key encryption, or PKI (Public Key Infrastructure).

Public Key encryption involves a private and public key-pair.  Data can be encrypted with either, and decrypted with the other.

If you want to send some sensitive data to someone, you need their public key to encrypt it.  Only the person with the private key can then decrypt it.  It doesn't matter who has a copy of the public key, hence the name.

Certificate Trusted Identity

Encrypting data and sending it to someone is fine, but how do you know the person you're talking to is who they say they are?

The other use of SSL certificates is to be able to be able to prove your identify.  SSL/TLS certificates are signed by a Certificate Authority (CA) who guarantees their identity.

Only these signed certificates (signed by a trusted authority), will be trusted by your browser.

SSL Certificate Content

An SSL certificate contains the public key, to enable you to encrypt data designated for the owner of the certificate, and also proves they are who they say they are.


SSL (Secure Socket Layer) was originally developed in 1994 by Netscape.  It has versions 1.0 (never released), 2.0, and 3.0.  

TLS (Transport Layer Security) was defined in 1999 and replaces SSL, they are basically the same thing.

SSL and TLS sit between (and are completely oblivious to) the application layer (HTTP, SMTP, etc.) and the network transport layer (TCP).

Requesting an SSL/TLS Certificate

To get an SSL certificate, you need to ask a certificate authority.  These cost around £10 for a basic domain-only certificate.  These are the most common, and used to prove the identity of a domain.  At the other end of the scale are EV (Extended Validation) certificates, required by banks, etc. costing around £250.


All of the examples from now on will be using the openssl package on the Linux command-line.  Other packages are available for other systems.

Creating a Private Key

All certificates contain a public key, which is related to a private key, so the first step is to create a new private key.

You can have many private keys in operation for various certificates, and/or use the same private key for all your certificates.

$ openssl genrsa -des3 -out server.key 1024
Generating RSA private key, 1024 bit long modulus
e is 65537 (0x10001)

If you look in the resulting file (server.key) you'll see the contents are in PEM (Privacy Enhanced Mail) format, a simple Base64 encoding.


By default the private key will have a passphrase associated with it.  This is an extra level of security, but can also be annoying if using it with Apache for example; you'll have to enter the passphrase each time Apache restarts.

To create a key without a passphrase, just omit the -des3 flag

$ openssl genrsa -out server.key 1024

You can also remove the passphrase on an existing key

$ openssl rsa -in server.key -out server.key.unsecure

To change the passphrase on a key (you'll need to enter the original one first)...

$ openssl rsa -des3 -in server.key -out server.key.new

Certificate Signing Request (CSR)

To request a certificate, you'll usually need to produce a Certificate Signing Request, this is basically a small text file containing some details.

$ openssl req -new -key server.key -out server.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [XX]:.
State or Province Name (full name) []:.
Locality Name (eg, city) [Default City]:.
Organization Name (eg, company) [Default Company Ltd]:.
Organizational Unit Name (eg, section) []:.
Common Name (eg, your name or your server's hostname) []:lavoco.com
Email Address []:.

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

The Common Name is the only important bit here.

Certificate Authorities are usually quite sensible and will include both the bare domain and the www record in the certificate, as alternative names.

If you want more sub-domains to be covered by the same certificate, you'll probably want to look into wildcard certificates, or talk to the certificate authority about adding extra individual sub-domains.

The CSR is also in PEM format...


To look at the contents...

$ openssl req -noout -text -in server.csr
Certificate Request:
        Version: 0 (0x0)
        Subject: CN=lavoco.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha1WithRSAEncryption

You can see the public key in the CSR, which was created based on our private key.  The public key needs to be in the CSR so the certificate authority can put it in the SSL certificate.

When you receive your certificate it will no doubt be in PEM format also.


To view the contents...

$ openssl x509 -noout -text -in server.crt

The CSR can now be safely deleted.

Installing SSL Certificates

Installing SSL certificates is usually straight forward, but there are usually a few variations.

You should have 2 files, the private key, and the certificate, both in PEM format.

  • server.key
  • server.crt

To install these files, you'll need to tell the various programs where the files are.  The private key should be kept in a secure location with restricted permissions.

Some applications allow you put the private key and certificate in the same file, this can keep things a bit simpler, I use the .pem extension to indicate this.

SSL/TLS for Email

You can use an SSL certificate to secure a variety of services.  I used mine to secure Exim for SMTP, and Dovecot for IMAP.

It's simply a case of telling each program where the private key and SSL certificate is.  Dovecot didn't allow them to be in the same file from what I could see.

Intermediate SSL Certificate Authorities

Your browser is usually shipped with various root certificates from well-known certificate authorities, such as Verisign, Thwarte, etc.  When a server provides a certificate, it is checked against this list in your browser to ensure it is valid.

On some occassions, the root certificate is not the one used to sign your certificate directly, and the certificate authority may have used an intermediate certificate (itself created from the root certificate).  This was the case with my new certificate from StartSSL (which is free).

My browser did have this intermediate certificate installed, but my email client didn't.  I used the same certificate to secure Exim, but Thunderbird complained that the certificate was not signed by a root certificate it shipped with.

The solution to this was to include the intermediate certificate in my certificate .pem file, so it is passed along with my certificate to complete the chain, between my certificate, and the root certificate in my email client.

Leave Comment
Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated. So, please do not use a spammy keyword or a domain as your name, or it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!