Intel PTT AIK enrollment fails with HTTP 400 – Intel ADL EK certificate rejected by Microsoft AIK service

Hello Timur,

Based on the information provided, this does not look like a basic TPM-health, Secure Boot, or Windows configuration problem.

Your diagnostics show that:

TPM 2.0 is present and ready.

Intel PTT is enabled.

Secure Boot and UEFI are enabled.

Windows reports the TPM as capable of attestation.

AIK enrollment reaches the Microsoft AIK service.

The request fails specifically at SubmitRequest.

Microsoft returns HTTP 400 with: No valid TPM EK/Platform certificate provided in the TPM identity request message.

There are also several recent Microsoft Q&A reports involving Intel CSME/PTT and Intel ADL EK certificates with the same HTTP 400 response. One report specifically identifies an Intel ODCA 2 CSME P_ADL issuing CA and reaches the same EnrollStage = 220 / SubmitRequest failure.

What this indicates

The important distinction is that the TPM can be healthy locally while the Microsoft AIK service can still reject the EK certificate presented for attestation.

Microsoft's documentation explains that Windows provisions an AIK through a Microsoft cloud service and that the AIK certificate is issued by that service. The EK/EK certificate is part of the trust relationship used during this process.

Therefore, the HTTP 400 response does not by itself mean that your physical TPM is defective.

About the Intel issuing CA

I could not find a public Microsoft document confirming that:

CN=www.intel.com, OU=ODCA 2 CSME P_ADL 00002701 Issuing CA

is currently accepted by the Microsoft AIK service.

That is an important distinction: the public documentation does not provide a complete public list from which we can confirm that particular Intel CA is provisioned in Microsoft's AIK infrastructure.

The fact that your request reaches SubmitRequest and is then rejected with "No valid TPM EK/Platform certificate" is consistent with the service being unable to validate/accept the EK information supplied in the request, but the exact server-side reason cannot be determined from the client error alone.

What I would do next

Since you have already updated:

motherboard BIOS,

Intel ME firmware,

Windows,

TPM 2.0 configuration,

Secure Boot,

I would avoid repeatedly clearing the TPM or reinstalling Windows as a first response. Those actions do not establish that the Microsoft-side EK trust problem has been resolved.

Instead, collect the following information for Microsoft support:

TPM manufacturer: INTC
TPM model: ADL
EK issuer:
CN=www.intel.com, OU=ODCA 2 CSME P_ADL 00002701 Issuing CA

AIK authority:
INTC-KeyId-7a543ff6ca11d099679c36a611f261efc15d52092

HTTP status:
400 Bad Request

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

EnrollStage:
220

x-ms-client-request-id:
58badf96-827a-4226-89d5-59e527e2610e

x-ms-request-id:
2574918c-385a-4ae5-b986-c5bfe3b1f09c

Ask Microsoft specifically to determine whether the Intel ADL EK issuing CA and the corresponding INTC-KeyId-* authority are currently recognized by the Microsoft AIK/attestation service.

If the service-side trust/provisioning is the problem, that is not something a normal Windows client repair, SFC/DISM operation, TPM reset, or Secure Boot change can independently fix. Similar Intel PTT reports have been escalated around this same class of AIK-service rejection.

Also, the 404 result you obtained for the derived microsoftaik.azure.net authority is useful diagnostic evidence, but I would not independently interpret it as proof that the CA is missing. The authority naming and service behavior need to be confirmed by the Microsoft AIK/attestation team.

So the most appropriate question for Microsoft support is:

Can Microsoft confirm whether the Intel ADL PTT EK chain issued by ODCA 2 CSME P_ADL 00002701 Issuing CA and authority INTC-KeyId-7a543ff6... is currently provisioned and trusted by the Microsoft AIK service?

That should allow the issue to be separated cleanly into either a client/firmware EK problem or a Microsoft AIK-service trust/provisioning problem, without unnecessarily resetting a healthy TPM.Hello Timur,

Based on the information provided, this does not look like a basic TPM-health, Secure Boot, or Windows configuration problem.

Your diagnostics show that:

TPM 2.0 is present and ready.

Intel PTT is enabled.

Secure Boot and UEFI are enabled.

Windows reports the TPM as capable of attestation.

AIK enrollment reaches the Microsoft AIK service.

The request fails specifically at SubmitRequest.

Microsoft returns HTTP 400 with:
No valid TPM EK/Platform certificate provided in the TPM identity request message.

There are also several recent Microsoft Q&A reports involving Intel CSME/PTT and Intel ADL EK certificates with the same HTTP 400 response. One report specifically identifies an Intel ODCA 2 CSME P_ADL issuing CA and reaches the same EnrollStage = 220 / SubmitRequest failure.

What this indicates

The important distinction is that the TPM can be healthy locally while the Microsoft AIK service can still reject the EK certificate presented for attestation.

Microsoft's documentation explains that Windows provisions an AIK through a Microsoft cloud service and that the AIK certificate is issued by that service. The EK/EK certificate is part of the trust relationship used during this process.

Therefore, the HTTP 400 response does not by itself mean that your physical TPM is defective.

About the Intel issuing CA

I could not find a public Microsoft document confirming that:

CN=www.intel.com, OU=ODCA 2 CSME P_ADL 00002701 Issuing CA

is currently accepted by the Microsoft AIK service.

That is an important distinction: the public documentation does not provide a complete public list from which we can confirm that particular Intel CA is provisioned in Microsoft's AIK infrastructure.

The fact that your request reaches SubmitRequest and is then rejected with "No valid TPM EK/Platform certificate" is consistent with the service being unable to validate/accept the EK information supplied in the request, but the exact server-side reason cannot be determined from the client error alone.

What I would do next

Since you have already updated:

motherboard BIOS,

Intel ME firmware,

Windows,

TPM 2.0 configuration,

Secure Boot,

I would avoid repeatedly clearing the TPM or reinstalling Windows as a first response. Those actions do not establish that the Microsoft-side EK trust problem has been resolved.

Instead, collect the following information for Microsoft support:

TPM manufacturer: INTC
TPM model: ADL
EK issuer:
CN=www.intel.com, OU=ODCA 2 CSME P_ADL 00002701 Issuing CA

AIK authority:
INTC-KeyId-7a543ff6ca11d099679c36a611f261efc15d52092

HTTP status:
400 Bad Request

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

EnrollStage:
220

x-ms-client-request-id:
58badf96-827a-4226-89d5-59e527e2610e

x-ms-request-id:
2574918c-385a-4ae5-b986-c5bfe3b1f09c

Ask Microsoft specifically to determine whether the Intel ADL EK issuing CA and the corresponding INTC-KeyId-* authority are currently recognized by the Microsoft AIK/attestation service.

If the service-side trust/provisioning is the problem, that is not something a normal Windows client repair, SFC/DISM operation, TPM reset, or Secure Boot change can independently fix. Similar Intel PTT reports have been escalated around this same class of AIK-service rejection.

Also, the 404 result you obtained for the derived microsoftaik.azure.net authority is useful diagnostic evidence, but I would not independently interpret it as proof that the CA is missing. The authority naming and service behavior need to be confirmed by the Microsoft AIK/attestation team.

So the most appropriate question for Microsoft support is:

Can Microsoft confirm whether the Intel ADL PTT EK chain issued by ODCA 2 CSME P_ADL 00002701 Issuing CA and authority INTC-KeyId-7a543ff6... is currently provisioned and trusted by the Microsoft AIK service?

That should allow the issue to be separated cleanly into either a client/firmware EK problem or a Microsoft AIK-service trust/provisioning problem, without unnecessarily resetting a healthy TPM.