Every time your browser shows that little padlock, it’s vouching for a chain of trust that stretches from the website you’re visiting all the way back to a handful of organizations you’ve never heard of. You didn’t choose to trust them. Your operating system did — years ago, when someone at Apple or Microsoft or Mozilla decided which root certificates to bundle. That’s the foundation of PKI. Not math. Not policy. A pre-installed list of “these organizations are trustworthy” that you never consented to and probably never inspected.

The TLDR

Public Key Infrastructure (PKI) is the system that makes encrypted web connections possible. It works through a chain of trust: root Certificate Authorities (CAs) vouch for intermediate CAs, which vouch for the certificates on individual websites. When you visit a site over HTTPS, your browser walks that chain to verify the certificate is legitimate. If any link in the chain is broken — expired, revoked, or fraudulently issued — the whole thing falls apart. PKI is elegant in theory and terrifyingly fragile in practice, because you’re trusting a small number of organizations to never make a catastrophic mistake. Some of them already have.

The Reality

Your browser’s trust store contains somewhere between 100 and 150 root certificates. These are the anchors. Every encrypted connection you make traces back to one of them. And the organizations behind those roots — companies like DigiCert, Sectigo, GlobalSign, and the Internet Security Research Group (Let’s Encrypt) — hold the keys to the entire internet’s trust model.

The problem isn’t the cryptography. The problem is that a single compromised CA can issue a valid certificate for any domain on the internet. In 2011, the Dutch CA DigiNotar was compromised, and attackers issued fraudulent certificates for google.com, cia.gov, and dozens of other domains. Those certificates were technically valid — browsers trusted them because DigiNotar was in the root store. The Iranian government used them to intercept Gmail traffic from 300,000 people. DigiNotar was removed from trust stores and went bankrupt within months, but the damage was done.

In 2015, Symantec’s CA operations were caught issuing unauthorized test certificates for google.com. Google spent years gradually distrusting Symantec’s certificates, eventually forcing a complete re-issuance affecting millions of sites. The largest CA in the world, and they couldn’t keep their house in order.

How It Works

The Certificate Chain — Root, Intermediate, Leaf

PKI operates as a hierarchy. At the top are root CAs — their certificates are self-signed and embedded directly in your operating system or browser. Root CAs almost never issue certificates directly. Instead, they sign intermediate CA certificates, which in turn sign leaf certificates (the ones on actual websites).

Root CA (self-signed, in your trust store)
  └── Intermediate CA (signed by Root)
        └── Leaf Certificate (signed by Intermediate, on example.com)

When your browser connects to a site, the server presents its leaf certificate and any intermediates. Your browser walks the chain upward until it hits a root it trusts. If the chain is complete and valid, the connection proceeds. If any link is missing, expired, or unrecognized — you get that certificate warning.

X.509 — The Certificate Format

Almost every certificate you encounter is X.509, defined in RFC 5280. An X.509 certificate contains: the subject (who it’s issued to), the issuer (who signed it), the public key, validity dates (not before, not after), serial number, signature algorithm, and extensions like Subject Alternative Names (SANs) that list which domains the certificate covers.

The Certificate Lifecycle

Every certificate goes through a lifecycle: request (generate a key pair, create a Certificate Signing Request), validation (the CA verifies you control the domain — via DNS, HTTP challenge, or email), issuance (the CA signs and returns the certificate), deployment (install it on your server), renewal (before it expires), and potentially revocation (if the private key is compromised or the certificate was mis-issued).

Let’s Encrypt automated this entire lifecycle. Before Let’s Encrypt launched in 2015, getting a TLS certificate meant paying a CA, waiting for manual validation, and remembering to renew annually. The Internet Security Research Group changed that with the ACME protocol — automated certificate issuance and renewal, free, in minutes. As of 2025, Let’s Encrypt has issued certificates for over 300 million websites. They democratized TLS and made HTTPS the default instead of the exception.

Revocation — CRL vs OCSP

When a certificate needs to be invalidated before its expiration date, there are two mechanisms. Certificate Revocation Lists (CRLs) are periodically published lists of revoked serial numbers. The problem: they’re big, they’re slow, and most clients don’t check them consistently.

Online Certificate Status Protocol (OCSP) is a real-time check — your browser asks the CA “is this certificate still valid?” before proceeding. Better in theory, but it introduces latency and a privacy concern: the CA knows every site you visit. OCSP stapling solves this by having the server periodically fetch its own OCSP response and present it during the TLS handshake. No extra round-trip, no CA tracking your browsing.

In practice, revocation checking is unreliable. Many browsers soft-fail — if they can’t reach the CRL or OCSP responder, they proceed anyway. Chrome dropped traditional OCSP checking entirely in favor of CRLSets (a curated, pushed subset of revocations). The dirty secret of PKI is that revocation, the safety net for compromised certificates, barely works.

How It Gets Exploited

CA Compromise

DigiNotar remains the canonical example. When a CA is compromised, the attacker can issue certificates for any domain. Those certificates will be trusted by every browser and operating system that trusts that CA’s root. Nation-state actors target CAs specifically because one breach gives them the ability to impersonate any site on the internet.

Mis-issuance

CAs sometimes issue certificates to the wrong people, either through process failures or social engineering. The Symantec debacle involved thousands of certificates issued without proper validation. MITRE ATT&CK T1587.003 documents the acquisition of digital certificates as a pre-attack technique — adversaries don’t always need to hack a CA when they can simply request a certificate through legitimate channels with fraudulent information.

Certificate Transparency Bypasses

Certificate Transparency (CT) was created to catch mis-issuance. CAs must log every certificate they issue to public, append-only logs. Anyone can monitor these logs for unauthorized certificates issued for their domain. But CT is detective, not preventive — it catches problems after issuance, and only if someone is watching. If you’re not monitoring CT logs for your domains, a fraudulently issued certificate could exist for weeks before anyone notices.

Expired Certificates and Outages

Forgetting to renew a certificate doesn’t just show a browser warning — it can take down entire services. In 2020, an expired intermediate certificate caused a global outage for Sectigo customers. In 2024, an expired certificate briefly disrupted Microsoft Teams. For the usual suspects, targeting certificate renewal processes or disrupting ACME challenges is a viable denial-of-service vector.

What You Can Do

Inspect certificates. Click the padlock in your browser. Look at who issued it, when it expires, and what domains it covers. Make this a habit, especially on sensitive sites like banking and email.

Monitor Certificate Transparency logs. If you own a domain, use services like crt.sh or Facebook’s CT monitoring to watch for unauthorized certificates. If a certificate appears for your domain that you didn’t request, something is very wrong.

Use HSTS and certificate pinning cautiously. HTTP Strict Transport Security forces browsers to always use HTTPS. Certificate pinning goes further by specifying exactly which certificates or public keys a browser should accept — but it’s a double-edged sword. Pin incorrectly and you lock people out of your own site. HSTS is straightforward and should be everywhere. Pinning requires operational maturity.

Automate certificate management. Use Let’s Encrypt and ACME clients like Certbot. Manual certificate management is how things expire at 3 AM on a holiday weekend. Automated renewal eliminates an entire class of outages.

Implement CAA records. DNS Certification Authority Authorization records specify which CAs are allowed to issue certificates for your domain. It’s a single DNS record that prevents unauthorized CAs from issuing certificates for you. There’s no reason not to set it up.

Follow NIST SP 800-57 for key management. Protect private keys. Don’t store them alongside certificates. Use hardware security modules for high-value keys. Rotate regularly.

Sources & Further Reading