Welcome to the third and last installment of our „Networking Security“ blog post series. If you didn’t read the previous ones yet, go ahead and read the first two parts:

• Part 1: What is TLS?
• Part 2: Verifying and Connecting
• Part 3: Trust and Certificate Chains

In this article we’ll talk about trust, and how it’s implemented thanks to certificate chains.

Chain of Trust

As explained in the previous posts, a server certificate can be signed by a CA certificate in order to confirm their identity. We trust that the CA has verified the contents of the server certificate before signing it, and hence we trust that the contents of the server certificate are valid.

Now, since a certificate that is used to sign other certificates, can in turn be signed by another certificate, we can build a whole „chain of trust“:

• At the top, there is the Root Certificate (also called the Anchor). It is signed by itself (self-signed).
• In between, there may be one or more Intermediate Certificates. They are signed by either other intermediates or the root certificate.
• On the bottom is our server (or client) certificate, called the Leaf Certificate.

In order to verify trust of a leaf certificate, we follow the „certificate chain“ upwards until we reach a root certificate we already know and trust.

Root Certificates

In order to know which root certificates to trust, we must have a „trust store“ containing all the root certificates. This store is usually provided by the operating systems, but some clients (most notably web browsers) have their own „trust store“.

In order for a CA to have its root certificate accepted into the trust store of an operating system or browser, they must meet certain quality criterias. They must prove that they take CSR validation seriously and that they have measures put in place to keep their private key confidential.

Having their private key stolen by an attacker is the absolute worst-case scenario for any CA. It would mean that the attacker could create and sign ANY certificate using the CA’s cert! And since the CA’s certificate is trusted by all operating systems, clients connecting to the attacker would be none the wiser!

The only way to react to a compromised key is to rotate it, that is, to create a new one using a new private key. This however would mean that the certificate also has to be replaced in all trust stores. Since this can take a long time for some operating systems or clients, CA’s usually only use Intermediate Certificates to sign your certificates, and store the root key somewhere safe (and by safe I mean printed out on a piece of paper and stored in an actual safe.)

Intermediate Certificates

As explained, CA’s usually use an Intermediate Certificate to sign your CSR’s. An Intermediate Certificate, in turn, can be signed by either the Root Certificate or another Intermediate Certificate. This means that, in theory, there could be any number of intermediate certificates between your server (leaf) certificate and the Root. In practice, however, there is usually only one or two intermediates.

CA Bundles

In order to verify a certificate, a client must possess the certificate that was used to sign it. So in order to verify the whole chain, it must have each intermediate certificate as well as the root certificate. The root certificate we already have in our trust store. But what about the intermediates?

When a CA has signed your CSR and sends you back the certificate, they will also send you all the intermediate certificates between your server cert and the Root. This is called the „CA bundle“ or „CA chain“.

When we install our Server certificate in our web server, we also provide it the CA bundle. And when a client connects to the server, the server will send along the bundle with the certificate. This is safe because as long as one of the certificates in the chain is signed by a trusted root certificate, we know that we can trust the whole chain.

Note that the root certificate itself must NOT be part of the chain. It MUST come from the client’s trust store! Unfortunately some CA’s have the bad habit to include their root in the CA bundle, so make sure to remove it before configuring your webserver.

If you check your website against SSL Labs‘ SSL Server Test, it will warn you if either intermediates are missing or the root („anchor“) is included.

Closing Words

Congratulations, you’ve made it! You should now have some basic understanding about TLS/SSL certificates, what they do, and how they work!

Thanks to various browser vendors‘ efforts, HTTPS has become the norm when surfing the web in recent years. And now that you’re armed with knowledge, there is no excuse anymore to serve your websites unencrypted!

Welcome to the second article of a series of three, about the subject of security in networking applications, TLS, certificates, keys, and more.

• Part 1: What is TLS?
• Part 2: Verifying and Connecting
• Part 3: Trust and Certificate Chains

In the first part, we learnt about TLS/SSL, certificates, CAs and Keys. If you haven’t read it yet, please do so now.

Now that we know all about the pieces of the puzzle, how do they all fit together? Let’s have a closer look!

Issuing Certificates

To begin with, we need to obtain a certificate. The process works something like this:

First, we need a public/private key pair. With it, we can now create a new CSR (short for „Certificate Signing Request“). The CSR contains all the details we want to include in the certificate (the „Subject“) as well as the public key. We then send the CSR to the CA (the „Certificate Authority“).

The CA then verifies the contents of our CSR, and signs it with their own certificate and private key. This results in a new certificate with the details from our CSR, its „Issuer“ field set to the „Subject“ of the CA’s certificate, and our public key embedded. The CA then sends the new certificate back to us.

And that’s it! We now have a certificate that is signed by the CA, and we have the accompanying private key. We can now install the certificate in our web server.

Establishing Connections

The whole purpose of certificates and keys is to create secure channels through which devices can exchange information, without the risk of snooping by third parties. In other words, security experts call this „being able to send secrets on a postcard“, and all things considered, the analogy is quite appropriate.

So, how do we establish a secure connection with SSL? The following things are required:

1. A (web) server with:
   • A CA certificate;
   • A server certificate;
   • And a server certificate key (with its corresponding passphrase).
2. And a client (usually a web browser) with a list of trusted CA certificates.

With all this in place, we can establish a trusted, secure connection between both:

1. The client opens a TLS connection to the server.
2. The server responds with its certificate.
3. The client verifies that the server certificate was indeed signed by a trusted CA.
4. The client verifies that the server certificate’s CN attribute (part of the „Subject“, remember?) matches the requested URL.
5. The client verifies that the server certificate is not expired.
6. The client can optionally check that the server’s certificate has not been revoked, either by using a CRL (a „Certificate Revocation List“), or a mechanism like OCSP (an „Online Certificate Status Protocol“).

After these steps, the client has established an encrypted connection, and verified that the server it is connected to is indeed the one it claims to be.

The client and the server can now exchange data securely with one another, without the risk of a third party being able to read their interactions, or even worse, manipulating them!

Client Certificates

There is however another use case for certificates, and that is Client Authentication. Remember how in the example above the server’s certificate was used to verify its identity? This works the other way around too!

If we have a client certificate that is signed by a CA known to the server, we can establish a mutually trusted, secured connection.

To achieve this, we need the following things:

1. A server with:
   • A CA certificate;
   • A server certificate;
   • And a server certificate key (with its corresponding passphrase).
2. A client with:
   • A CA certificate;
   • A client certificate;
   • And a client certificate key (again, with its corresponding passphrase).

Once all the things are in place, a mutually trusted, secured connection can be established:

1. The client opens a TLS connection to the server, sending its certificate.
2. The server responds with its own certificate.
3. The client verifies that the server certificate was indeed signed by a trusted root.
4. The client verifies that the server certificate’s CN attribute matches the requested URL.
5. The client verifies that the server certificate is not expired.
6. The client can optionally ensure the server’s certificate was not revoked.
7. The server verifies that the client certificate was indeed signed by a trusted root (our CA certificate in this case).
8. The server verifies that the client certificate is not expired.
9. The server can optionally ensure the client’s certificate was not revoked.

After these steps, both client and server have established an encrypted connection, one in which both parties are who they claim they are. The server can now read the client’s certificate details (mostly the Subject) to identify the client.

And just like previously, our connection is now fully encrypted and all communications flowing through it are confidential.

Coming Up

In the last part of this series, we are going to talk about some technical details about chains, roots, and intermediates. Stay tuned!

Welcome to this first article of a series of three, about the subject of security in networking applications, TLS, certificates, keys, and more.

• Part 1: What is TLS?
• Part 2: Verifying and Connecting
• Part 3: Trust and Certificate Chains

We have noticed that many of our customers struggle to understand how TLS certificates work on a conceptual level. For example, how does „signing“ work? What does it even mean? What are a „chain“, an „intermediate“ or a „root“? Why do intermediates belong to a chain, but not the root? What is a CSR? How do CSR, Key, and certificate work together? And so on.

This series is an attempt to explain these critical concepts to our customers, starting this first part with the basic vocabulary and knowledge to get started.

HTTPS – TLS – SSL

Let’s talk about what we want to achieve first. When you visit a website via plain old HTTP, an attacker could intercept your request and grab any private information like usernames and password. Additionally, there is no way for you to verify that you indeed connected to the server you intended. An attacker could have modified the DNS response (which is also unencrypted) to send your browser to their server instead. See Man-in-the-middle attack on Wikipedia for more examples.

So in order to verify the identity of the server we connected to, and to make sure nobody except the server and our browser can read the data we exchange, websites these days use TLS („Transport Layer Security“, or its predecessor SSL „Secure Sockets Layer“) to both authenticate the server and encrypt the traffic.

From a technical perspective, TLS sits between TCP and HTTP on the protocol stack, and while it’s mostly known for being the S (for Secure) part in HTTPS, it’s noteworthy that it can be used for other protocols as well. Some examples:

• Email protocols: IMAPS, POP3S, SMPTS, …​
• Database connections: MySQL, PostgreSQL, MongoDB, etcd, …​
• Data transfer: FTPS
• Telephony: SIPS
• Chat: XMPPS, IRCS, …​

The last thing to note here is that there are different versions of TLS (and SSL), and some of them are not considered secure anymore!

From oldest to newest, at the time of writing (March 2021):

• SSLv1: Insecure, not supported anymore
• SSLv2: Insecure, not supported anymore
• SSLv3: Insecure, not supported anymore
• TLS 1.0: Insecure, deprecated
• TLS 1.1: Insecure, deprecated
• TLS 1.2: OK
• TLS 1.3: OK

Keep this in mind when planning your environment! You wouldn’t want to protect your brand new microservice with outdated security protocols!

By the way, if you want to check which TLS versions a website supports, use SSL Labs‘ SSL Server Test. It’s a great debugging tool and will show you a lot of information about the topics of this Blog post series!

Certificates

The next thing we should have a look at are Certificates, or more specifically X.509 v3 public key certificates.

A Certificate is a cryptographically signed piece of information, of which the most important part is the Subject, which identifies who this certificate belongs to, as well as the Issuer. Other attributes include details about when the certificate is about to expire as well as a lot of technical information about the key and signature algorithms used, and so on.

The Subject and Issuer of a certificate are characterized by a set of attributes:

• CN – Common Name
• C – Country
• ST – State
• L – Location (City)
• O – Organisation
• OU – Organisational Unit

Together, those attributes form a Distinguished Name (DN). Most attributes are optional, except for the Common Name. In the case of Server Certificates, the CN must match the address used to connect, for example www.vshn.ch.

The Certificate also contains a Public Key (embedded in the certificate) and its matching Private Key.

The last important feature of X.509 certificates is that they are signed by other certificates (or itself). Once a certificate is signed, its contents cannot be changed anymore.

Signing CAs

The Internet is a big place, so how do we know whom to trust? To solve this issue, the concept of Certificate Authorities came up.

A Certificate Authority (commonly referred to as CA) is a central trusted source of certificates. They have a CA Certificate (also known as the „root“ certificate) that is well known and trusted. This certificate is only used to sign other certificates. By signing another certificate, the CA confirms „yes, I trust this certificate and the information in it is correct.“

A related concept is a Certificate revocation list, also known as „CRL“, which is a list of digital certificates that have been revoked by the CA before their scheduled expiration date, and should therefore no longer be trusted.

Now that we have explained what a certificate is, let’s talk about keys.

Keys

Each certificate has its own key. The key makes certificates actually useful; without them, they would not work.

Each key consists of two parts: a public key and a private key. While the public key is embedded as part of the certificate itself, the private key is stored in a different file altogether.

In order to sign another certificate, you need the Private key of the signing certificate (but not of the certificate you want to sign).

When you open a connection to a server, the server also needs the private key of the server certificate in order to authenticate itself and establish encrypted communication.

This whole concept is called Public-key cryptography.

Confidentiality

A very important thing to understand is that the key is the only confidential piece in the puzzle; needless to say, it is the most important piece! So please, keep this always in mind: do not ever exchange keys over unsecured channels, under any circumstances!

On the other hand, the certificate itself is not confidential. The CA certificate in particular must be provided to all clients and servers, in order to verify other certificates.

How can a client ask a CA to sign a certificate? Through a CSR (also known as Certificate Signing Request) which, as the name implies, performs exactly this task.

Coming Up

Speaking about verification and issuing new certificates, we are going to talk about these subjects in detail, respectively in the second and third parts of this series. Stay tuned!