A compromised intermediate CA is live. Here's your rotation checklist.

What happened

NIST published CVE-2026-111943 flagging a compromised intermediate certificate authority. The entry describes the private key material of a widely-used intermediate CA as having been exfiltrated, with evidence drawn from certificate transparency logs showing issuance patterns inconsistent with the operator's stated policy. The CA's root is not implicated; the intermediate signing key is.

That distinction matters more than most CVE write-ups let on. A compromised root forces a browser-vendor-coordinated distrust event — think DigiNotar in 2011 or Symantec's long unwind from 2017 through 2018. A compromised intermediate, by contrast, is a quieter kind of fire: the root issuer can revoke the intermediate itself, every certificate it signed becomes suspect, and the cleanup lands on whoever operated services behind those leaf certs — not on Mozilla or Chrome.

As of publication, the advisory does not name every leaf certificate issued through the compromised intermediate, but CT logs make this enumerable. Anyone with a `crt.sh` query and the intermediate's SKI can get the list in minutes. Expect that list to circulate on security Twitter and in vendor advisories over the next 48 hours, and expect it to be longer than the operator's initial statement implies.

Why it matters

Most production TLS stacks trust a chain, not a cert. When you curl an endpoint, your client walks from the leaf up through one or more intermediates to a root in your trust store. If an attacker holds an intermediate's private key, they can mint a valid-looking cert for literally any hostname — including hostnames they do not control — and any client that trusts the parent root will accept it until that intermediate is explicitly distrusted.

Three things make this incident thornier than the usual "rotate your certs" headline.

First, the revocation plumbing is still bad in 2026. CRLs are large and slow; OCSP stapling is inconsistently deployed; browser CRLSets and OneCRL are curated lists that lag by hours or days. Chrome and Firefox will likely push a distrust update within a week, but server-to-server traffic — your microservices, your webhooks, your mTLS mesh — doesn't ride on browser trust stores. Those clients use the OS trust store, a bundled `ca-certificates` package, or a hand-curated bundle that your SRE team last touched in 2024. None of those update themselves on a browser-vendor timeline.

Second, pinning cuts both ways. If you pin to the compromised intermediate's SPKI, you are now actively trusting an attacker-controlled key until you ship a release. If you pin to the root, you're fine on that axis but your leaf certs are still forgeable until the intermediate is distrusted upstream. If you pin to the leaf, you're the safest — but you're also the team that has to redeploy within hours of any legitimate rotation. There is no pinning strategy that is simultaneously robust against compromise, cheap to operate, and resilient to legitimate CA changes; this incident is the periodic reminder of that trilemma.

Third, code signing is downstream of this too. If the compromised intermediate chains into any code-signing root your build or install pipeline trusts — Authenticode, Apple notarization intermediates, Java jarsigner chains, Linux package signing — then "any binary signed through this chain" joins "any TLS cert signed through this chain" on the suspect list. Most teams audit TLS trust stores occasionally. Almost no one audits their code-signing trust stores on a quarterly cadence.

Community reaction in the first few hours has split along predictable lines. CA/B Forum regulars are pointing out that this is exactly the scenario post-Symantec reforms were meant to contain — short-lived intermediates, audited key ceremonies, name-constrained sub-CAs — and that the industry walked back several of those after operator pushback. Practitioners are pointing out that ACME and Let's Encrypt have made leaf rotation cheap enough that the real friction is now entirely in the intermediate layer, which almost no one automates.

What this means for your stack

Start with inventory. Run `openssl s_client -showcerts` against your public endpoints and dump the intermediate SKIs; cross-reference against the CVE's listed intermediate. For internal mTLS, dump every cert in your mesh — Istio, Linkerd, Consul, whatever — and do the same. If you use a managed CA (AWS Private CA, GCP CAS, Vault PKI), check whether any of your issuance chains include the affected intermediate. Most managed PCAs operate their own roots, but partner integrations sometimes cross-sign.

For anything chained through the compromised intermediate, treat the leaf cert as compromised even if yours wasn't the key that leaked — because an attacker can mint a parallel cert for the same hostname, and your clients will accept it. Rotate the leaf through a different issuer, not just a different cert from the same chain. If you're on Let's Encrypt, that's a 90-second ACME run; if you're on an enterprise CA, that's a ticket your PKI team was hoping not to get this quarter.

Update your trust bundles. The `ca-certificates` package will ship a distrust soon; make sure your base images rebuild to pick it up, and make sure your long-running containers are redeployed, not just restarted — a cached in-memory trust store doesn't notice disk updates. For HSM-based signing, confirm that revocation of the intermediate propagates to whatever validation step your signer performs; some HSM-backed signers only validate at key-provisioning time, not per-signature.

Finally, audit CT logs for your own domains. If an attacker has already minted a cert for `yourcompany.com` through this intermediate, it will appear in CT logs within a day or two of issuance. Services like Cert Spotter and Facebook's CT monitor will email you on new issuance; if you don't have that wired up, this week is a good week to do it.

Looking ahead

The long-tail consequence of CVE-2026-111943 isn't the rotation itself — most ops teams can get through that in a sprint. It's that this is the second serious intermediate-CA incident in eighteen months, and the industry's answer so far has been "shorter-lived intermediates and better monitoring," neither of which addresses the fact that the trust model still has single points of compromise that can forge arbitrary identity. Expect renewed interest in name-constrained intermediates, in short-lived certs by default, and — in the longer arc — in post-quantum trust hierarchies that quietly rebuild some of this plumbing anyway. The best time to automate intermediate rotation was five years ago. The second best time is before the next CVE lands.