SSL Certificates - an easy to understand guide

As with any technology, I think it's very important that first we understand the problem that this technology is trying to solve. Let's try to understand the problem through an example.

Problem with sending messages in plain text

We are operating a website where we are selling some fancy coffee. For completing purchases we need payment information from our customers. Our customer, Bob, is sitting in a coffee shop and is trying to buy our newest product on sale. He just connected his laptop to a shady public Wi-Fi that is controlled by a hacker who can read the traffic that goes through this network. If we are sending the payment information in plain text the hacker is able to intercept the traffic and can easily read the payment information that is sent.

Encryption to the rescue

(Encryption is a very big topic on its own and I am over simplifying things in this section, but this is enough for us to understand the big picture.)

The simplest and quickest form of encryption that we can use is symmetric encryption. In this case there is a single key that can both encrypt (lock) and decrypt (unlock) messages.
In our story Bobs laptop can generate a random key and send it to our website. After both the website and Bobs laptop agreed on this shared key all the following communication can be encrypted with it and there would be no more plain text messages to capture.

BUT! What if the hacker also intercepted Bobs first message, the one that contained the secret key? In this case the hacker would also know the key and would be able to decrypt the messages.

Asymmetric encryption

When using asymmetric encryption we have a pair of keys - a private and a public key. If something is encrypted with one of the keys it can only be decrypted with the other one and vice versa.
The beauty of this setup is that the website server can share its public key freely. By doing this the clients can encrypt messages using the public key of the website and be sure that only the website can read the message.

In our example Bobs browser would not send the symmetric key it generated in plain text, but instead it would encrypt it using the websites public key. Because this messages can only be decrypted by using the private key we can be sure that only the website can read this message.

So to recap: The client (Bobs browser) generates a (symmetric) key. Encrypts it using the public key of the web server and sends it. The web server can decrypt the message using its private key. Now both the web server and the client have the key that will be used for further communication.

And finally we can send those credit card information... BUT! What if we are dealing with a really skilled hacker?

Man-in-the-Middle Attack

Our setup is still vulnerable. The problem is that a skilled hacker that controls the Wi-Fi network could intercept all the messages from the client and impersonate the web server. In this case the hacker could send its own public key to the client, acting as the real website. The hacker can act as a middle-man, forwarding the content between the client and the original website. In this case the client would have no way to know that he is not talking with the real website.
Since the public key is just a very big random number it doesn't carry any more information about its source. When the client receives a public key it cannot be sure that this key really belongs to the website he is trying to connect to.
SSL Certificates were invented to solve this problem.

SSL Certificates

An SSL Certificate in its most basic form works just like an identity card. The ID card certifies that the information from the ID card belongs to the person from the photo. You trust the information on an identity card because you trust the issuer of the card, the government.
A SSL Certificate certifies that a given public key belongs to a given domain or IP address and it is signed by a third party (CA - Certificate Authority) organization. If you trust the authority who signed it, then you can trust the certificate.

These formal definitions like, "certificate" and "authority" may seem overwhelming, bug there is nothing complicated about SSL Certificates. A certificate is just a piece of data with a standard format (X.509 is the name of the standard).

What is a certificate?

• validity (the period during which the certificate is vaid)
• domain name of the subject (CN)
• more information about the subject (company name, county, etc)
• public key of the subject
• information about the issuer of the certificate (CA)
• signature

The certificate is sent to the client in base 64 encoded format and it looks similar to the following example:

Ok, so the server instead of just sending its public key it sends a certificate that contains the public key, some extra information and a signature from a third party (CA - Certificate Authority).

Can the hacker just send its own public key along with the signature of the web server?

The hacker can get the certificate of the web server - it is public information. And since the certificate is just a block of information - the hacker could send the its own public key together with the signature from the certificate of the web server. So this is a valid question...

The trick is that the signature of the certificate is created by hashing all of the data from the certificate and encrypting it using the private key of the Certificate Authority.
When Bobs browser receives the certificate it will decrypt the signature using the public key of the Certificate authority and it will compare the data from the signature with the content of the certificate. In this case the browser would notice that the public key from the certificate doesn't match with the one that was encrypted in the signature.

Who can sign a certificate?

Basically anyone... A certificate is basically singed by a private key. This signing private key in turn has a public key and also a certificate of the public key. And in turn this certificate is also signed, forming a chain of certificates.
A certificate can also be self-signed, this would be the root certificate.
A certificate is trusted by the browser if it trusts the root certificate. The operating system and the browser have lists of pre-installed Certificate Authority certificates they trust (such as DigiCert, Go Daddy, Let's Encrypt, etc.)

Summary

Here is a short summary of what happens when Bob needs to send his credit card information to our web server securely using a public wifi.

Our web server has a public and a private key and we have a certificate about the public key from Let's Encrypt. When Bob tries to connect to our website we first send him our certificate. Bobs browser looks at the root certificate of our certificate and decides that it can trust it. It can trust it since the certificate of the CA (Let's Encrypt in our case) is trusted by the browser. Bobs browser decrypts the signature of our certificate using the public key of the CA and compares it to the content of our certificate. After the certificate is found to be valid Bobs laptop generates a secret key. Encrypts this secret key using our public key from our certificate and sends it to our web server. From now on all the communication between us will be encrypted using this secret key - our communication is secure.

Your feedback is welcome! Please let me know if you think there is something important that should be included in this post or if you find anything wrong!

Comments available on dev.to