In times of DevOps, developers are dealing more and more with certificates. In my career as a consultant, I have noticed that this often leads to the greatest confusion. I’d therefore like to dedicate today’s TechUp to this topic.
First a few basic terms 🔐
SSL (Secure Socket Layer)
SSL is an encryption protocol developed by Netscape, which first appeared in version 1.0 in 1994. In 1995 SSL 2.0 was released, and just a year later SSL 3.0. However, all of these versions are no longer permitted today. In 1996, Netscape passed version control to the IETF (Internet Engineering Task Force), for the development of an Internet standard.
TLS (Transport Layer Socket)
After the handover, the IETF developed the improved protocol TLS in version 1.0 on the basis of SSL 3.0, which appeared in 1999. However, this is no longer supported because, among other things, it no longer conforms to the payment transaction standard (PCI DSS). In 2006, version 1.1 of TLS was released. However, since SHA-1 is used here to create the signature, its use is not recommended. In 2008, TLS 1.2, which is still valid today, was released. Since 2018 there has also been TLS 1.3 which contains new requirements for TLS 1.2.
Cipher Suites
A Cipher is simply an algorithm, or collection of steps, to perform mathematical calculations (RSA). Messages are encrypted using this algorithm. There are currently 37 ciphers for TLS 1.2 and five ciphers for TLS 1.3. Cipher Suite is a combination of ciphers. There are four different types of ciphers:
-
Key Exchange Algorithms (RSA, DH, ECDH, DHE, ECDHE, PSK)
-
Authentication/Digital Signature Algorithm (RSA, ECDSA, DSA)
-
Bulk Encryption Algorithms (AES, CHACHA20, Camellia, ARIA)
-
Message Authentication Code Algorithms (SHA-256, POLY1305)
Here’s an example of what a cipher might look like:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS is the protocol.
- ECDHE (Elliptic Curve Diffie Hellman) is a cipher with which the keys are exchanged during the handshake.
- RSA is the authentication mechanism.
- AES_128_GCM Is the bulk encryption mechanism (so the actual data encryption).
- SHA256 is the hashing algorithm.
X.509
X.509 is a public key infrastructure standard for creating digital certificates. X.509 certificates apply to TLS versions of various transmission protocols (HTTPS, S/MIME).
What do you need certificates for?
On one hand, certificates are there to take care of user/client identification, and on the other hand they are responsible for encrypted communication. A distinction is made between two types of certificates; the client certificate (PKI) and the server certificate (SSL-Certificate).
Encryption
There are several ways to encrypt information. The simplest is to encrypt the message with a key and send it to the recipient. Since the recipient has the same key, he can decrypt this message again.
However, this method cannot really be used on the Internet, because otherwise you would have to know the key of every website with which you want to communicate securely. This is of course not possible, because the key could only be obtained in an unencrypted way. For this reason there is the so-called Public Key Procedure. In order for this process to work, however, an infrastructure is first required.
Public Key Infrastructure
We’ve all heard of PKI, or Public Key Infrastructure when it comes to certificates. In cryptology, a PKI is a system that can issue, distribute and check digital certificates. The most important components of a PKI are:
- Certificate Authority (CA)
- Registration Authority (RA)
- Validation service (VA)
- X.509 Digital Certificates
- Directory services for certificates
- Certificate Revocation Lists
The way a PKI works is as follows:
Chain of Trust
Let’s take a look at how a PKI is used in practice. The greatest asset of a PKI is the root CA (Root Certificate Authority). This serves as a “trust anchor” and must be specially protected. If the root CA is hacked, the entire PKI is no longer trustworthy and all certificates issued by it must be revoked. For this reason, only a few people have access to the root CA, which by the way must ONLY be kept offline.
This is why there are CA hierarchies. Let’s look at which CA’s are in this hierarchy.
Root Certificates
The heart of a PKI. Each CA has only a few root certificates. The public key of a root certificate, for example, is also stored in the browser so that all certificates issued by the root CA are trusted (Chrome CA’s).
Intermediate certificates
An intermediate certificate is issued by a root certificate. After the intermediate certificate has been signed by the root certificate, the root certificate is no longer needed to issue further certificates.
Server Certificates
This certificate is signed by an intermediate certificate. It is issued specifically for a user or domain name.
Example of validation
We now know the three levels of hierarchy. Now let’s look at a small example of how a server is validated.
A user views the page https://b-nova.com in the Chrome browser. We can see from the lock next to the address that the connection is secure and our certificate is valid.
Now let’s look at the certificate in detail.
The certificate for the website was issued by LetsEncrypt. This in turn was issued by ISRG Root X1. The root certificate was stored in the browser and the connection is therefore considered secure. In order for the website to be trusted in the browser, the server must deliver both the domain certificate and the intermediate certificate.
If the server were to only deliver the server certificate (b-nova.com), we would receive a certificate error because the entire chain could not be validated.
Server Certificates
Server certificates are used to authenticate a server. An SSL/TLS certificate (or Server Certificate - we’ll call it SSL certificate for simplicity) is also the basis for encrypted communication with a website. For example, phishing attacks (faking an identity) are prevented.
The name SSL certificate is misleading in this context. Based on the name, one might think that the certificates are tied to a specific protocol, which is not the case. Rather, a certificate is only used to implement SSL or TSL.
Structure of an SSL certificate
An SSL certificate contains the following information, among other things:
-
Unique serial number
-
Holder of certificate (Company)
-
Certified domain
-
Validity
-
Algorithms used
-
Exhibitor (CA = Certificate Authority)
-
Signature of the CA
-
Fingerprint
-
Public key
How SSL works
To establish a secure connection, an SSL/TLS handshake is performed. We’ll look at this using the example of an HTTPS connection between a browser and a server.
Let’s say you visit the page b-nova.com.
-
Browser and server say “hello” and agree on the cipher suite to be used for encryption.
-
The server sends its SSL certificate (Public Key included) to the browser.
-
The browser checks the SSL certificate using the root certificate stored in the browser. If this check is correct, the browser creates a session key and encrypts it with the public key of the server and then sends it back to the server.
-
The server decrypts the session key with its private key. If this decryption is successful, the handshake is complete. Up to this point, asymmetric encryption took place because servers and browsers encrypt and decrypt their messages with different keys.
-
From this point on, browser and server only communicate via the session key, which is encrypted symmetrically.
Client Certificates
A client certificate is used to authenticate a user or “client”. However, it is not used to encrypt the communication. For this reason, a client certificate only makes sense if a server certificate is used at the same time, since this encrypts the data. Like server certificates, client certificates are based on PKI.
If you want to use a client certificate, the server requests the certificate from the client as an additional step. The client sends the certificate and checks it against the issuer certificate stored with it.
We see in the graphic that the server makes a “Certificate Request”. It requests the client certificate from the client. The counterpart to this is then stored on the server itself so that it can authenticate the client.
Conclusion
Hopefully, I’ve been able to give you a little more insight into how certificates work in general, and what differentiates server and client certificates. Here you will find more exciting b-nova TechUps. Check it out!
