Certificate Authority (CA)

What is a Certificate Authority?

A Certificate Authority (CA) is a trusted organization that issues digital certificates and vouches for the identity of their holders. When a website presents a TLS certificate, a CA has signed it, attesting “yes, this certificate legitimately belongs to example.com.” Your browser and operating system ship with a built-in list of trusted root CAs, and they trust any certificate that chains back to one of those roots. This is what lets a browser you’ve never configured believe that the bank’s website is really the bank — the CA is the trusted third party in the middle, and the entire public HTTPS trust model rests on it.

The chain of trust — how it actually works

CAs don’t sign every website certificate with their crown-jewels root key; they use a chain of trust. A small number of root CAs have self-signed root certificates that are pre-installed as trusted in browsers/OSes. Roots sign intermediate CA certificates, and intermediates sign the end-entity (website) certificates. So a site’s certificate chains: website cert → intermediate → root, and the browser validates each signature up the chain until it reaches a trusted root. This structure exists for security — the root’s private key is kept offline and rarely used, so a compromise of an intermediate can be contained by revoking it without invalidating the root. The reason this matters practically is the contrast with a self-signed certificate: a self-signed cert has no CA vouching for it and chains to nothing trusted, which is exactly why browsers throw warnings on it. The CA-signed chain provides the authentication half of TLS (proving identity), complementing the encryption half — and remember that encryption without trusted authentication is vulnerable to man-in-the-middle attacks, which is the whole reason CAs exist.

The trust model’s fragility, and how it’s managed

The CA system’s great weakness is that it’s only as trustworthy as its least trustworthy CA — since browsers trust many root CAs, a single compromised or malicious CA could issue fraudulent certificates for any domain, and clients would accept them. This isn’t hypothetical: the DigiNotar breach (2011) saw a CA compromised and used to issue fraudulent Google certificates, and it was subsequently distrusted and driven out of business. The ecosystem manages this fragility with several mechanisms: Certificate Transparency (CT) logs, public append-only records of every certificate issued, so domain owners can detect unauthorized certs for their domains and browsers can require certs to be logged; revocation (CRLs and OCSP) to invalidate compromised certificates before they expire; CAA DNS records, which let a domain owner specify which CAs are allowed to issue for their domain; and strict baseline requirements CAs must follow to stay in the trust stores. The modern practical landscape is dominated by Let’s Encrypt, a free, automated CA (via the ACME protocol) that made CA-signed certificates free and scriptable, eliminating the old cost excuse for self-signed certs and driving near-universal HTTPS. Organizations also run private/internal CAs to issue certificates for internal services, distributing their own root to their fleet — getting the trust benefit inside their perimeter without public CAs.

What people get wrong

• Not understanding the chain — a certificate that fails to include its intermediate (“incomplete chain”) breaks trust on some clients even though the cert itself is valid.
• Forgetting the whole system’s trust is only as strong as its weakest CA: a single rogue/compromised CA can forge certs for any domain, which is why CT logs, CAA records, and revocation exist.
• Reaching for self-signed certs on public sites — they chain to no trusted CA, so browsers warn; free automated CAs (Let’s Encrypt) removed the reason to do this.

Primary source: Let’s Encrypt: How it works