Again… I am writing a blog about TPM attestation. Why? Because sometimes, even when your device doesn’t have the Intel 11 gen or it isn’t an AMD device, you could still end up with some attestation errors during Autopilot for modern deployments.
I guess today something broke at Microsoft
So I will create a separate blog to summarize the troubleshooting stuff I showed in the TPM attestation series
I will divide this blog into multiple parts
1. The Issue
First, let’s start with the issue that starts occurring again today. We were (trying) to enroll 30 new Lenovo devices into Autopilot for pre-provisioned deployment.
Of course, we made sure we have the latest Win10 21h2 Build KB5007253 which fixes the Intel Tiger Lake attestation issue like I am describing in this blog
But this time, the devices didn’t have a firmware-based Intel (11th gen), AMD, or Qualcomm TPM but one from Nuvoton! So we should expect no issues with that one, right?
Think again! We ended up with the error: TPM attestation failed! 0x81039001 !
So no deployments for us today, let me explain how to start troubleshooting
2. How to troubleshoot TPM Attestation issues
I already did some blogs about this topic… but let me summarize how you could detect what is going on?
Of course, we need to determine first if Attestation is even possible and if the device has the proper TPM version. To do so enter this command: TPMtool getdeviceinformation. This will give you a simple overview of the TPM capabilities
Now we are sure everything is good to go, let’s go forth!
As shown in my other blogs, I am using the certreq tool to determine if its possible to start the AIK enrollment. So let’s start with that one by entering this command: certreq -enrollaik -config “”
Take a look at the screenshot above. I am going to explain it some more. Normally It will show you the AIK enroll url it is using.
Please note: You need to enter the “” after -config, if you define something else (Like ”), the AIK attestation URL is not going to work! You will end up with a screen giving you the error: 0x80072ee5 (WinHttp: 12005 ERROR_WINHTTP_INVALID_URL)
2.3 TrustedTPM File
After running the certreq tool, we finally fetched the AIK URL. But we still need to check if the AIK URL is a valid one. To do so please download the trustedtpm.cab file from the Microsoft site
Please note: In the screenshots above you could have noticed the NTC-KeyID .NTC (Nuvoton), INTC (Intel), AMD or STM (STMicroelectronics) are all just TPMS vendors. It depends on your hardware vendor which KeyId you will get.
When you have downloaded the file, extract and open the version.txt. Just simply search for the part after NTC-KeyId-.
As shown above, it’s in the version.txt file.. so we can be sure the url is a valid one because that url is very important… if it’s not in the file…. AIK enrollment will fail!
Another important note to add: When you have found the AIK URL, please check if that AIK Cert is NOT “removed” as shown below!
It looks like when Microsoft determines that somehow that AIK CA URL is used to deliver AIK certificates for vulnerable firmware versions, it will pull back that AIK URL even when it’s also used for not vulnerable firmware! In the example above, I guess Microsoft decided to shut down the AIK CA for that specific AMD fTPM .
When trying to re-enroll a previous working device with Autopilot for pre-provisioning deployments, you could run into this error: 0x800705b4 at the securing your hardware Phase when that AIK CA is withdrawn!
What did we learn from this nice error: Even when it worked before, it doesn’t guarantee that it works in the future!
So when we do have a valid (not vulnerable) and working TPM and we know that the AIK enrollment url is fine so let’s get some more TPM information.
Enter this nice command to get the required information: mdmdiagnosticstool -area TPM -cab c:\temp\tpm.cab
Normally you won’t get an error… but this time… you can guess what is going to happen
We are receiving 0x80190190 error HTTP_E_STATUS_BAD_REQUEST. Luckily it will still create the cab file within in the certreq_enrollaik.txt file. Please open that one and search for errors!
As shown above, we are prompted with the error: “Failed to parse SCEP request”. The error will tell us the Simple Certificate Enrollment Protocol request failed during the verification phase on the certificate registration point.
Normally when everything is fine, you will notice the PkiStatus: SCEPDispotionSuccess. Sounds way better than the error we got
In this file, you would again notice the AIK url but as we know by now the AIK url isn’t the issue… let’s continue
2.5 Determing if the EK cert is available
When you have read my other blogs, you will know that the EK certificate (EKCert)is very important, if we don’t have the possibility to fetch that one and its intermediate certificate we could have a problem.
When you want to be sure you have a working EKcert, the easiest ways to check out if you have a working EK cert are these 2 options
As shown above, we have got the requirements set up. No problems with the EKCert here!. After spending some time troubleshooting, I noticed on Twitter that a lot of people were suddenly experiencing TPM issues. So I decided to quit for today and start over tomorrow. And yes…!!! after a night of sleep, it was working!
Knowing how to troubleshoot can give you some insights into what’s happening or what could be wrong. I was expecting to see a Service warning in the Service Health and Message center…. but unfortunately, nothing was mentioned about this issue
Sometimes it’s the Intel 11th gen issue, sometimes it’s just the TPM not supporting attestation, sometimes the EKCert can’t be retrieved, and sometimes Microsoft withdrew an AIK ca, and sometimes it’s just the need for patience…