Certificate and CA

Prerequisites

Before reading this article, you need to learn:

In the article Scenarios for Using Asymmetric Encryption, we learned about two main uses of asymmetric encryption:

Encrypted Communication: Encrypt with the public key, decrypt with the private key, so communication is private.
Digital Signature: Sign with the private key, verify with the public key, to prove identity and data integrity.

However, there is still a problem with asymmetric encryption: How can you be sure the public key you receive is genuine and trustworthy?

The Trust Problem in Public Key Distribution

Suppose you want to visit your bank's website https://bank.com. The bank's server sends you its public key and tells you:

This is my public key. You can use it to encrypt data for me. I will decrypt it with my private key.

Sounds fine, but there is a big security risk: Man-in-the-Middle Attack.

Imagine this situation:

Your computer <---> Hacker's computer <---> Bank server

When you visit https://bank.com, the hacker intercepts your network request:

The hacker intercepts the real public key sent by the bank.
The hacker sends you his own public key, pretending it is the bank's public key.
You use the hacker's public key to encrypt your username and password and send it out.
The hacker uses his private key to decrypt it, stealing your account info.
The hacker then encrypts your info using the bank's real public key and sends it to the bank server.

You have no idea you are talking to the hacker. You think you are talking directly to the bank.

The core problem: you can't make sure the public key you received really belongs to the bank and is not fake.

It's just like someone calling you and saying, "I'm a bank customer service agent." How do you know it's not a scammer?

To solve this, we need a trusted third party that both sides trust. This third party is a Certificate Authority (CA).