A Crash Course in Certificates

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

6 min readOct 9, 2020

Audience and Aim

This article is for developers who are currently using certificates and want to concrete their practical knowledge. We won’t dive deeply into details, but will give a pragmatic overview of the different areas required for their understanding.

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?

Argument

What is a certificate for?

Normally, communication across the internet is insecure. Certificates are used to add a layer of security. This manifests itself in three ways:

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?

You get a digital certificate from a recognized Certificate Authority (CA). To do this you need to generate a private/ public key pair. From these you generate a Certificate Signing Request (CSR) and send it to the CA. They will then return you a .crt file (your 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:

But who gets to be a certificate authority?

Certificate Authorities can be a government run or private company, however regardless of who they are they need to meet a number of fairly stringent requirements.

What is in a certificate?

The contents of a certificate are actually fairly minimal, resembling something similar to the below:

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

How do I use a certificate?

Usually a server will be set up to provide a client browser with a certificate. A server provides its certificate, along with its signature, which is then verified by the client browser to prove it came from one of a list of trusted CAs (as we saw earlier).

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?

Your certificate groups your public key, domain name and organization details. But how do we use this to send messages securely?

Example of a client and server establishing a secure connection

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

Client Hello: The client begins the handshake and tells the server a little bit about itself.
Server Hello: The server looks at the client capabilities and chooses its connection settings.
Server Sends Certificate: This is the step where we send over our certificate to the client.
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.
Server Hello Done: Server sends a message saying it is done with its initial part of the communication.
Client Key Exchange: Like the server did, the client will also send additional settings to generate a master secret.
Client Change Cipher Spec: Client switches to symmetric encryption and tells the server.
Finished: The client tells the server the connection is established.
Server Change Cipher Spec: Now the server switches to symmetric encryption.
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?

A CA controls something called a root certificate. This is used to sign, and therefore authenticate, other certificates (like our one) making it very valuable. Too valuable to use directly!

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:

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)

There are a couple of types of certificate, Domain and Extended validated.

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

The final thing we will cover is how we specify which domain our certificates cover. We can have several different domain names in a single certificate by purchasing a certificate with SAN (Subject Alternative Name).

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:

example.com
example.org
example.net
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!

Conclusion

In this article we have covered the basics of certificates and how, on a practical level, they are used to secure internet communication.