Welcome to this first article of a series of three, about the subject of security in networking applications, TLS, certificates, keys, and more.
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!
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
L– Location (City)
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
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.
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.
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.
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.
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!