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 itself
First, let’s start with the issue that start 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 0x81039001 !
So no deployments for us today, let me explain how to start troubleshooting
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)
First, we need to check the AIK URL if it’s 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 the wrong one…. AIK enrollment will fail!
So we have a 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.4 Determing if the EK cert is available
When you have read my other blogs, you will know that the EK certificate 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
So as shown above, we have got the requirements set up. So no problems with the EkCert
Knowing how to troubleshoot can give you some insights about 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, but this time it was just the need for patience…