What Is Certificate Authority, Let’s Encrypt, Trust Stores

What Is Certificate Authority, Let’s Encrypt, Trust Stores

What Certificate Authorities are, how Let's Encrypt works, and why trust stores matter. Complete guide to HTTPS, SSL certificates, and PKI trust chains.

If you’ve ever dealt with HTTPS, SSL, or TLS, you’ve interacted with a Certificate Authority (CA) whether you realized it or not. I definitely hadn’t… until I broke my entire system.

This post is a practical explanation of what a CA is, how Let’s Encrypt fits into the picture, and how deleting the wrong package on Arch Linux taught me who the internet actually trusts.


What Is a Certificate Authority (CA)?

A Certificate Authority is a trusted organization that says:

“Yes, this public key really belongs to this domain.”

Browsers don’t magically trust websites. They trust CAs, and CAs vouch for websites by signing certificates.

Examples of well-known CAs:

  • Let’s Encrypt
  • Google Trust Services
  • DigiCert
  • GlobalSign

If a certificate is signed by a CA your system trusts, HTTPS works. If not, you get errors like “certificate not trusted” or “unknown issuer”.


How Trust Actually Works (The Chain)

TLS trust is based on a certificate chain:

Root CA (trusted by OS / browser)
  └── Intermediate CA
        └── Server Certificate (example.com)

Key point: 👉 Your system does NOT trust websites. It trusts Root CAs.

Those trusted root certificates live in something called a trust store.


Let’s Encrypt: Free, Automated, Trusted

Let’s Encrypt is a CA with one mission: make HTTPS free and easy.

What it does:

  • Issues Domain Validated (DV) certificates
  • Uses the ACME protocol to verify domain ownership
  • Certificates are short-lived (90 days)
  • Designed for full automation

What it doesn’t do:

  • No company identity checks (no OV [Organization Validation] / EV [Extended Validation])
  • No “brand trust” signaling

Important part: Let’s Encrypt root certificates are trusted by all major OSes and browsers. That’s why it works everywhere despite being free.


My Arch Linux Mistake (and the Realization)

At some point, I removed the Mozilla CA certificates package on Arch Linux.

My logic was simple and wrong:

“I don’t use Firefox, so I don’t need Mozilla stuff.”

What actually happened:

  • I deleted the system’s CA trust bundle
  • My OS no longer knew which Root CAs to trust
  • HTTPS stopped working everywhere

Symptoms:

  • Browsers couldn’t open any HTTPS site
  • curl, git, pacman all failed
  • TLS handshakes broke at verification stage

Why? Because verification goes like this:

  1. Server sends its certificate
  2. Client tries to build a chain to a trusted Root CA
  3. Trust store is empty → verification fails

At that moment it realized:

I didn’t break Firefox. I deleted “who my system trusts on the internet”.

I had to recover using pacstrap / chroot and reinstall:

ca-certificates
ca-certificates-utils

Lesson learned the hard way.


Why Mozilla CA Certificates Aren’t “Firefox Stuff”

Despite the name:

  • Mozilla maintains one of the most widely used Root CA programs
  • Linux distributions reuse it as the system trust store
  • Firefox, Chrome, curl, git - all rely on it (directly or indirectly)

Delete it, and you’ve effectively said:

“I trust no one.”


Final Takeaway

  • CA = a trusted organization that signs certificates
  • Your OS decides which CAs are trusted
  • Let’s Encrypt is trusted because it’s in the trust store
  • HTTPS fails not because certificates are wrong, but because trust chains break

TLS isn't magic. It's just cryptography + trust + a file you really shouldn't delete.

If you understand that, SSL errors stop being scary-and start being debuggable.