Expired CRLs and how they can derail your AMT configuration efforts

A while back I ran into an issue configuring an AMT system in TLS mode. I wanted to walk you through the issue and one potential solution in the event you are seeing similar issues with TLS.

I did a quick overview of my environment and everything appeared to be set up correctly. I was able to provision using a non-TLS profile in SCS, but when I switched to a TLS profile I kept getting this error on the vPro client while running ACUConfig.exe:

“Exit with code 75.

Details: Failed to complete remote configuration of this Intel(R) AMT device. Failed to get the certificate from the CA. (Certificate ID: 3310051103).  (0xc0002825). The certificate chain could not be built. Please make sure that the root certificate is installed properly. (0xc0003e93). Intel(R) AMT Operation failed. (Request Certificate). (0xc00007d5). The RCS failed to process the request.”

I checked out the SCS server and made sure the root Cert was installed correctly and everything looked normal. Then accessing the MMC cert snap-in on the SCS server, I created a test request to the CA for the AMT TLS cert and it issued it to me:






And as you can see, the OS had no issues with the certificate, but I was still seeing the errors on the vPro client while running ACUConfig.exe.

Taking a closer look at the acuconfig error message, it seemed like the SCS was having trouble building the certificate chain. So I decided to take a look at the CRL. After some digging around a bit, I decided to copy the CRL from the Cert Authority. To do this I just ran this command from a PowerShell prompt on the Certificate Authority:


Then I copied the crl.crl file over to the SCS server and installed it:


After I finally got the CRL installed on the SCS server, I restarted the SCS service and attempted the provision again. Sure enough, I was able to complete the process and the Cert Authority issued the TLS certificate for the AMT device.


There are quite a few different methods of publishing / referencing the CRL in your environment, for more information see this technet page: http://technet.microsoft.com/en-us/library/cc737760(v=ws.10).aspx

Instead of relying on the SCS error messages, you could also use a utility like certutil to check the validity of the CRL. Here is a blog post on TechNet on Basic CRL Checking with certutil: http://blogs.technet.com/b/pki/archive/2006/11/30/basic-crl-checking-with-certutil.aspx

Bill York also has some information related to expired CRLs and SCCM: http://communities.intel.com/thread/20138

If you suspect you are having issues with the CRL in your environment, this manual workaround will get you back up and running, but for a long term fix you should bring it up with your PKI team.