---
title: "What Is Certificate Authority, Let’s Encrypt, Trust Stores"
description: "What Certificate Authorities are, how Let's Encrypt works, and why trust stores matter. Complete guide to HTTPS, SSL certificates, and PKI trust chains."
slug: "what-is-certificate-authority-lets-encrypt-trust-stores"
url: "https://furkanbaytekin.dev/blogs/what-is-certificate-authority-lets-encrypt-trust-stores"
author: "Furkan Baytekin"
category: "Software"
tags: []
published: 2025-12-21T10:15:46Z
updated: 2025-12-21T10:15:46Z
readTime: 3
cover: "https://myblogcms.furkanbaytekin.dev/uploads/cover/what-is-certificate-authority-lets-encrypt-trust-stores+1766311911113"
---

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:

```bash
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.
