How Digital Certificates and Certificate Authorities Work

When you visit a website, your browser checks a small file called a certificate. That file proves the website is who it claims to be—the same way a passport proves your identity. But who verifies the certificate itself? That's where Certificate Authorities come in. They act as trusted middlemen, signing certificates to vouch for websites. Understanding how this system works reveals both why the web functions securely and where weaknesses can emerge.

What a Certificate Actually Is

A digital certificate is a package of information that binds a public key to an identity. Start with the basics: a public key is a long string of numbers used in encryption. By itself, it's just data—anyone can claim a public key belongs to them. A certificate answers the question: "Does this public key actually belong to google.com, or is it an imposter trying to intercept my traffic?"

The certificate contains the public key, the website's domain name, an expiration date, and crucially, a digital signature. Think of that signature like a tamper-evident seal on an envelope. If someone modifies the certificate contents after it's signed, the seal breaks and the certificate becomes invalid.

Who Signs the Certificate? The Chain of Trust

Your browser doesn't verify certificates using magic. Instead, it trusts certain organizations to verify them. These organizations are Certificate Authorities (CAs). When a website wants a certificate, it proves ownership of its domain to a CA, and the CA signs the certificate with its own private key. Your browser then checks: "Is this certificate signed by a CA I trust?"

But how does your browser know which CAs to trust? It comes pre-loaded with a list of trusted root CAs—organizations vetted by browser vendors (like Mozilla, Google, Apple). When you download your browser, it includes certificates from these root CAs built directly into the software.

The problem is that root CAs are busy. Instead of signing every website certificate themselves, they create intermediate CAs—organizations they trust to sign certificates on their behalf. This creates a chain: your browser trusts the root CA, the root CA trusts the intermediate CA, and the intermediate CA signs the website's certificate. As long as each link is valid, the entire chain is trustworthy.

When the System Breaks: The DigiNotar Incident

In 2011, an intermediate CA called DigiNotar was hacked. Attackers used it to sign fake certificates for Gmail, Yahoo, and other major sites. They could then intercept traffic from users who thought they were connecting securely to these websites—the certificates looked valid because they were signed by a trusted CA.

This revealed a critical problem: CAs are human organizations with security practices that can fail. DigiNotar was breached partly through poor security hygiene. The aftermath was swift—Mozilla, Google, Apple, and other browser vendors removed DigiNotar's certificates from their trusted lists within days. This stopped the attack, but it also showed that the chain of trust depends entirely on CAs staying trustworthy.

After DigiNotar, the industry learned that trusting CAs alone wasn't enough. Browser vendors also demanded transparency.

Certificate Transparency Logs

Certificate Transparency (CT) is a system that logs every certificate a CA signs in public, append-only ledgers. Think of it like a public record book: when a CA issues a certificate, that fact is permanently recorded where auditors, security researchers, and the certificate owner can verify it.

If someone issues a fake certificate for google.com, Google's security team can check the CT logs, discover the certificate, and alert browser vendors to block it—all before the fake certificate causes real harm. This transforms CAs from the sole gatekeepers into part of a system where issuance is transparent and verifiable.

CT logs don't prevent bad CAs from signing bad certificates. They prevent bad certificates from being used silently. The attacker's action becomes visible.

How Browsers Decide Which CAs to Trust

Your browser ships with a curated list of trusted root CA certificates. Mozilla maintains the "Common CA Certificate Database," a public list of CAs it considers trustworthy. Other browser vendors (Google, Apple, Microsoft) have similar processes. To be included, CAs must meet security standards, undergo audits, and agree to transparency requirements.

Governments cannot simply create their own CA and force browsers to trust it. If an authoritarian regime issues a CA certificate and tries to use it to intercept traffic, the certificate will fail validation because the CA is not in the browser's trusted list. The regime could try to install its CA on devices within its borders, and many do—but this requires control over individual computers, not the internet backbone.

This is why the system, despite its flaws, has made it harder for governments to conduct mass surveillance through HTTPS interception. They cannot forge certificates that appear valid to browsers outside their control.

The Limits of This System

No system is perfect. A CA could be compromised again. A major browser vendor could be pressured to trust a malicious CA. End users in restrictive countries can be forced to install government-controlled CAs on their devices. The system also does nothing to verify whether a website operator is who they claim to be offline—only that their online certificate matches their domain.

But the combination of certificate pinning (browsers remembering specific certificates for major sites), transparency logs, and public CA audits has made large-scale, silent certificate forgery much harder than it once was.

The Takeaway

Digital certificates prove that a public key belongs to a website. Certificate Authorities sign those certificates, and browsers trust only CAs on their pre-loaded list. When CAs fail (DigiNotar), transparency logs catch the problem. This system isn't perfect, but it transforms encryption from something only cryptographers understand into something that protects millions of ordinary users every day. To deepen your understanding, explore how HTTPS actually uses certificates, how certificate pinning works, and the policies that govern which organizations can become trusted CAs.