Recently, we’ve seen Windows Autopilot devices, particularly HP EliteBooks and Lenovo T480s, encountering 0x800705b4 timeout errors during TPM attestation. This crucial step ensures that a device’s TPM is trusted, but something is going wrong in the process, causing these models to fail during deployment.
In this post, we’ll explore the typical TPM attestation flow, examine the Windows Autopilot TPM Attestation errors, and investigate why these specific devices are experiencing issues.
Calling the Autopilot Attestation Fix-Man!
So, there I was, enjoying my coffee when suddenly, a message lit up my Discord, complete with a “Bat-Signal” of sorts (see image for reference 👀). It was time to step up.
As we all know, Patch My PC does incredible work for the community, and this time, I’m doing my part by answering the call for help. Devices were failing TPM attestation during Windows Autopilot for pre-provisioned deployments (White-glove) with the dreaded Windows Autopilot TPM Attestation 0x800705b4 error!
As shown above, during securing your hardware, the 0x800705b4 was thrown at my feet.
It was time to dive deep and help fix this issue for everyone. I’ll be teaming up with Microsoft on this one to crack the case and get those attestation failures resolved. Here’s a breakdown of the issue, the attestation flow, and why a recently renewed CA 035 certificate might be causing more headaches than expected for devices like the HP EliteBook 800 and Lenovo T480. Let’s dive in and fix this together for the community!
Everything Happens for a reason.
Interestingly, this isn’t the first time I’ve encountered this particular issue. In another case I was working on, someone contacted me about a device that failed during app installations in the Autopilot enrollment process. It turned out there was a cryptographic issue with secure channels. This issue caused the IME to be unable to contact the service. You can read about that situation here. (which is still work in progress until msft comes up with the fix)
Fast forward to the Discord message I received, and I couldn’t help but notice something familiar. The device involved was pretty similar to the one I had been working on in that earlier case. His devices that failed TPM attestation had the same Infineon TPM.
It felt like a déjà vu moment, as the root cause behind both issues seemed to share a common thread.
That’s when I realized there might be more at play here, and it required a deeper look into what could be causing these devices to behave this way.
How TPM Attestation Should Work
When a device is enrolled through Windows Autopilot for provisioned deployments, it undergoes TPM attestation as part of the security validation. The goal is to ensure that the device’s TPM (Trusted Platform Module) is genuine, secure, and able to protect the system’s cryptographic keys.
You can kick off this process quite easily by entering certreq -enrollaik -config “” from a cmd Not PowerShell! Otherwise, you would receive the 0x80070057 the parameter is incorrect error)
Besides using the certreq tool (like I always do) you can also use the tpmdiagnostics tool.
When we execute the command to enroll the Windows AIK Cert, the normal attestation process will involve a couple steps:
GetCACaps: The device communicates with the server to determine the Certification Authority’s (CA) supported capabilities, such as algorithms and protocols.
GetCACertChain: The device retrieves the necessary certificates from the CA to validate its trust in the root and intermediate certificates. This is called walking the cert chain
PKIOperation: The device sends a signed certificate signing request (CSR) using its TPM’s Endorsement Key (EK). The server verifies the request against the CA chain and responds with a signed certificate, confirming that the TPM attestation was successful.
So, what’s going wrong? Everything seems to proceed as expected until the PKIOperation step, where the server refuses to accept the TPM’s identity, resulting in a 0x800705b4 timeout error. After tracing the issue, it became clear that something deeper was affecting the process.
When looking at the error we got when trying to enroll, things become a bit more strange
0x80190190 (2145844848 HTTP_E_STATUS_BAD_REQUEST)
After executing the certenroll command on our own device, this is what it told us
First off, it tells us that there is no valid TPM EK/Platform certificate provided in the TPM Identity request message. Which is pretty weird as the device has the EK cert and it was ready for attestation?
Besides telling us that it failed to provide the EK/Platform it also shows us the error 0x80190190 which corresponds to Bad request (400). What’s happening here?
Confirming the Presence of the EKCert
One of the first things we did was check whether the device had the EKCert (Endorsement Key Certificate) installed.
Using the TPMDiagnostics tool and the get-tpmendorsementkeyinfo command, we confirmed that the EKCert was present on the device.
This validation was echoed in the event logs as well, showing that the AutopilotManager had successfully located the AIK key and the EK certificate.
However, despite the Endorsement Key (EK) certificate being present, the logs also indicated that the AIK key failed the certificate request, returning an HRESULT = 0x80090011 error, further pointing to a problem with the attestation process.
Things are becoming stranger and stranger. Well this is what I really love… With the EK Cert on the device, it’s time to walk the chain!
Walking The Chain
I made sure I got Fiddler in place from system context (otherwise you won’t spot it)
With Fiddler enabled I manually tried to enroll the AIK certificate and by the looks of it, the next TPM attestation step breaks after walking the chain. Let me explain a bit about how this chainwalk works from a bigger perspective.
Device (Client)
The device’s TPM has an Endorsement Key (EK) that is signed by the Infineon OPTIGA(TM) RSA Manufacturing CA 035.
The device presents its EK certificate to the attestation server as part of the TPM attestation process.
Intermediate Certificate: CA 035
CA 035 is the intermediate certificate issued by Infineon.
This certificate acts as a trusted link between the TPM’s EK certificate and the root certificate that the attestation server trusts.
Root Certificate: Microsoft TPM Root CA
The root certificate is the Microsoft TPM Root Certificate Authority 2014.
The root certificate is trusted by the attestation server and validates the CA 035 certificate.
The Intermediate Certificate
Even with the whole CACertChain response scrambled, you can read through the lines. While doing so, I downloaded each certificate from the response and started looking at it.
This certificate url corresponds to the Intermediate one.
It seems all valid, right? Upon further investigation, I started having doubts about this CA 035 certificate issued by Infineon.
This certificate was renewed just a few months ago, and judging by its smell, it is causing the attestation failures. If you look back at what happens when walking the chain, this CA035 certificate is pretty important in the process. Why? Let me show you once again!
As shown above, this ca 035 needs to be validated. What if there was a misalignment in the Microsoft attestation services?
Certificate Chain Mismatch
After a great conversation with my friends from Microsoft, they identified and resolved the issue. With the issue being resolved I was curious what changed. After executing the same AIK enrollment commands, we will notice that we got a different CA certificate.
We now get an older one instead of the one that was valid from 6/6/2024! Now that Microsoft changed the CA certificate, devices using Windows Autopilot for Pre-provisioned deployment and using the Infineon TPM with the CA 035 should no longer face this problem. Problem solved once again!
To end the story with a summary: Walking the Chain is one of the most important steps during attention. When the certificate is not trusted everything crumbles and your device will fail to perform attestation!.