Observability, short-lived credentials, and active enforcement hold the web's trust model together. Without them, a decade of Certificate Authority failures would've collapsed it. Will those same levers hold for what's coming next?

The web’s certificate trust model has held up through more than a decade of CA breaches, misissued certificates, and distrust events. How did it survive that pressure, and where are we heading? You can apply the same patterns to any system where you delegate trust.

What it was meant to be.

The original Public Key Infrastructure design assumed trust that could be delegated through a hierarchy of certificate authorities. Root CAs hard-coded into browsers and operating systems would vouch for intermediate CAs, which in turn would vouch for end-entity certificates. On receiving a certificate, a browser would check the chain against trusted roots and accept it as valid. The approach traces back to the early X.509 standard work and Netscape’s SSL deployment in 1995.

Three assumptions underpinned the design:

• CAs would not issue certificates fraudulently.
• Compromised certificates could be revoked, and clients would honor that revocation.
• The list of trusted roots would remain stable.

There was no public log of issued certificates. Browsers treated certificate revocations as advisory. The system relied on each CA doing its job correctly.

What happened.

CA failures came in waves, each exposing a different design assumption. Smaller CA incidents had appeared earlier, but DigiNotar was the first to force browsers to remove a root CA entirely.

In 2011, Dutch CA DigiNotar was breached and issued hundreds of fraudulent certificates. The attackers used a wildcard for *.google.com to intercept Gmail traffic in Iran. Any CA could issue a valid certificate for any domain, and revocation only helped after detection.

Smaller incidents followed. Misissuance by TURKTRUST and ANSSI in 2013, then CNNIC in 2015, prompted browsers to tighten scrutiny each time.

Symantec’s CA business misissued certificates over several years, including test certificates for domains it didn’t control. Mozilla and Google announced a phased rollback of trust in 2017. Chrome removed trust from Symantec’s old infrastructure entirely in 2018. Symantec, then one of the world’s largest CAs, sold its CA business to DigiCert in response to the planned rollback.

Code signing exposed a related but distinct failure mode:

• In 2020, attackers compromised SolarWinds’ build process. The backdoored Orion DLL, signed with SolarWinds’ legitimate certificate, reached 18,000 customers.
• In 2023, the 3CX compromise chained signatures end-to-end. A trojanized Trading Technologies installer ran on a 3CX employee’s machine, giving attackers a foothold inside 3CX, whose own signed installer then shipped to customers.

The CA validated a legitimate publisher, but the compromise occurred downstream of validation.

On the TLS side, in 2024 Google announced that Chrome would distrust new Entrust certificates, and Mozilla followed for Firefox. Both cited a multi-year pattern of compliance failures.

In September 2025, Croatian CA Fina was found to have issued twelve unauthorized certificates for Cloudflare’s 1.1.1.1 DNS resolver. Cloudflare’s disclosure acknowledged that its alerting systems missed the misissuance and an outside researcher caught it. Microsoft’s root store trusted Fina, which exposed Microsoft Edge and other Windows apps relying on the OS root store.

Each failure drove a structural response:

How the trust model held up.

Repeated CA failures revealed that voluntary self-policing wasn’t enough. Web browsers became the enforcers of industry rules, regularly revoking trust from CAs that failed. Mozilla and Apple distrusted WoSign and StartCom in 2016 for compliance failures, and Symantec’s 2018 distrust extended that pattern to a major CA. When Entrust drew the same response in 2024, the industry processed it without a crisis.

Nobody outside the CA could see which certificates were being issued. After DigiNotar, that gap could no longer be ignored. Google proposed Certificate Transparency in 2012 and shipped enforcement in Chrome by 2018. Every publicly-trusted certificate now appears in append-only logs, and services such as crt.sh make them queryable. That makes misissuance detectable within minutes, but only if someone watches.

Browsers checked revocation status best-effort and, by default, proceeded even when checks failed, leaving compromised certificates valid until natural expiration. The CA/Browser Forum, a consortium of CAs and browser vendors, gradually shortened certificate validity from 60 months in 2012 to 200 days in 2026. This limited the damage any single failure could cause.

Certification Authority Authorization (CAA) gave domain owners a way to constrain certificate issuance. They can publish DNS records declaring authorized CAs, and CAs have been required to check CAA since 2017.

Let’s Encrypt’s first decade brought mass automation, with free certificates starting in 2015. ACME, the certificate-automation protocol, was standardized as RFC 8555 in 2019. Domain validation went from a manual sales transaction to a sub-minute API call.

For code signing, Sigstore brought Certificate Transparency’s design to software signing. The Linux Foundation launched it as a free signing service in 2021. Sigstore’s CA, Fulcio, issues short-lived certificates bound to OpenID Connect (OIDC) identities, such as a developer’s Google or GitHub account. Each issuance is recorded to Sigstore’s public log, Rekor.

PyPI shipped digital attestations in 2024, and npm supports Sigstore-bundled provenance for packages that opt into it. Sigstore’s signing certificates last minutes rather than years, and the keys are ephemeral, generated in memory for one signature and then destroyed.

What it is now.

Today’s public TLS operates on observability, short validity, and active enforcement. Every publicly-trusted certificate is logged, making CA behavior observable to anyone watching. Validity is short enough that bad trust mostly expires before it spreads. The CA/Browser Forum produces the rules, browsers enforce them, and CAs that drift get distrusted.

Code signing hasn’t caught up. Browsers don’t enforce it the way they enforce TLS, there’s no public-log equivalent to CT, and distrust of code-signing CAs is slower and less visible. Code signing still assumes that a publisher’s environment is trustworthy. Sigstore is the structural answer for the open-source ecosystem, but adoption is uneven outside Linux Foundation projects. Enterprise software signing still relies on long-lived CA-issued certificates whose private keys live in environments that can be compromised.

Public TLS has begun shifting to post-quantum cryptography, starting with key exchange. Cloudflare reported that hybrid post-quantum key exchange covered most human-initiated traffic on its network by late 2025. Chrome made hybrid post-quantum key exchange the default in 2024.

Where it’s going.

The CA/Browser Forum has scheduled further cuts to public TLS validity, dropping it to 100 days in 2027 and 47 days in 2029. Domain validation reuse, the time before a CA must re-verify domain ownership, drops to 10 days at the same 2029 milestone. Manual rotation is impractical at 200 days, and untenable at 47.

Signatures are harder to migrate. NIST’s post-quantum signature algorithms produce much larger signatures, pushing TLS handshakes past TCP’s initial congestion window and adding round-trip latency. The CA/Browser Forum has adopted post-quantum profiles for email certificates, where size matters less, but TLS profiles remain in draft.

Google is working with Cloudflare on Merkle Tree Certificates for Chrome. The CA batch-issues certificates and publishes a Merkle tree root, and the server presents an inclusion proof against that root. No per-certificate signature crosses the wire, so handshakes stay small and avoid the latency penalty. First deployments of any post-quantum certificate flavor are expected in 2026, with broad browser trust unlikely before 2027.

What this means.

The web’s trust model became resilient because browsers and CAs addressed every failure with a structural fix. Certificate Transparency emerged from CA opacity, shorter validity from unreliable revocation, and Sigstore from long-lived signing keys. Behind all three are observability, short-lived credentials, and active enforcement.

Beyond public TLS, the same three levers strengthen any delegated-trust system. They apply to code signing, container registries, package repositories, internal PKI, identity federation, and third-party APIs. Without those three levers, any of those trustees becomes a single point of failure for everything relying on its decisions.

Identity federation runs on the same three levers in the form of short-lived OIDC tokens, federated session monitoring, and Continuous Access Evaluation. Long-lived API keys break all three, valid for years even if the issuer is breached.

Security teams can apply this pattern wherever they’ve delegated trust. Each lever maps to one question:

• Observability: Can you see every credential the trustee issued in the last 30 days?
• Short-lived credentials: Will a key leaked today expire before doing damage?
• Active enforcement: Can you enforce consequences when a trustee misbehaves?

The web’s trust model held because every breach forced one of those three answers to yes. So should yours.