The Trust Problem Link to heading

If you haven’t been following along, this is part of the series Encryption in Transit.

So far, everything sounds nice in theory. You and a server has a public key, you use it to create a pre-computed symmetric key and talk securely, done.

But, how do you even know that public key belongs to the server you think it does? Link to heading

Like, imagine you’re trying to connect to your bank. You ask for its public key, and you get a response containing the public key. Cool. But how do you know it’s really the bank you’re talking to? What if there is an actual attacker sitting and intercepting every request you make to your bank? Which means if you go to bank.com it is actually an attacker trying to portray itself as bank.com and never letting your request reach to the ACTUAL bank.com. In this case, they can just hand you their public key, you happily encrypt everything with it, and now they’re reading all your traffic while pretending to be the bank.

In this case, how do you ensure that public key is actually coming from the ACTUAL bank.com and anything you encrypt with this public key can only be decrypted only by the application running at bank.com?

And this is exactly why self-signed certificates don’t work in practice. A server can absolutely generate its own certificate. Like I can legit build a website looking like google.com and buy domain for g00gle.com, and attach a self-signed TLS certificate in the name of google.com. Telling your browser, trust me, I am the public key of REAL google.com, encrypt your data with it and send it over to me, it will be very easy for me to impersonate google.com for you.

This is the real problem TLS has to solve. Not just encryption — but trust. Encryption without trust is kind of useless, because you might just be securely talking to the wrong person.

Enter Certificate Authorities Link to heading

This is where Certificate Authorities (CAs) come in.

Instead of you trying to verify every website on your own (which is obviously impossible), you outsource that job to a trusted third party. A CA is basically an organization whose whole job is to verify identities and then vouch for them.

So instead of a server saying “this is my public key,” it says:

“Here’s my public key… and also, this trusted authority has signed it.”

That signature is the important part. The CA checks that the server actually owns the domain it claims (like example.com), and once it’s satisfied, it signs the certificate using its own private key (more on this later).

Now your browser doesn’t need to trust the server directly. It just needs to trust the CA that signed it.

But… why should I even trust the CA? Link to heading

I have trust issues so I googled about it. So, “technically” speaking… You already do.

Your browsers and operating systems come with a built-in list of trusted Certificate Authorities. This is called the trust store. It’s basically a curated list of “these are the entities we trust to vouch for identities on the internet.”

So when your browser sees a certificate signed by, say, a well-known CA, it can verify the signature using that CA’s public key (which it already has). If the signature checks out, the browser is like:

Cool, I trust this CA (Root CA), and this CA trusts this server — so I’ll trust the server

This… Is the exact core idea of The Chain of Trust.

But what if the ATTACKER becomes the CA?? Link to heading

Not really true, because becoming a CA is not an easy task. they have to go through a pretty heavy audit and compliance process. There are industry standards (like WebTrust audits) that check how securely they operate.

Also, running a CA involved big money — you need infrastructure, security, audits, legal compliance — and most public CAs are businesses that charge for issuing certificates (even though free options like Let’s Encrypt exist now).

And to be very frank, just to become a CA to spoof g00gle.com to pretend google.com isn’t gonna work. What if the user types google.com correctly in the first place? (I know, stupid example, but I hope you get the point)

Still, how does one apply becoming a CA? Link to heading

There’s no single governing body of the internet handing out root status. Instead, trust is decided by browser vendors and operating systems — the people who control the trust stores.

Companies like Google, Apple, Microsoft, Mozilla, they each maintain their own list of trusted root certificates. So becoming a root CA really means convincing these vendors to include YOUR root certificate in their trust store.

Yessir, they DO look for all the compliant audits and stuff. If you fail them, your application can also get rejected. Don’t try to be cheap 😄

The REAL Chain of Trust Link to heading

The Root CA Link to heading

So yes, if you haven’t guessed it already… The Root CA’s certificate is what browser / OS stores in their trust store. Their public keys are literally baked into your system.

This is the reason Root CAs are kept offline i.e. their certificates aren’t transferred over the network. They are completely isolated, Off-the-grid, and used only very rarely. If a root CA is ever compromised, it’s basically game over — an attacker could sign certificates for any domain on the internet and every browser would accept them as valid.

So instead of using root keys (Another common name for a Root CAs private key is the ROOT KEY) for everyday signing, they delegate that responsibility to something we call as Intermediate Certificates

Intermediate Certificate Link to heading

Rather than signing every certificate directly, Root CAs create Intermediate CAs. The root says:

“I trust this intermediate CA to issue certificates on my behalf.”

It does that by signing the intermediate’s certificate. Now, the intermediate CA can go ahead and sign server certificates. This creates a chain:

Root CA → signs → Intermediate CA
Intermediate CA → signs → Server Certificate

When your browser connects to a server, it doesn’t just get the server’s certificate. It also gets this chain (minus the root, since the browser already has it).

The browser then verifies each step. Is the server signed by an intermediate certificate? If yes, is the intermediate certificate signed by a trusted root? If yes, the trust is established.

The certificate (to-be-tested) contains details on who signed it.

Info

So this layered approach reduces risk. Even if an intermediate CA is compromised, you can revoke just that intermediate without touching the root

But, how does a server even get a certificate signed in the first place? Link to heading

This is where CSR comes in?

When you want a certificate, you generate a key pair on your server (public + private key). The private key stays with you — ALWAYSSS. Then you create a CSR, which is basically a bundle of information:

Your Public Key
Your Domain name (example.com)
Some metadata about your organization

You send this CSR to a Certificate Authority. The CA verifies that you actually control the domain (this could be via DNS records, email validation, etc.), and if everything looks good, it signs your public key and returns a certificate.

Now you have something you can present to clients that says:

“Here’s my public key, and a trusted authority has verified that it belongs to this domain.”

How does a CA verify your domain identity? Link to heading

One of the most common ways this is done is DNS validation. The CA asks you to create a specific DNS record (usually a TXT record) with a random value they give you. Then, The CA looks up the record, sees the expected value, and goes “okay, this person controls the domain. And because only someone who controls the domain can make this change this acts as proof for domain identity verification.

Another method is email validation. In this, the CA sends a verification email to certain predefined addresses associated with the domain — like admin@example.com, hostmaster@example.com, or similar. The assumption is that if you control the domain, you probably have access to these standard inboxes. You receive the email, click a link or enter a code, and that completes the verification.

Earlier, There used to be some reliance on WHOIS data for figuring out contact emails, but that’s become less reliable over time because WHOIS is often privacy-protected now. So modern flows stick to well-known email aliases tied to the domain itself rather than whatever shows up in registration records.

Tip

The important thing to notice here is that the CA isn’t deeply investigating who you are as a person (at least not for basic certificates). It’s just checking: can you prove control over this domain right now? If yes, it’s enough to issue what’s called a Domain Validated (DV) certificate.

To summarize Link to heading

So the whole system is less about encryption itself, and more about answering one question:

“Can I trust that this public key actually belongs to the server I’m trying to talk to?”

And instead of solving that problem directly between client and server, TLS builds this entire chain of trust using Certificate Authorities, root certificates, and signatures.

It’s a bit indirect, but that’s kind of the point. You don’t need to know every server on the internet — you just need to trust a small set of authorities that vouch for them.

Thanks for reading this far. If you’re interested in reading more, checkout the complete series and if you have any more questions / queries feel free to reach out to me on X.

Meow.