Digital certificates

The TLS protocol relies on public key encryption. The sending computer uses the public key of the receiving computer when encrypting data. Before that happens, though, TLS requires a step that is crucial to its security: the sender must verify the identity behind the public key.

A digital certificate, also known as a public key certificate or identity certificate, proves the ownership of an encryption key.

What would happen if TLS did not include a certificate verification step?

Attackers have come up with ways to intercept a request from one computer to another computer on the Internet, such as through rogue access points.

From here, they can launch a man-in-the-middle (MITM) attack. Even though it's called a "man" in the middle attack, attackers come in all ages and genders. You can also think of it as a "masquerader in the middle".

First, during the process of setting up a secure connection with TLS, an attacker sends the client their own public key instead of the server’s public key.

After that, whenever the client encrypts data with the received public key, they're instead encrypting data with the attacker’s public key. The attacker can then decrypt the encrypted message, change it however they'd like, and re-encrypt it with the server’s public key before sending the data to the server.

To prevent a MiTM attack, the client needs to check the identity behind a public key. A digital certificate shows the identity behind a public key. However, if anyone can make them, how can a client trust the legitimacy of a digital certificate? In TLS, clients trust a digital certificate if it was generated by institutions known as certificate authorities.

A server that wants to communicate securely over TLS signs up with a certificate authority. The certificate authority verifies their ownership of the domain, signs the certificate with their own name and public key, and provides the signed certificate back to the server.

When the client inspects the certificate, it can see that a certificate authority is vouching for the authenticity of the public key. But it still has a decision to make: does it trust that certificate authority?

Clients generally come bundled with a list of trusted certificate authorities. For example, an Apple iPhone running iOS 10 trusts this list of certificate authorities.

Apple users then have to trust Apple to continually monitor that list to make sure each certificate authority is verifying domains properly.

You can imagine a chain of trust from the user to the server:

At each point, trust can be broken. If the user doesn't trust the client, they can override the client's default list of trusted certificate authorities. If a client no longer trusts a certificate authority, it will remove it from the list. If a certificate authority sees suspicious behavior from a server, it can revoke its certificate.

There are actually multiple levels of certificate authorities: the root certificate authority and intermediate certificate authority.

The root CA does not actually directly issue any digital certificates for servers. It only issues digital certificates for intermediate CAs that act on its behalf. The intermediate CAs can either issue digital certificates for another intermediate CA, or for a server directly.

Thus, there is another chain of trust, from the root CA to the server:

The layers of certificate authorities increase the security of the system. If a root CA discovers that an intermediate CA has been compromised by an attacker, they invalidate the certificates from that CA but continue trusting the certificates from their other intermediate CAs.

🔍 You can see the chain for yourself when you check the certificate for a secured website in the browser. If you click the lock next to the URL, the browser should offer a way to inspect the certificates.

🙋🏽🙋🏻‍♀️🙋🏿‍♂️Do you have any questions about this topic? We'd love to answer—just ask in the questions area below!