Skip to content

fix(attestation): include Azure vTPM AK intermediates#49

Open
samlaf wants to merge 9 commits into
flashbots:mainfrom
SeismicSystems:fix/azure-vtpm-aia-intermediates-clean
Open

fix(attestation): include Azure vTPM AK intermediates#49
samlaf wants to merge 9 commits into
flashbots:mainfrom
SeismicSystems:fix/azure-vtpm-aia-intermediates-clean

Conversation

@samlaf

@samlaf samlaf commented Jun 5, 2026

Copy link
Copy Markdown

This fixes Azure TDX/vTPM attestation verification failures caused by newer Azure vTPM AK certificate chains that are not covered by the currently bundled Global Virtual TPM CA - 03 intermediate.

On a current Azure TDX CVM, the AK leaf certificate chain can look like:

AK leaf
  issuer: Azure Cloud Virtual TPM CA - 24

Azure Cloud Virtual TPM CA - 24
  issuer: Azure Cloud Virtual TPM CA 2025

Azure Cloud Virtual TPM CA 2025
  issuer: Azure Virtual TPM Root Certificate Authority 2023

The TPM NV AK cert index on this VM contained only:

leaf DER || zero padding

so parsing additional intermediates from the TPM AK cert payload is not sufficient for this chain.

This PR changes Azure attestation generation to fetch the AK issuer chain from the leaf certificate’s AIA CA Issuers URLs and serialize those intermediates into the attestation evidence. Verification remains offline: the verifier treats these intermediates as untrusted chain material and still pins the Azure vTPM roots.

Microsoft guidance indicates that AIA should be used to discover Azure vTPM intermediate CAs, since public docs can lag behind production intermediate rotation:

https://learn.microsoft.com/en-us/answers/questions/5897616/download-intermediate-ca-cert-for-azure-cloud-virt

Changes

  • Adds optional evidence field:

    ak_intermediate_certificates_pem: Vec<String>
  • During Azure attestation generation:

    • reads the AK leaf certificate from the vTPM;
    • strips TPM NV zero padding;
    • walks AIA CA Issuers URLs up to a bounded depth;
    • serializes fetched intermediate certs into the evidence.
  • During verification:

    • deserializes evidence-supplied intermediates;
    • bounds the number of supplied intermediates;
    • combines them with the legacy bundled intermediate for backwards compatibility;
    • verifies the AK leaf against pinned Azure vTPM roots.
  • Keeps verification network-free/deterministic.

  • Keeps #[serde(default)] on the new field so old evidence still deserializes.

  • Adds offline fixture tests for the observed Azure chain:

    • Azure Cloud Virtual TPM CA - 24
    • Azure Cloud Virtual TPM CA 2025

Security notes

The fetched intermediates are not trusted anchors. They are serialized as untrusted evidence only. Verification still requires the AK certificate chain to terminate at a pinned Azure vTPM root.

The number of evidence-supplied intermediates is capped to avoid unbounded peer-controlled chain material.

Behavior change

Azure attestation generation now makes outbound HTTP(S) requests to Microsoft PKI/AIA endpoints in order to fetch issuer certificates.

Azure attestation verification does not make network requests.

Validation

Tested with this code on an Azure Standard_DC4eds_v6 TDX box on westus3. Before this change, verification failed with:

WebPKI: UnknownIssuer

After this change:

Generating Azure TDX + vTPM attestation...
Generated azure-tdx evidence: 22148 bytes
Verifying Azure TDX + vTPM attestation...
Verification succeeded.

The generated evidence includes two serialized AK intermediates:

Azure Cloud Virtual TPM CA - 24
Azure Cloud Virtual TPM CA 2025

This subsumes #48.

PR #48 improves handling for cases where the TPM AK cert payload contains concatenated DER intermediates. However, on the Azure TDX VM tested here, the TPM AK cert NV index contained only:

leaf DER || zero padding

and no intermediate certificates. Therefore #48 does not fix the observed UnknownIssuer failure for this chain.

This PR handles that case by following the AIA issuer URLs from the AK leaf certificate and including the resulting issuer chain in the evidence.

Fetch Azure vTPM AK issuer certificates from the leaf certificate's AIA CA Issuers URLs during attestation generation and serialize them into the Azure evidence document.

During verification, treat evidence-supplied intermediates as untrusted chain material, combine them with the legacy bundled intermediate for backwards compatibility, and continue pinning Azure vTPM roots. Bound the number of serialized intermediates during deserialization and keep stripping TPM NV zero padding before WebPKI verification.

Add offline AK-chain fixtures for the observed Azure Cloud Virtual TPM CA - 24 -> Azure Cloud Virtual TPM CA 2025 chain.

@ameba23 ameba23 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the PR! We have let support for Azure slip, because we currently have no production Azure instances. So wonderful to have this fix contributed.

Very good idea to do the intermediary certificate fetching on the 'attester' side rather than the verifier side. One thing we could consider for a followup would be to cache these to avoid re-fetching on subsequent attestation generation.

Great to have the test assets with observed intermediaries. I think it could be useful to have a complete observed attestation payload to test against. We could spin up an Azure instance and get one if you don't want to add this yourself.

We use stable rust but nightly for formatting / clippy, which is why CI fails. This is unconventional and not documented (sorry). Could you please run cargo +nightly fmt && cargo +nightly clippy. Thanks.

@ameba23 ameba23 requested a review from MoeMahhouk June 8, 2026 10:51
pub(crate) fn fetch_ak_intermediates_from_aia(
ak_cert: &X509Certificate<'_>,
) -> Result<Vec<Vec<u8>>, MaaError> {
const MAX_AIA_DEPTH: usize = 6;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to be too arbitrary. Why hardcode the depth? why not fetch all intermediates to verify the full chain? what happens if there were slightly more than 6 for example? would the full chain verification up to the Azure Root CA anchor still succeed?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch! Refactored the fetching logic quite a bit in bd465dd, in part to fetch from all possible URLs, not only the first one; let me know what you think.

As for your question, there was a big inconsistency. I combined MAX_AIA_DEPTH with the more important MAX_EVIDENCE_AK_INTERMEDIATE_CERTIFICATES which is used on the verifier path. The main idea is that we need to protect from DDoS attacks on the verifier side, so we need some bound. 6 is indeed very arbitrary... but I somehow doubt Microsoft would have chains greater than 2/3.... pure hunch though I really have no idea. Happy to increase if you think we should.

};

aia.iter().find_map(|desc| {
if desc.access_method.to_id_string() != "1.3.6.1.5.5.7.48.2" {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

small nit:
what is this hardcoded "1.3.6.1.5.5.7.48.2"? is this some kind of OID? could you please put it behind a const variable with identifiable name to know what it represents?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done: fb10e90

Comment on lines +165 to +170
if bytes.starts_with(b"-----BEGIN") {
let (_type_label, der) = pem_rfc7468::decode_vec(&bytes)?;
Ok(der)
} else {
Ok(bytes)
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

small nit: (no need to change but just curious)
I wonder if this "if condition" is necessary and is not already handled by the pem_rfc7468::decode_vec function instead.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added comment explaining in dc6319a

@MoeMahhouk

Copy link
Copy Markdown
Member

@samlaf , thank you for surfacing this new change from Azure vTPM attestation process side as well as for your contribution to solve the issue.
I skimmed the PR changes quickly and left some comments to review.
Also, I have an extra question:
why is it delegated to the attester to fetch the intermediate certificates along side the vTPM AK leaf certificate?
If I understand this link you shared in the code comments, Azure support recommendation sounded more like it is on the verifier to fetch those intermediate certificate by using the AIA url provided within the AK leaf certificate received during the attestation by the attester.
So I would think that the flow from the attester side stays the same while the verifier should parse the AK leaf certificate to fetch the AIA url and fetch all intermediate certificates used to verify the full certificate chain up to the Azure vTPM anchor CA certificate. Or did I oversee something?

@samlaf samlaf force-pushed the fix/azure-vtpm-aia-intermediates-clean branch from 8b1bc40 to 94a74a3 Compare June 8, 2026 15:29
samlaf added 7 commits June 8, 2026 23:30
fix output dir for fixtures

commit fixtures

update test to use new yaml fixtures

fix fixture generating code (serde_saphyr bug?)

actually fix serializer

make fixture match new serialization format
make from maaerror box

fix clippy: only box MaaError::AiaFetch
Consolidate AK intermediate bounds into a single MAX_EVIDENCE_AK_INTERMEDIATE_CERTIFICATES limit shared by generation and verification, so generated evidence cannot exceed what the verifier accepts.

Fail closed when the AK issuer chain is incomplete or exceeds that limit instead of silently returning a partial chain. When following AIA CA Issuers URLs, try alternate URLs sequentially as fallbacks if earlier URLs fail, and trim fetched DER to the parsed certificate before serializing it as evidence.

Box the large ureq AIA fetch error inside MaaError to keep the error enum size small enough for clippy.
Add local HTTP server tests for AK issuer fetching to verify that AIA caIssuers URLs are tried sequentially when earlier URLs fail, and that explicit PEM responses are accepted as a lenient fallback to DER.

Keep the tests deterministic by using a local server instead of depending on Azure or Microsoft CDN availability.
@samlaf samlaf force-pushed the fix/azure-vtpm-aia-intermediates-clean branch from 94a74a3 to 01e60d4 Compare June 8, 2026 15:30
@samlaf

samlaf commented Jun 8, 2026

Copy link
Copy Markdown
Author

Thanks for the quick feedback guys! Always fun to work with responsive people. :)

Sorry had pushed some unsigned commits from the TDX box... so had to force-push to squash them. Will address comments now.

Great to have the test assets with observed intermediaries. I think it could be useful to have a complete observed attestation payload to test against. We could spin up an Azure instance and get one if you don't want to add this yourself.

@ameba23 refactored the tests to follow your previous yaml file convention. Let me know what you think! 74a7881

So I would think that the flow from the attester side stays the same while the verifier should parse the AK leaf certificate to fetch the AIA url and fetch all intermediate certificates used to verify the full certificate chain up to the Azure vTPM anchor CA certificate. Or did I oversee something?

@MoeMahhouk good question... both options are possible. I went with this option because it felt better in a TEE world to have verification be deterministic, not require a network connection, and be totally self-contained. But if you think otherwise we could support verifier fallbacking to fetching from network. Depends how flexible (but also bug-prone!) we want this library to be I guess. Added a comment on create_azure_attestation in 2ef3e85, let me know what you think.

Comment on lines +644 to +650
let mut serializer_options = serde_saphyr::SerializerOptions::default();
// With compact list indentation enabled, serde_saphyr can emit an
// indentless empty sequence after a nested block sequence, e.g.
// `event_log:\n[]`, which its parser rejects. Disable compact list
// indentation for fixture output so nested/empty sequences are always
// indented under their mapping keys.
serializer_options.compact_list_indent = false;

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like this bug was fixed: bourumir-wyngs/serde-saphyr#126
Prob worth bumping your serde-saphyr dep?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants