Certificate Authorities

Certificate Authorities are the organizations your browser trusts to verify that websites are who they claim to be. Every HTTPS connection depends on this trust. When you see the padlock icon, you're not just seeing encryption—you're seeing your browser's faith that a CA properly verified that website's identity before issuing its certificate.

Your browser trusts about 150 organizations you've never heard of to vouch for every website you visit. This is either a miracle of institutional design or a house of cards—possibly both.

What a CA Actually Does

A Certificate Authority verifies identities and issues digital certificates. When a website operator wants an SSL certificate, they prove their identity to a CA. The CA then creates a certificate containing the website's public key and identity information, and signs it with the CA's own private key.

That signature is everything. It's the CA saying: "I verified this. I vouch for this identity."

Browsers trust certain CAs implicitly. Any certificate signed by a trusted CA is automatically accepted—no user intervention needed. This is convenient but also terrifying if you think about it too long.

The Root of All Trust

The foundation is a small set of root Certificate Authorities whose certificates are embedded in operating systems and browsers. These root certificates are self-signed—the CA vouches for itself—but they're trusted because browser vendors explicitly included them.

Mozilla, Google, Apple, and Microsoft each maintain their own root store programs. To become a trusted root CA, an organization must undergo extensive audits, maintain strict security controls, and demonstrate years of trustworthy operation. Getting a new root certificate added takes years.

This high barrier is intentional. The system's security depends on root CAs being trustworthy, so the bar for entry is deliberately punishing.

The Chain of Trust

Root CAs rarely sign website certificates directly. Instead, they sign intermediate certificates, which sign website certificates. Your browser sees: website certificate → intermediate CA → root CA.

Why the indirection? The root CA's private key is extraordinarily valuable. It stays offline, in hardened facilities, air-gapped from the Internet. Intermediate keys do the day-to-day signing. If an intermediate is compromised, you revoke that intermediate. The root survives.

When you configure a web server, you must include the full chain—your certificate plus all intermediates. Browsers need to see the path back to a root they trust.

Public vs. Private CAs

Public CAs issue certificates trusted by browsers for public websites. DigiCert, GlobalSign, Sectigo, Let's Encrypt—these are public CAs included in browser trust stores.

Private CAs issue certificates for internal use. A company might run its own CA for internal websites, email signing, or device authentication. These certificates aren't trusted by public browsers unless manually configured.

Private CAs are powerful but require expertise. If you compromise your own CA, you've compromised your entire organization's internal trust.

Let's Encrypt Changed Everything

Before 2016, certificates cost money. Not much—maybe $10-100 per year for basic certificates—but enough friction that many websites didn't bother. HTTPS was for e-commerce and banks.

Let's Encrypt changed this by offering free, automated certificates to anyone. It's a non-profit CA sponsored by major technology companies and operated by the Internet Security Research Group.

The impact was staggering. HTTPS adoption went from about 40% of web traffic in 2015 to over 90% today. Billions of certificates issued. The entire web encrypted, largely because one organization removed the friction.

Let's Encrypt issues only Domain Validation certificates with 90-day lifetimes. The short validity encourages automation—you can't manually renew every 90 days, so you automate or you suffer.

Validation Levels

CAs offer different validation levels:

Domain Validation (DV) verifies only that you control the domain. The CA checks through automated methods: DNS records, HTTP challenges, or email to administrative addresses. Takes minutes.

Organization Validation (OV) verifies the organization's legal existence. The CA checks business registration, possibly calls the registered phone number, confirms the requester is authorized. Takes days.

Extended Validation (EV) requires extensive verification: background checks, physical address verification, corporate documents, third-party database confirmation. Takes weeks.

Here's what matters: the validation level doesn't affect encryption strength. A free DV certificate from Let's Encrypt provides identical cryptographic security to a $1,000 EV certificate. The difference is only in how thoroughly the CA verified who you are—not how securely your connection is encrypted.

When CAs Fail

The system has experienced catastrophic failures:

DigiNotar (2011) was a Dutch CA that was completely compromised. Attackers issued fraudulent certificates for Google, Yahoo, and hundreds of other sites. These weren't theoretical threats—the certificates were used for surveillance of Iranian citizens.

When the breach was discovered, browsers removed DigiNotar from their trust stores. The company was dead within weeks. Every certificate they'd ever issued became untrusted.

Symantec (2017-2018) repeatedly violated validation requirements. They issued certificates without proper verification, including test certificates for domains they didn't control. Google and Mozilla announced they would distrust all Symantec certificates. Rather than face browser death, Symantec sold its CA business to DigiCert.

These incidents reveal something important: the system has accountability. CAs that violate trust get killed. The punishment is corporate death, and browser vendors have proven willing to execute.

Certificate Revocation

When a certificate needs to be invalidated before expiration—private key compromised, domain sold, employee left—it must be revoked. CAs maintain Certificate Revocation Lists (CRLs) and operate OCSP responders that browsers can query.

Revocation has historically been unreliable. Checking revocation status adds latency and raises privacy concerns (the CA learns which sites you visit). Many browsers don't consistently check. Modern approaches like OCSP Stapling let servers include fresh revocation proof with each connection, avoiding the privacy and performance problems.

The Trend Toward Shorter Lifetimes

Certificate validity periods have steadily decreased:

• 2012: Five years maximum
• 2015: Three years maximum
• 2018: Two years maximum
• 2020: 398 days maximum (about 13 months)

Shorter lifetimes reduce the window of vulnerability if a certificate is compromised. They also force automation—nobody manually renews certificates every year across hundreds of servers.

The industry is moving toward even shorter lifetimes. Let's Encrypt's 90-day certificates have proven that aggressive automation works. Some are pushing for 30-day or even shorter validity.

Certificate Transparency

Since 2018, CAs must log every certificate they issue to public Certificate Transparency logs. These are append-only records that anyone can monitor.

CT logging means unauthorized certificates can be detected. If a compromised CA issues a fraudulent certificate for google.com, Google's monitoring will spot it in the CT logs within hours. Before CT, a fraudulent certificate might go undetected indefinitely.

This transparency has fundamentally changed CA accountability. Every certificate is public record.

The Trust Tradeoff

The CA system has an uncomfortable dependency: security for billions of people depends on a few hundred organizations maintaining perfect operational security forever. One compromised root CA could issue certificates for any domain on the Internet.

But the alternatives are worse. Without CAs, how would your browser know that the server claiming to be your bank is actually your bank? Every user manually verifying every certificate? Impossible. Some decentralized trust system? Hasn't scaled.

CAs are imperfect. The DigiNotar compromise was used for surveillance of dissidents. Symantec violated requirements for years. But the accountability mechanisms work—both CAs were removed from trust stores. The system bends but recovers.

For now, when you see that padlock, you're trusting that every CA in your browser's root store is operating with integrity. Most of the time, they are.