Intel PTT EK certificate chain incomplete – AIK enrollment fails (HTTP 400)

Welcome to Microsoft Q&A!

Thank you for the detailed diagnostic information.

Based on the information provided, the failure is occurring during Windows AIK certificate enrollment when the Microsoft AIK enrollment service validates the TPM Endorsement Key (EK) credentials submitted in the enrollment request. The service is returning:

"No valid TPM EK/Platform certificate provided in the TPM identity request message."

This error is typically returned when the AIK enrollment service is unable to establish trust in the TPM manufacturer's EK certificate chain presented during attestation. AIK enrollment requires a valid TPM EK certificate chain that can be validated to a trusted TPM manufacturer certificate authority.

Regarding your specific questions:

1. Is this a known PTT EK certificate or chain issue for this CSME/PTT version?

At this time, I am not aware of any published Microsoft advisory identifying Intel PTT firmware version 600.18.1040.2765 as having a known or widespread AIK enrollment defect.

That said, there are publicly reported cases involving Intel PTT-based systems where AIK enrollment fails with the same HTTP 400 error indicating that the submitted EK/Platform certificate chain could not be validated.

Based on the information available, it is not currently possible to determine whether the underlying cause is:

• Missing intermediate certificates on the client
• An Intel EK provisioning issue
• A TPM certificate chain construction issue
• A trust-chain validation issue between the presented EK chain and the Microsoft AIK service

Because the EK certificate and its trust chain originate from the TPM manufacturer, further analysis from Intel would be required to determine whether the certificate chain associated with your platform has been provisioned as expected.

2. Should the intermediate CA certificates be present, and how can they be provisioned?

Intel has publicly documented that newer Intel PTT implementations utilize Embedded Intermediate CA certificates (EICAs) stored in TPM NV indexes. Intel describes a certificate hierarchy consisting of ROM, Kernel, and PTT intermediate authorities that ultimately chain to the TPM EK certificate.

Microsoft's Get-TpmEndorsementKeyInfo cmdlet exposes both the ManufacturerCertificates and AdditionalCertificates collections. However, an empty AdditionalCertificates field by itself does not conclusively confirm that the EK certificate chain is incomplete.

Since EK certificate issuance and provisioning are manufacturer-owned processes, Microsoft does not provide a supported method for manually recreating, replacing, or reissuing Intel EK certificate chains. Verification of the expected certificate hierarchy and any associated provisioning mechanisms would need to come from Intel.

3. Is a CSME firmware update planned that reissues the EK chain?

Microsoft does not control Intel CSME/PTT firmware releases or the issuance of TPM manufacturer certificates. As such, I cannot comment on future Intel firmware updates, planned certificate reissuance activities, or roadmap decisions related to specific Intel firmware versions.

For questions regarding:

• Expected EK certificate hierarchy
• Missing intermediate certificates
• EK certificate recertification
• EK re-provisioning
• Future CSME/PTT firmware releases

Intel would be the appropriate authority to provide guidance and confirmation.

Recommended next steps

1. Whether the EK certificate chain stored in TPM NV validates successfully using TPM diagnostic tooling.
2. Whether the complete Intel-issued intermediate certificate chain expected for the EK certificate is available and trusted on the device.
3. Whether Intel recognizes the EK certificate issuer "CN=CSME ADL PTT 01SVN" and the associated KeyId used during enrollment as valid and supported for AIK attestation scenarios.

Based on the information provided, Windows appears to be successfully reaching the Microsoft AIK enrollment endpoint. The failure occurs during validation of the TPM identity evidence submitted with the enrollment request. For that reason, the available evidence points more toward an EK certificate trust-chain validation issue than a general TPM health, Secure Boot, or Windows provisioning problem.

For concerns related to Intel PTT endorsement key provisioning, embedded intermediate CA certificates, EK certificate hierarchy, or potential CSME/PTT firmware remediation, I recommend continuing engagement with Intel Support.

Ownership of the EK certificate issuance process and TPM manufacturer trust chain resides with the TPM manufacturer. Intel has publicly indicated that newer Intel PTT implementations use the On-Die Certificate Authority (ODCA) model and that portions of the certificate chain may be stored in TPM NV indexes.

While the following resources are not Microsoft sites, these are official Intel support channels:

• Intel Customer Support: Intel Support
• Intel Community Forums: Intel Community
• Intel Security and Manageability (CSME/PTT) Support Channels through your motherboard/OEM vendor for platform-specific firmware updates.

References:

TPM Key Attestation | Microsoft Learn

Get-TpmEndorsementKeyInfo (TrustedPlatformModule) | Microsoft Learn

If you find it useful, please click Accept Answer.

Thank you for choosing Microsoft Q&A.

reviewed this case and concluded that Windows reaches the AIK enrollment endpoint successfully and that the failure occurs while validating the EK certificate trust chain, not because of TPM health, Secure Boot or Windows provisioning. Microsoft stated that EK certificate issuance and the manufacturer trust chain are Intel's responsibility, and referred me to Intel to confirm:

1. Whether the EK issuer "CN=CSME ADL PTT 01SVN" and KeyId 34219b21f477f6c7f78a0f26b23d0430deea4363 are valid and supported for AIK attestation.
2. Whether the Embedded Intermediate CA certificates (ROM, Kernel and PTT CAs) are correctly provisioned in the PTT NV indexes on my platform.
3. Whether a CSME/PTT firmware update or EK re-provisioning procedure is available. I have also confirmed that BIOS 1836 and 1840 both contain the same ME firmware (16.1.40.2765).

Follow-up with new evidence: 1. Updated to BIOS 1840 (same ME 16.1.40.2765). Same HTTP 400. 2. The Intel EICA chain IS present in the TPM: NV index 0x01C00100 (1977 bytes), plus the EK certs at 0x01C00002 (RSA), 0x01C0000A and 0x01C00016 (ECC). So AdditionalCertificates being empty was not the cause. 3. certreq -enrollaik shows the identity request is built against: CN=www.intel.com, OU=ODCA 2 CSME P_ADL 00002226 Issuing CA Request ID: 50016986-83de-41c5-884d-77b0653e0ae2 x-ms-request-id: a1aff807-8026-442c-8967-f40ee5d91095 Response: 400 "No valid TPM EK/Platform certificate provided" Since the client sends the full Intel on-die CA chain, could you confirm whether "ODCA 2 CSME P_ADL 00002226 Issuing CA" is in the Azure AIK service trust pool? This matches other reports where Intel ODCA issuing CAs were not trusted by the service.

Hi Faisal Abdullah!

Thank you for taking the time to provide these additional diagnostics.

I appreciate the detailed testing you have already completed, especially the comparison between BIOS versions and the verification of the certificates stored in the TPM NV indexes. This additional information helps narrow the issue significantly.

Based on your latest findings, I would revise one point from my earlier response. An empty AdditionalCertificates value from Get-TpmEndorsementKeyInfo does not, by itself, establish that the Intel EK certificate chain is incomplete. Your direct inspection of the TPM NV indexes indicates that the Intel Embedded Intermediate CA chain, along with the RSA and ECC EK certificates, is present on the platform.

The evidence now shows the following:

• The Intel Embedded Intermediate CA certificates are present in TPM NV storage.
• The RSA and ECC EK certificates are present.
• BIOS 1836 and BIOS 1840 contain the same Intel ME firmware version, and the enrollment behavior remains unchanged.
• Windows is able to construct and submit the AIK enrollment request.
• The request reaches the Microsoft AIK enrollment service but is rejected with HTTP 400 and the message, “No valid TPM EK/Platform certificate provided in the TPM identity request message.”
• Your enrollment diagnostics identify ODCA 2 CSME P_ADL 00002226 Issuing CA in the certificate path.

Given these findings, a missing local intermediate certificate no longer appears to be the likely explanation.

However, the information available publicly does not allow me to confirm whether this specific Intel ODCA issuing CA is currently included in the Microsoft AIK service's trust configuration. The HTTP 400 response confirms that the TPM identity evidence submitted with the request was not accepted, but it does not identify the specific certificate or validation condition responsible for the rejection.

Therefore, I would not interpret this result alone as proof that ODCA 2 CSME P_ADL 00002226 Issuing CA is missing from the Microsoft service trust configuration. That specific determination requires service-side investigation.

At this point, I also would not recommend clearing the TPM, reinstalling Windows, or manually modifying certificate stores solely to troubleshoot this error. You have already established that the relevant Intel certificate data is present and that the request successfully reaches the enrollment service.

Recommended next step

Please open or continue a Microsoft Support case and request investigation of the AIK enrollment rejection. When submitting the case, include the information you have already collected, particularly:

• The complete certreq -enrollaik result
• The Intel ODCA/EICA certificate chain obtained from the TPM
• ODCA 2 CSME P_ADL 00002226 Issuing CA
• The AIK endpoint/KeyId involved
• The relevant Event 87 entry
• The request and correlation identifiers from a recent failed enrollment
• The date and time, including time zone, of that enrollment attempt
• Confirmation that the behavior is unchanged after updating from BIOS 1836 to BIOS 1840

Those details should provide the information necessary for Microsoft Support to investigate why the submitted TPM identity evidence is being rejected and, where appropriate, correlate the failed request with the service-side records.

I would also recommend continuing the Intel or motherboard-manufacturer case in parallel. They will be in the best position to verify that the EK and Embedded Intermediate CA certificates provisioned on this particular platform are correct for the installed CSME/PTT firmware.

Moreover, your latest testing provides an important clarification: the evidence no longer supports the earlier assumption that an empty AdditionalCertificates collection indicates a missing Intel intermediate CA chain. The remaining issue is that the AIK service is rejecting the TPM identity evidence. Determining whether that is related specifically to the identified Intel ODCA issuing CA, another certificate-validation condition, or a different attestation requirement will require investigation by Microsoft Support together with confirmation of the platform certificate provisioning from Intel or the system manufacturer.

Once again, thank you for providing such thorough diagnostics. They have helped narrow the scope considerably and should also help avoid repeating the TPM and Windows troubleshooting you have already completed.