A Crash Course in Certificates

I understand certificates, or at least I think I do…

Hacker at his desk

Audience and Aim

Please note, this article does assume you have a basic understanding of public and private key infrastructure!

We aim to answer the below questions:

  • What is a certificate for?
  • How do I get a certificate?
  • What is a certificate authority?
  • What is in a certificate?
  • How do I use a certificate?
  • How does a certificate work?
  • What are certificate chains?
  • How do Domain Validated Certificates and Extended Validation Certificates differ?
  • What are SAN, Single Domain and Wildcard certificates?


What is a certificate for?

  • Confidentiality: Certificates make sure no-one sees what is in your messages. This is done via the encryption process.
  • Authenticity: Certificates make sure that whoever you are communicating with is who they say they are. This is done via the signing process.
  • Integrity: Certificates make sure your message gets from A to B without being altered.

The overall process of securing communication in this way is known as TLS/ SSL.

How do I get a certificate?

This file is signed by the issuing Certificate authority, and is what guarantees it. When someone receives a message from you, they verify that the certificate you used was approved by someone they trust!

To have a go at generating your own CSR you can run the below:

openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr

Fill in the information you are prompted for. This will generate you a private key (server.key) and a CSR (server.csr)!

You can also view your browser’s trust store. This is the list of CAs you can have a certificate issued by, and then use for that browser. In Firefox I can see these in the settings:

List of trusted CAs in Firefox

But who gets to be a certificate authority?

What is in a certificate?

-----BEGIN CERTIFICATE-----A large random string...-----END CERTIFICATE-----

How do I use a certificate?

We can also use mutual authentication. This is when the client sends a certificate as well as the server, and is used to allow only certain parties to connect to a server.

How does a certificate work?

Example of a client and server establishing a secure connection

The above exchange is called the handshake and establishes a secure connection.

  1. Client Hello: The client begins the handshake and tells the server a little bit about itself.
  2. Server Hello: The server looks at the client capabilities and chooses its connection settings.
  3. Server Sends Certificate: This is the step where we send over our certificate to the client.
  4. Server Key Exchange: Depending on the connection settings we send additional settings to generate a master secret. Once a secure connection is established we use symmetric encryption, encrypting using this master secret.
  5. Server Hello Done: Server sends a message saying it is done with its initial part of the communication.
  6. Client Key Exchange: Like the server did, the client will also send additional settings to generate a master secret.
  7. Client Change Cipher Spec: Client switches to symmetric encryption and tells the server.
  8. Finished: The client tells the server the connection is established.
  9. Server Change Cipher Spec: Now the server switches to symmetric encryption.
  10. Finished: The server tells the client the connection is established.

Once all of the above have completed we have a secure connection!

What are certificate chains?

To counter this CAs generally issue intermediate certificates. The CA signs the intermediate with its private key, making it trusted. This intermediate is then used to sign our server certificate.

We also have the notion of Root CAs and Intermediate CAs. Root CAs issue from a root certificate, however intermediate CAs will issue off an intermediate certificate.

To summarise there are three components to a certificate chain:

  • Root certificate: This is the certificate that a root CA uses to sign a certificate.
  • Intermediate certificates: These stem from a root certificate and form a tree. They act as middle-men between the root and the certificate we own. There must be at least one intermediate, but there can be multiple!
  • Server certificate: This is the certificate we have had issued.

An example is below:

Example of certificate chaining

When we install a certificate we must also install all of the intermediate certificates (in something called a certificate bundle). There needs to be a complete chain of certificates up to the root in order to be trusted!

Domain Validated Certificates (DVC) vs Extended validation Certificates (EVC)

Domain validated certificates are used when an applicant can prove they own the domain specified in the CSR (for example demo.com). A lot of the time this validation process is fully automated, making these the cheaper option.

Extended validated certificates prove a legal entity (such as a bank) controls the domain. This requires the CA to manually verify the entity’s identity and are therefore more expensive.

SAN vs. Single Domain vs. Wildcard

These generally allow you to secure 4 additional domain names in addition to the main domain name. For example you could use the same certificate on:

  1. example.com
  2. example.org
  3. example.net
  4. example.co.uk

This is in comparison to a single domain certificate which only covers the one domain, rather than several, and therefore tend to be cheaper.

The last option is to use a wildcard certificate. We may ask for a certificate for *.example.com which will then cover mail.example.com , api.example.com, test.example.com.

Covering multiple domains can save money and admin time, however if something happens to our private key and we need to revoke this certificate it will affect many more services!


Senior Software Engineer at the BBC

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store