A Certificate Authority (CA) is a crucial part of securing communication. A CA can be public or private: a public CA is an organization that provides digital certificates for a fee, whereas a private CA is an internal server set up to store and issue digital certificates for use within the network. These digital certificates are important for devices to verify they are who they say they are.
To explain why CAs are important, consider this scenario:
You need to make a payment so you open up your browser and type in your bank’s website. When you press enter, your bank’s website loads and you have a login form. How do you know it is safe to provide your credentials? Could a hacker have intercepted the communication between you and your bank and provided their own code? To verify you are communicating directly with your bank, you could ask your bank for its credentials and then verify those credentials through a trusted third party that already has a log of each website’s credentials. That trusted third party is the CA.
After the CA has successfully verified who you are communicating with, your browser will accept the connection (and perform all the steps to encrypt the communication) and a padlock will appear next to the URL indicating that you have a safe connection.
How certification work?
For the process described above to work, the CA must have already verified the bank, right? Correct.
To set up a website to transfer data over HTTPS, the bank first needs to request a CA to verify its identity and provide it with a digital certificate. This SSL/TLS certificate is digitally signed with the CA’s private key to prevent forgery.
Overall, the steps that make up the certification process for an SSL/TLS certificate are:
- The client requests a digital certificate from a trusted CA for their website
- The CA will verify client is the owner of the website
- The CA will create the digital certificate
- The CA will sign the digital certificate so it cannot be forged
Chain of Trust
By this point, you might be wondering how do we trust the CA is who they say they are? Here we get to the Chain of Trust. Just like in our earlier scenario we asked a CA to validate a website, we can also have a CA validate a CA. A certificate that needs to be validated by another CA is called an Intermediate Certificate. You can see this hierarchy in the image below where Entrust G2 certifies L1M, which in turn certifies www.chase.com.
However, for this chain to have an end, we need to be able to inherently trust the final CA. We do this through Root Certificates. Root Certificates are certificates for thoroughly vetted CAs, and these certificates are distributed within operating systems and browsers. Their embedded nature means they can’t be altered by a MITM attack.