You may recall that in a previous blog post on asymmetric cryptography, I showed you how we can use digital signatures to authenticate the person on the other end. Well there’s more to the story!

Suppose Bob signs a message with his private key and we want to verify his digital signature by decrypting that message with his public key, how we do we know if Bob’s public key is really his?

The truth is that if an attacker, Mallory, had signed the message with her private key and masqueraded her public key as Bob’s, we would have no way of knowing. So we need a way to trust that our public key indeed belongs to Bob, otherwise our digital signature would be pointless.

There are lots of ways to verify ownership of a public key, but the most common right now is to use Digital Certificates.

So say we want to verify Bob’s digital signature again. Bob signs a message with his private key but this time his public key is written on a digital ceritificate. Now we can verify Bob’s ownership of that public key by validating that certificate.

Certificate Authority

In order to validate the certificate, we need to look to a trusted 3rd party. That’s where a Certificate Authority (CA) comes in.

Say a server has a public key and wants its clients to trust it. The server would take that public key and put it in a Certificate Signing Request (CSR), which is then sent off to a CA. The CA does the appropriate ID checks and, if everything checks out, issues a certificate.

certificate

The certificate contains the server’s public key and some other information like the issuer of the certificate, the subject of the certificate, the usage of the key, and the valid from/to dates1. Lastly, the CA adds their own digital signature to the certificate, signed using their own private key.

As you may have guessed, the problem is now how do we trust the CA’s digital signature? In other words, how do we know the CA issued this certificate, and not that pesky attacker Mallory again? We need another CA to issue a certificate that validates this CA’s certificate!

Chain of Trust

Say we issue a second certificate to verify the digital signature of the first certificate. Now we need a third certificate to verify the digital signature of the second certificate. Using certificates in a chain like this is called a Chain of Trust.

chain-of-trust

Each certificate’s public key is used to verify the next certificate’s digital signature.

Root Certificate

Eventually, we need a certificate that’s issued itself. That is, the issuer must be the same as the subject, and its digital signature must be signed with its own private key (i.e. self-signed). We call this certificate the Root Certificate.

root-certificate

The reason we trust the root certificate is because it’s already on our device. Companies like Microsoft, Google, Apple, etc. will decide which root certificates are allowed on their devices. So when you visit a website and the server sends you a certificate, you use an intermediate certificate to verify the server’s certificate, and then you use your root certificate to verify the intermediate certificate.



  1. The from/to dates are very important because we don’t want this certificate to be used forever or that would itself present a security risk. ↩