security(tee): source and pin the Global Virtual TPM CA - 03 root, or Azure provenance is host-dependent

[imran-siddique]

Split out of #431, which stays closed: its code deliverable shipped and works. This is the gap that code cannot close on its own.

The problem

Azure Trusted Launch presents two vTPM attestation-key certificate hierarchies concurrently at NV index 0x01C101D0. Measured on hardware:

	D2s_v5, eastus, 2026-07-31	D2s_v7, eastus2, 2026-08-01
Certificate size	1596 bytes	994 bytes
Issuer	Azure Cloud Virtual TPM CA - 11	Global Virtual TPM CA - 03
AIA extension	present, 4 caIssuers URIs	absent entirely
Chain to a pinnable root	yes, reaches Azure Virtual TPM Root Certificate Authority 2023	no

cmcp_verify/tpm_roots.py pins only the 2023 root, which the CA-11 hierarchy reaches over AIA. On a host presenting Global Virtual TPM CA - 03 there is no AIA to walk, and tpm2_getcap handles-nv-index confirmed the intermediates are not stored elsewhere in NV as a fallback. So the chain cannot be assembled at all and verify_tpm_quote fails with "AK chain root is not among the supplied trusted TPM roots".

That failure is correct: key provenance genuinely cannot be established on such a host with what we have. But the consequence is that cMCP's TPM provenance story works on some Azure VMs and not others, with no way for an operator to tell in advance. Details and the corrected doc are in #452.

What is needed

1. Obtain the Global Virtual TPM CA - 03 certificate and its chain up to a self-signed root, from a Microsoft-published source that can be cited. It is not fetchable from the AK certificate itself, since there is no AIA.
2. Pin that root alongside AZURE_VTPM_ROOT_2023_PEM, keyed by platform so trusted_roots_for can return both for Azure.
3. Confirm on hardware that a host presenting this hierarchy then verifies end to end. That means provisioning until a VM of that generation is drawn, which is not directly selectable; D2s_v7 in eastus2 produced one on 2026-08-01.
4. Decide what a deployment does when neither root matches: fail closed is the current behaviour and is probably right, but the error should name the unrecognised issuer so an operator can act on it rather than reading a generic chain failure.

Why not just walk AIA

There is nothing to walk. This is the constraint that makes the issue a sourcing problem rather than a code problem, and it is why it cannot be fixed the way #449 and #450 fixed the CA-11 path.

Open question for whoever picks this up

Whether Microsoft publishes the Global Virtual TPM CA - 03 intermediate and root in a durable, linkable location. If not, this becomes the same shape as the client firmware TPM vendor-root problem in the RFC's section 6: a dependency only the platform vendor can resolve. In that case the honest outcome is to document Azure TPM provenance as hierarchy-dependent rather than to keep implying it is universal.

Related: #431 (closed, shipped the chain-carrying code), #452 (the hardware finding), #439 section 6.

[zohebk8s]

Took a run at the open question. Microsoft does publish it - and the chain lands somewhere that resolves this better than expected, so the section 6 fallback doesn't trigger. There's a tested branch below if it's useful, and one unrelated thing further down: the _AIA_MAX_DEPTH cap looks like the same failure waiting to happen on the CA-11 side.

Where it is

Trusted Launch FAQ, "vTPM AK certificate" section:
https://learn.microsoft.com/en-us/azure/virtual-machines/trusted-launch-faq

• Root — durable. Stable URL on Microsoft's PKI server:
  microsoft.com/pkiops/certs/Azure%20Virtual%20TPM%20Root%20Certificate%20Authority%202023.crt
• Intermediate — not durable. Published only as inline PEM in that page, as a .p7b (root + ICA-03) and a standalone .cer. The equivalent pkiops path 404s, so it has to be vendored; there's nothing to fetch at runtime.

The CA-03 root is the root already pinned

Global Virtual TPM CA - 03 is issued directly by Azure Virtual TPM Root Certificate Authority 2023. So step 1 is answered and step 2 collapses — there's no second root to pin, and trusted_roots_for doesn't need to return two.

Verified against Microsoft's PKI server rather than the docs page alone:

• Downloaded the root from pkiops; byte-identical (DER) to both the docs-page copy and to AZURE_VTPM_ROOT_2023_PEM as it stands in tpm_roots.py. All three:
  sha256 e6c596b17f8ffefba5c300f714cfb1260c6028704ecf7becc4ab5018efb00e95
• ICA-03's signature verifies under that downloaded root.
• Not revoked — root CRL is signed by the root, current (next update 2026-09-05); one serial listed, not this one.
• The .p7b, the standalone .cer, and the pkiops download agree byte-for-byte.
• Negative controls: ICA-03 is correctly rejected under an unrelated root, and a single flipped base64 char in its signature is correctly rejected under the real root — so the checks above aren't vacuous.

subject  CN = Global Virtual TPM CA - 03
issuer   CN = Azure Virtual TPM Root Certificate Authority 2023
serial   33000000092740E5AC727B0EA6000000000009
validity 2025-04-24 → 2027-04-24
sha256   FD:7C:92:DA:BC:E4:DC:EC:9F:EA:A3:0F:8B:08:7A:DA:
         05:98:41:31:89:18:21:52:B8:81:F5:56:40:64:A2:9C
SKI      67:09:86:F8:F9:81:5E:93:AD:F9:C9:64:E7:14:0A:DA:99:CB:0A:2D
EKU      2.23.133.8.1, 2.23.133.8.3
BC       CA:TRUE, pathlen:0

Which agrees with the chain logged in #449 from the other end. One PKI, one root, two branches of different depth:

Azure Virtual TPM Root Certificate Authority 2023
├── Azure Cloud Virtual TPM CA 2025 → Azure Cloud Virtual TPM CA - 11 → leaf   (4 certs, #449)
└── Global Virtual TPM CA - 03 → leaf                                          (3 certs)

So "chain to a pinnable root: no" is really "chain cannot be assembled" — the hierarchy does reach the pinned root, there's just no way to walk to it without the intermediate. Worth adjusting the tpm_roots.py comment block for the next reader too, since it currently says "no chain reaches this root".

Two lines in docs/spec/tpm-security-model.md are affected by this as well, both landed in #458:

• "Azure TPM key provenance is hierarchy-dependent until the second CA root is sourced" — there isn't a second root, so the condition can't be met as written.
• "What remains genuinely open is in section 6, and it is not ours to decide: ... whether Microsoft publishes the Global Virtual TPM CA - 03 chain in a citable location" — it does, at the link above. That one can come off the open list.

Where the change goes, and a branch

agent_manifest/_cert_chain.py does no path building. The chain has to arrive complete and leaf-first, and the check is fingerprint equality on the last element:

trusted = {c.fingerprint(SHA256()) for c in roots}
if chain[-1].fingerprint(SHA256()) not in trusted:
    raise TpmVerificationError("AK chain root is not among the supplied trusted TPM roots")

So the vendored bundle has to be consumed by the producer — _chain_from_leaf in cmcp_runtime/tee/tpm.py, which currently ends the walk when there's no AIA and returns just the leaf. That's also why the error names the root: chain[-1] is the leaf. Appending the bundle when the walk terminates early gives [leaf, ICA-03, root].

Two things make that tidy: Microsoft's .p7b for CA-03 contains exactly ICA-03 + root, i.e. precisely the two certs to append, and load_any() in that module already parses PKCS#7, so it can be vendored in its published form.

There's a branch if it's useful — happy for it to be a starting point rather than a proposal, or to be ignored entirely:

https://github.com/zohebk8s/cmcp/tree/fix/ca03-chain-assembly

• New cmcp_runtime/tee/vtpm_ca_bundle.py holding the two certificates, plus vendored_issuer_for().
• _chain_from_leaf consults it when AIA is absent or yields nothing.
• 7 tests. CI green on the full matrix (3.11/3.12/3.13 × ubuntu/windows), plus governance, bandit and pip-audit.

Vendoring a public CA certificate inline is already the pattern here — INTEL_SGX_ROOT_CA_PEM in agent_manifest/_tdx_verify.py, the AMD chain handling in _snp_verify.py, and tpm_roots.py itself. The one way this differs is that those all pin a root, where this pins an intermediate, which rotates on a far shorter cycle than a 25-year root; that asymmetry is what the expiry test below is for.

The design point worth arguing with: vendored_issuer_for returns a candidate only after verify_directly_issued_by confirms it actually signed the certificate being resolved. A name match alone is never enough. That means the trust set is unchanged — these are chain-building material, not anchors — and if Microsoft has re-keyed a CA under the same name, the impostor fails the signature check and behaviour falls back to exactly what happens today. So it's safe to land ahead of the hardware confirmation below; it cannot make a CA-03 host worse than it currently is.

Performance is unchanged: end_to_end p99 measured against an unmodified main control on the same machine came out 9353µs patched vs 10277µs baseline, i.e. indistinguishable. The lookup only runs after the AIA walk has already failed, and it's two in-memory signature checks against a two-element list.

A second, latent instance of the same bug

while len(chain) < _AIA_MAX_DEPTH:   # _AIA_MAX_DEPTH = 4

The cap counts certificates, and the CA-11 chain in #449 is exactly 4 — leaf, CA-11, CA 2025, root. That hierarchy is sitting precisely at the limit with no headroom. If Azure ever inserts another intermediate, the walk truncates one short of the root and fails with the same "AK chain root is not among the supplied trusted TPM roots", for a third distinct reason.

Not urgent, and not something I've changed on the branch since it's orthogonal, but it's the same failure mode waiting to happen and it would be just as hard to diagnose from the error text.

One thing I can't confirm without hardware

Global Virtual TPM CA - 03 is a subject name, not an identity, so I can't rule out more than one CA cert under it. The check is whether the AK cert's AKI on a CA-03 host equals the SKI above.

@imran-siddique — the #452 notes record issuer CN, size and AIA absence but not the AKI. Do you still have the AK cert from the D2s_v7 run? If its AKI is 67:09:86:F8:…:0A:2D that closes it.

One other question while you're in there: the two hosts in the table differ in SKU, region and date at once, so I don't think the data separates "per-host" from "regional" or "generational" yet. Worth knowing which, because if it turns out to be selectable then point 3 gets much easier — the hardware confirmation stops being a lottery. The hardware doc says the 08-01 VM "presented the old form again", which hints there may be observations beyond the two published. Are there?

Notes

• ICA-03 expires 2027-04-24. Roots last 25 years; intermediates don't, and there's no URL to poll for a replacement, so nothing will notice for us. The branch has a test that fails 90 days ahead of that date rather than letting it surface as an outage on a CA-03 host next April.
• Global Virtual TPM CA - 01 on that page expired 2025-11-03 and is still listed, so the page shouldn't be ingested uncritically.
• Point 4 is only half-addressable from this repo. The branch adds a debug log at the truncation point naming the issuer that could not be resolved, but the operator-facing message is raised in agent_manifest/_cert_chain.py — a different repo. Distinguishing "chain incomplete, unrecognised issuer X" from "chain complete, root not pinned" needs a change there.
• Parsing traps: the .crt is PEM despite the extension, and the .p7b blob on the docs page is wrapped in -----BEGIN CERTIFICATE----- though it's PKCS#7 SignedData.

[imran-siddique]

One more thing this blocks, from the 2026-08-01 NV certify run (#460): the certify pair for the gateway measurement is signed by the platform AK, so its appraisal has the same chain dependency. That run drew the Global Virtual TPM CA - 03 hierarchy, so verification had to be anchored on the leaf itself, which exercises the verifier's plumbing but proves no key provenance. Chained verification of the measurement proof has therefore never completed against a real vendor root either. When this root is sourced, the same Azure run should cover both the quote path and the NV certify path.