up:: Classical Cryptography MOC

Certificate Authority

A certificate authority (CA) is the trusted entity that issues and digitally signs the certificates computers use to prove who they are. When a website, a piece of software, or a device presents a certificate, a CA has vouched for it by signing a statement that binds a public key to that identity, and everyone who trusts the CA extends that trust to whatever it signed. A CA is one component of the larger PKI system, and it’s the load-bearing one, because the CA’s own signing key is what makes every certificate underneath it believable. Break that one key and the whole population beneath it becomes forgeable, which is why a CA signing key is the highest-value target in the quantum transition.

The short version:

• A CA is the trusted issuer in PKI. It signs certificates that bind a public key to an identity, and relying parties trust those certificates because they trust the CA’s signature.
• CAs are arranged in a hierarchy. A root CA is a self-signed trust anchor kept offline; it signs intermediate CAs, which do the day-to-day issuing.
• A relying party trusts a certificate by following the chain of trust up from the certificate to a root it already has in its trust store.
• Two worlds of CAs anchor trust: public CAs (the ones browsers trust, governed by the CA/Browser Forum) for the open internet, and private/enterprise CAs an organization runs for its own users, devices, and code.
• A CA’s signing key is the highest-blast-radius key anywhere, because Shor’s algorithm recovers its private key from the public one and forges every certificate under it at once (PKI collapse). That’s why CA signing keys are the first thing to migrate to ML-DSA or SLH-DSA.

An everyday analogy

Think of a CA as a notary whose seal everyone in the country has agreed to honor. The notary doesn’t personally know the millions of people whose documents they stamp; they follow a strict procedure to confirm an identity, then apply a seal that any bank, court, or office will accept without re-checking. A senior notary appoints deputies and lends them authority to stamp, so the work scales. You honor a stamped document because you recognize the seal and trust the office behind it, not because you know who carried it in. A root CA is that country-wide seal, the deputies are intermediate CAs, and the list of seals you’ve agreed to honor is your trust store. The catch in the quantum story is that the seal here is a piece of math, and a large enough quantum computer can carve a perfect copy of it from the public imprint alone.

What is a certificate authority?

A certificate authority is an organization or system that operates under a defined policy to issue, sign, and manage digital certificates. Its core job is to make one assertion trustworthy at scale: this public key genuinely belongs to this identity. It makes that assertion by taking a certificate request, verifying the requester’s identity through a defined process, and then signing the resulting X.509 certificate with the CA’s private signing key. Because only the CA holds that private key, only the CA can produce a signature that validates against the CA’s public key, so a signed certificate can’t be forged without the key.

The X.509 certificate a CA produces carries the subject’s public key, the subject and issuer names, a validity period, key-usage constraints, and the CA’s signature over all of it, as profiled for Internet use by RFC 5280.

Source: IETF, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” RFC 5280, May 2008, RFC 5280.

A CA is distinct from the rest of PKI in a way worth holding onto: PKI is the whole system (the certificate format, the chains, the trust stores, the revocation machinery), while the CA is the specific actor that signs. Identity vetting is often split off to a Registration Authority (RA), which checks who the requester is before the CA signs, so the CA’s key material touches as few systems as possible. That separation is a security control, not a formality, because everything a CA is worth protecting comes down to protecting its signing key.

Why is a CA arranged as a root and intermediate hierarchy?

Because a CA’s most valuable asset, its signing key, should be exposed as little as possible, and a hierarchy is how you square that against issuing millions of certificates. The structure has three tiers, each with a deliberate job:

1. Root CA. The trust anchor. Its certificate is self-signed (nothing sits above it to vouch for it), and its public key is distributed directly into trust stores. A root CA’s private key is kept offline, in a hardware security module, and used rarely, often only to sign intermediates during controlled key ceremonies. It is the single most sensitive cryptographic asset in the whole deployment.
2. Intermediate (issuing) CA. Signed by the root, an intermediate does the day-to-day work of issuing end-entity certificates. Keeping the root offline and letting intermediates take the operational load means a compromised intermediate can be revoked and replaced without having to change the root that’s embedded in every trust store on earth.
3. End-entity (leaf) certificate. Not a CA at all, but what the CAs exist to produce: the certificate issued to a specific website, person, device, or code-signing identity.

The reason for the layering is operational isolation. If the busy, exposed issuing key had to be the root, then any compromise would mean re-distributing a new root to every relying party, which is the slowest, most painful operation in all of PKI. By putting a replaceable intermediate between the root and the daily grind, a CA operator contains most failures well below the level that would force a trust-store update.

Tier	Signed by	Key handling	Job
Root CA	Itself (self-signed)	Offline, in an HSM, used rarely	Trust anchor embedded in trust stores; signs intermediates
Intermediate CA	The root (or another intermediate)	Online, protected, used constantly	Issues end-entity certificates day to day
End-entity certificate	An intermediate CA	Held by the subject	Proves the identity of a site, person, device, or code

How does the chain of trust actually work?

Trust flows downward through a chain of signatures, and a relying party verifies it upward. When your browser receives a website’s certificate, it doesn’t recognize that specific certificate; it recognizes, or eventually reaches, a root it already trusts. Validation walks the chain:

1. The leaf certificate carries the issuing intermediate’s name. The verifier checks the intermediate’s signature on the leaf.
2. The intermediate certificate carries the root’s name. The verifier checks the root’s signature on the intermediate.
3. The root is self-signed, and the verifier checks whether that root is present in its trust store. If it is, the chain is anchored and validation succeeds. If the chain reaches no trusted root, validation fails.

Every link is a signature made with a CA’s private key and checked with that CA’s public key, so the entire structure rests on one property: a CA’s signature is unforgeable to anyone who doesn’t hold its private key. Break the signature at any level and everything below it becomes forgeable, which is exactly why the keys at the top of the chain carry the most risk. A CA also has to be able to pull trust back early, before a certificate’s validity period ends, which it does through revocation (Certificate Revocation Lists and the Online Certificate Status Protocol); the mechanics of revocation belong to PKI as a whole.

What is a trust anchor and how does a CA become one?

A trust anchor is a CA that a relying party trusts a priori, without needing anyone else to vouch for it, and in practice that means a root CA whose certificate has been placed in a trust store. A trust store is the list of root CAs a given system has decided to trust, and here’s the fact that governs the entire quantum migration: every operating system, browser, and language runtime keeps its own independent trust store. Chain validation only succeeds if the chain lands on a root in that system’s store, so a certificate valid on one machine can fail on another that trusts a different set of roots.

A CA becomes a trust anchor by getting its root certificate into those stores, and that is a gated, audited process, not a technical upload:

1. Public CAs apply to the root programs run by the major platform and browser vendors (for example the ones operated by Microsoft, Apple, Google, and Mozilla). Admission requires meeting the CA/Browser Forum Baseline Requirements and passing independent audits, and inclusion propagates to users through operating-system and browser update cycles.
2. Private/enterprise CAs become trust anchors within an organization by having their root pushed into the trust stores of managed devices through configuration management, so internal systems trust internally-issued certificates.

Source: CA/Browser Forum, “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates,” CA/Browser Forum Baseline Requirements.

The distribution dependency is the whole reason a CA migration is measured in years. Getting a new root trusted everywhere means shipping it into every one of those independent stores, on update schedules no single CA controls.

Where do CAs anchor trust in the real world?

Two distinct populations of CAs carry the weight, and mistaking the scope of one for the whole is the most common way organizations underestimate their exposure.

1. Public CAs anchor the open internet. A small set of commercial and nonprofit CAs (names like DigiCert, Sectigo, and Let’s Encrypt) issue the certificates that let any browser trust any website it has never seen before. These operate under the CA/Browser Forum Baseline Requirements and the platform root programs, and they underpin TLS/HTTPS, publicly-trusted code signing, and cross-organization trust generally.
2. Private/enterprise CAs anchor an organization’s internal trust. Most large organizations run their own internal CA hierarchy that issues certificates no public browser needs to trust: client certificates for VPN and Wi-Fi authentication (802.1X, EAP-TLS), certificates for zero-trust access, machine and service identity inside a data center or service mesh, internal code and firmware signing, and device certificates. This surface is usually larger and less well inventoried than the public certificates people picture.

Both worlds do the same job, proving who rather than keeping data secret, and both are quantum-vulnerable in the same way, because both sign with RSA and ECDSA. A cryptographic inventory scoped to “our public TLS certificates” misses most of the real CA trust surface, which is why every issuing CA an organization operates belongs in a CBOM.

Why is a CA signing key the highest-value quantum target?

Because a CA signing key is a trust multiplier, and its matching public key is already published in the open. A single root or intermediate CA vouches for a huge population of certificates, so the blast radius of breaking one CA key isn’t one system, it’s everything that key underwrites. The reasoning runs in three moves:

1. The target is public by design. A CA’s public signing key appears in its certificate, which sits in trust stores, is served during handshakes, and is logged in Certificate Transparency records (RFC 6962). There’s no traffic to intercept and no vault to breach, because the input an attacker needs is already published.
2. Shor’s algorithm turns the public key into the private one. A cryptographically relevant quantum computer running Shor’s algorithm recovers the private signing key from the public key for both RSA and ECDSA. The CA’s HSMs, physical security, and access controls are all irrelevant to this, because the key is computed rather than stolen.
3. One broken CA forges everything beneath it. With the private key, an attacker mints certificates that are cryptographically valid for any name they choose, and each passes standard validation because the signature is correct and chains to a trusted root. When the broken key is a widely-trusted root, the result is PKI collapse, where trust for potentially millions of systems fails at once.

Source: IETF, “Certificate Transparency,” RFC 6962, June 2013, RFC 6962.

This is a trust attack, not a secrecy one, which puts it in the Non-HNDL class: it targets integrity and authentication in real time and needs a live quantum computer at the moment of the forgery. For the full anatomy of the catastrophe and the published qubit resource estimates behind it, PKI collapse is the deep-dive; this note is about the entity whose key is at stake.

Why do CA signing keys migrate first?

Because they carry the largest blast radius and the longest lead time, which is the worst possible combination and puts them at the front of the signature-migration queue. The fix is to move the CA’s signing key off RSA and ECDSA and onto a NIST-standardized post-quantum signature, starting at the top of the hierarchy:

1. Roots and intermediates move before leaves. The highest-blast-radius keys are the CA keys, so those migrate first. Reissuing end-entity certificates while a CA’s own key stays classical leaves the real vulnerability in place, because the attacker forges from the CA, and every fresh leaf is just as forgeable.
2. ML-DSA is the general-purpose replacement, the primary choice for CA and certificate signing. SLH-DSA, a conservative hash-based signature, is the backstop for very long-lived or high-assurance roots, where mathematical diversity from lattice-based schemes is worth the larger signatures.
3. The plumbing has to be ready first. CA private keys live in hardware security modules that must support the new algorithms, generating a new root requires a formal air-gapped key ceremony, and every certificate parser, TLS library, and revocation responder has to recognize the new algorithm identifiers before a post-quantum certificate is valid in production.
4. The clock is fixed. U.S. national-security policy sets 2035 as the outer date for completing the transition, and because re-rooting a CA and getting the new root into every trust store takes years, the planning problem is present-day even though a capable quantum computer doesn’t exist yet.

Replace	With	Best for
RSA / ECDSA CA and certificate signatures	ML-DSA	General-purpose CA and certificate signing, the primary choice
RSA / ECDSA long-lived root signatures	SLH-DSA	Conservative hash-based backstop for high-assurance or very long-lived roots

Because a CA hierarchy can’t flip all at once, the changeover usually runs through bridging structures: composite certificates carry both a classical and a post-quantum signature so old and new verifiers both validate, and crypto-agility (the ability to change a CA’s signing algorithm without rebuilding the infrastructure) is the precondition that makes any of it feasible.

Sources: NIST, “Module-Lattice-Based Digital Signature Standard,” FIPS 204, August 2024, FIPS 204.

NIST, “Stateless Hash-Based Digital Signature Standard,” FIPS 205, August 2024, FIPS 205.

NSA, “CNSA 2.0 FAQ” (PP-24-4014, December 2024 update), which sets 2035 as the completion date for the National Security Systems transition, CNSA 2.0 FAQ.

Common misconceptions

1. “A certificate authority and PKI are the same thing.” A CA is one component of PKI, the entity that issues and signs certificates. PKI is the whole system around it: the CAs, the X.509 format, the chains of trust, the trust stores, and the revocation machinery.
2. “There’s one big list of trusted CAs.” Every operating system, browser, and runtime keeps its own independent trust store, so a certificate that validates on one system can fail on another that trusts a different set of roots. That fragmentation is precisely what makes distributing a new post-quantum root slow.
3. “Only the public web CAs matter.” The private enterprise CAs an organization runs itself, issuing client, device, machine, and code-signing certificates, are usually a larger and more fragile trust surface than the public certificates people picture, and they’re the organization’s own problem to migrate.
4. “To break a CA, an attacker has to hack into it.” For the quantum threat, the private key is computed from the published public key with Shor’s algorithm, so the CA is never touched. Its HSMs and physical security are irrelevant to that break.
5. “Reissuing all our certificates is the migration.” Leaf certificates are the fast part. The long pole is migrating the CA’s own signing keys and getting the new root trusted across every trust store, a multi-year, ecosystem-wide effort.
6. “A root CA does the everyday issuing.” A root CA is kept offline and used rarely, mostly to sign intermediates. Intermediate CAs handle day-to-day issuance, precisely so the root stays protected.

Questions people ask

What is the difference between a CA and PKI? A certificate authority is the trusted entity that issues and signs certificates. PKI is the entire system that makes those certificates usable at scale: the CAs plus the X.509 certificate format, the chains of trust, the trust stores, and the revocation infrastructure. The CA is the actor; PKI is the framework it operates within.

What is the difference between a root CA and an intermediate CA? A root CA is a self-signed trust anchor whose key is kept offline and used rarely, and whose certificate is embedded directly in trust stores. An intermediate CA is signed by the root and does the day-to-day certificate issuing. The split exists so a compromised intermediate can be revoked and replaced without disturbing the root that lives in every trust store.

How does a CA get trusted by my browser? A public CA applies to the root programs run by platform and browser vendors, meets the CA/Browser Forum Baseline Requirements, passes independent audits, and its root certificate is then shipped into trust stores through operating-system and browser updates. Once the root is in your trust store, your browser trusts any certificate that chains up to it.

Is a certificate authority affected by quantum computing? Yes, severely. A CA signs with RSA or ECDSA, and both are broken by Shor’s algorithm on a large enough quantum computer, which lets an attacker recover the CA’s private key from its public one and forge certificates under it. Because one CA key underwrites many certificates, a CA is the highest-blast-radius target in the transition.

Which CA key has to be migrated first? The root and intermediate signing keys, because they sit at the top of the chain and vouch for everything beneath them. Migrating leaf certificates while a CA key stays classical leaves the actual exposure untouched, since an attacker forges from the CA itself.

What replaces a CA’s signing algorithm? ML-DSA is the general-purpose replacement for CA and certificate signing, with SLH-DSA as a conservative hash-based option for very long-lived or high-assurance roots. Both are finalized NIST standards published in August 2024.

Do I need to run my own CA? Many organizations do, for internal trust that public CAs don’t serve: VPN and Wi-Fi client authentication, service and device identity, and internal code signing. Those private CAs are the organization’s own responsibility to inventory and migrate, and they’re often a bigger quantum-exposure surface than the public certificates that get all the attention.

What happens if a CA’s key is broken? An attacker can mint certificates that validate for any identity they choose, and they pass standard checks because the signature is mathematically correct and chains to a trusted root. When the broken key belongs to a widely-trusted root, the result is PKI collapse, a trust failure across every system that trusted that CA, with no clean after-the-fact recovery.

---

Everything here is the map, given freely. When your team needs its own certificate authorities found, sized, and sequenced onto a post-quantum path before the machine arrives, that’s the work I do. Request an alignment briefing.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.