Certificates Demystified – root versus self signed, private versus public key

I struggled a lot with understanding the nuances of security certificates – self-signed versus root certs, public keys versus private keys versus Certificate Authorities (CAs)….This post will attempt to clarify some of the key (no pun intended) concepts.

What is the issue being Addressed?

I would like my website to communicate with Sheila’s website (everyone uses Alice, I figured, it was time to give Alice a break).  The trouble is that I want to be SURE , 100 % sure that the person (website) claiming to be Sheila – is INDEED Sheila.

This is required because a LOT – a LOT of impersonators can claim to be Sheila – thereby intercepting all my traffic. To avoid this, I need to be able to trust Sheila. In addition, she needs to be able to trust me as well.

Rather than relying on each other, we decide to go to a middleman (CA). This middleman is what is known as the Certificate Authority – or Trusted Third Party (TTP). An example would be a company like VeriSign.

What does the Certificate Authority need to do?

The CA will create a master key, also known as root CA key. The private key will be kept secret by the CA at all cost.

The public key will be embedded into a certificate, and this certificate will be signed by the public key of the CA.

Let us  assume that you want to access Sheila’s website, but you want it to really be Sheila’s website and not another person that claims to be her. Sheila is part of you community and therefore contacts the CA you agreed to use. She sends the CA a CSR (Certificate Signing Request) which basically is a public key. The CA will conduct the process of verifying that Sheila is Sheila (for example, the responsible person meets Sheila in person and get the CSR from her hands). When the CA is sure Sheila is Sheila and the CSR belongs to her, the CA can create a certificate in the name of Sheila and sign this certificate with the CA private key.

What does Sheila Need To Do?

Sheila is known to you  and therefore proceeds to contact the CA you both agreed to use. She first sends the CA a CSR (Certificate Signing Request) which is essentially a public key.

The CA will carry out the process of verifying that Sheila is Sheila (for example, by meeting Sheila in person and having her hand out her CSR).

Back to the CA

Once the CA has verified that Sheila IS indeed Sheila, they CREATE a brand new certificate for Sheila and sign it with the CA Private key. Let us call this ‘Sheila’s Website Certificate’. Now, finally, YOU enter the picture !

What do YOU need to do?

When your browser connects to Sheila’s website, you ask Sheila to produce a certificate (the Sheila’s Website Certificate). Once you obtain this certificate, you need to verify that it IS the correct certificate. You can see inside the certificate that it has been issue by a CA. If you have the CA key (public key), you can verify the signature. If the signatures match, you KNOW that the cert was ISSUED by the CA – and no one else. You also know that Sheila is who she claims to be because the CA is assuring you that they have validated Sheila.

Future messages encrypted with this public key will only be read by Sheila who has the corresponding private key (got it when they handed over the certificate).

Root versus Self Signed – Root means CA issued, Self signed means YOU issued

The private key created by the CA to sign Sheila’s and your certificates – is called the ROOT key. If, for any reason, you do NOT involve the 3rd party (CA), you can still create a 2-way web of trust between yourself and Sheila.. In this case, YOU act as the CA – and you have the ‘root’ key. This, however, is not called a root certificate – it is called self-signed.

If you happen to own both endpoints (and may have more than two endpoints to work with – say 12 customers each of whom needs an SSL),  then, it makes sense to create your own CA. You generate a root CA certificate then you sign certificate for each endpoints. At each endpoint you can install the public root CA cert. Then each time a endpoint connects to another, the contacted endpoint can send its certificate and the caller can verify it against the root-CA cert.

Summary

It is important to think in terms of a ‘web’ of trust when thinking of certificates. In a typical ‘web’ there are at least three players – You, Sheila and a Certificate Authority (CA).  If you happen to OWN both the endpoints (i.e. – yours and Sheila’s) , then it is possible to eliminate the CA – and use ‘self signed’ certs.  The distinction between CA and non-CA self signed certificates is important – A self-signed certificate’s purpose is to validate a communication partner (e.g. Sheila). It should not be allowed to act as a certificate authority since this might open up additional security implications (i.e. Man In The Middle attacks using said certificate as trusted authority).