- Note some additions have been incorporated into the original posting due to excellent ensuing follow up questions and answers that have appeared in subsequent comments to this posting. The intention is that you have all the relevant information in this blog and aren't misinformed, in case you don't read through all the subsequent comments... the updated information appears towards the bottom of this posting under "new information(1) and "new information(2)"

 

I am writing this blog posting based on a recent vPro activation project with a customer, specifically in the context of Microsoft ConfigMgr, however the principles would apply to any vPro enabled Management Console. It will specifically address an issue which was encountered which relates to the signing algorithm used by the Certificate Authority (CA). This posting is NOTintended as a general purpose vPro and PKI posting but is meant for uncovering one specific issue and its subsequent fix.

 

Brief Introduction

A Microsoft Enterprise Certificate Authority is required (e.g. with Microsoft ConfigMgr) where a certificate template is created in order to issue Web Server based certificates to vPro systems as they get provisioned. These certificates will be used to authenticate and encrypt the AMT communications between the vPro client and the vPro enabled Management Console.

 

Up until now most of the Certificate Authority Installations have been performed on Domain Controllers with Windows Server 2003. Naturally, more and more of these installs will occur on Windows Server 2008. When setting up and configuring a CA that will issue certificates on Server 2008 you need to be aware that you need to configure your CA to use the SHA-1 algorithm and NOTSHA256 or SHA512 (aka SHA-2). The reason for that is that the AMT redirection libraries of the Intel AMT SDK only support the SHA-1 signing hash algorithm. This is also mentioned in the Microsoft Technet article - http://technet.microsoft.com/en-us/library/cc161874.aspx

 

How can you tell which signing algorithm you are currently set to use?

  1. Open MMC for your Certificate Authority and select issued certificates, select the certificate that has been issued to the vPro client you are investigating   (alternatively you can select the root CA cert). Open the certificate and view the signature algorithm field in the Detailstab - make sure it is set to sha1RSA

  2. 1.jpg

256.bmp

2. You can also open MMC for your Certificate Authority, righclick and select properties; in the general tab it will state which hash algorithm is used, for example like in the screenshot below:

CA SHA.jpg

 

What are the symptoms of the signing algorithm issue?

The identification of this issue might not be immediate as provisioning will complete successfully without any issues, WebUI access works without a problem, AMT operations through the ConfigMgr Console and the OOB Mgmt Console all work fine. In fact everything works fine apart from SOL and IDER through the OOB Console. This would generally be indicative of either a PKI or Kerberos related issue or both; however the matter here is more subtle.The certificate with which there is an issue, is the Web Server Duplicate based certificate that was signed by the CA using the SHA-2 algorithm. There will be no apparent errors indicating there is an issue, as there is nothing wrong per-se with the certificate. Although, traversing through the OOBConsol.log file (note this is different to the usual log file that is used for vPro troubleshooting - AMTOPMGR.LOG ) will reflect that the certificate being presented by the vPro client is being rejected.

 

Explanation

The issue isn't manifested immediately since it is only when attempting an SOL connection that the certificate that is based on the unsupported hash algorithm is called upon.The AMT redirection libraries that are part of the Intel AMT SDK and are used by the vPro enabled Management Consoles are restricted to SHA-1.

 

What is the solution?

You will need to change the signing algorithm to SHA-1. Normally that would entail building the CA from scratch; however with the CA based on Server 2008, there is a possibility to change this on the fly.

  1. On the Server where you have your CA installed, open a command line prompt and type: certutil -setreg ca\csp\CNGHashAlgorithm SHA1

  2. This will update the MMC CA immediately, but to ensure the CA uses this new algorithm when it issues certificates, you must restart Certificate Services.

  3. Issue a certificate from the root, and verify that the signature uses SHA1 in the details tab / signing algorithm field on the certificate.

  4. Take a vPro machine that hasn't been provisioned before (alternatively unprovision and clear out any traces/residual data on that provisioned system from AD, CA and Management Console/DB) and ensure that as part of the provisioning process a certificate is issued to that vPro machine with a SHA1 signing algorithm.

  5. Attempt to use the SOL function via the OOB Mgmt Console.

 

As a reference, please revert to:http://74.125.155.132/search?q=cache:4A4orLtypUYJ:download.microsoft.com/download/4/7/f/47f81ee5-8593-4b39-871d-2f55eb731ad6/Certificate%2520Services%2520Enhancements%2520in%2520Longhorn%2520Server.doc+SHA-2+algorithm+sub-id+0x800&cd=8&hl=en&ct=clnk&gl=uk

 

- Caution: It should be noted that it might not be able to avoid having to rebuiled the CA, as there might be residual data in the environment and certificate stores that reflects the previous SHA-2 signing algorithm. We have been able to avoid a full rebuild in our particular case.

 

- New Information (1): The IMRSDK.DLL, which is the DLL file necessary for the redirection library being used for SOL funtionality, has been updated to include support for SHA-2. The IMRSDK.DLL file is part of the new AMT 6 SDK however it has also been incorporated into the AMT 5.1 SDK. When you would have installed your Managment Console, it will have had the IMRSDK.DLL file which only supports SHA-1 incorporated into it. Therefore, what you can do to incorporate support for SHA-2, where it has been previously not available, is to copy this new version of the DLL over to where the existing IMRSDK.DLL resides on your management console (you can append to the file extension of the existing/old one '.old', just in case you need to revert back, so don't delete it completely). In Microsoft ConfigMgr for example you can find this in C:\Program Files\Microsoft Configuration Manager\AdminUI\bin\i386. This is not an officially sanctioned and supported fix (i.e. you use this workaround at your own risk) however strictly technically speaking it will work. You can also seek advice from your chosen vPro enabled software vendor whether this would invalidate any support.

 

- New Information (2): There are 2 sides that require alignment for the SHA-2 support: the Management Console and the vPro client. As articulated in the original posting and ensuing thread, the solution for the Management Console is rather simple - substitute the IMRSDK.DLL file. That DLL that supports SHA-2 has been made available in the AMT 5.1 SDK and is also present of course in the AMT 6 SDK.

Note though that the SDK and the AMT Firmware are NOT the same thing. As far as the vPro client and its AMT Firmware, it also needs to be able to support SHA-2. The first iteration of AMT Firmware that supports SHA-2 is AMT 6. Therefore even AMT Firmware 5.1 doesn't support it (even though the SDK 5.1 does, but that is irrelevant). Therefore if you look at the solution in its entirety, the 1st time both server and client side will align to support SHA-2 is with AMT 6 based vPro clients. Any previous versions of AMT do not support SHA-2. Therefore the consequences of that are that if you have a mixed environment, you have to use the lowest common denominator, which will dictate using SHA-1. If you have a green-field AMT 6 and above vPro client estate, then you will be able to deploy using SHA-2.

Whilst it is technically hypothetically possible to backport SHA-2 support into AMT Firmware, just as other fixes have been introduced with interim firmware releases, this is a remote possibility at this point and would take a very long time to filter through the OEM that would need to release the firmware. When dealing with firmware as far back as AMT 2 some OEMs will be very reluctant to release anything, so arguably you as the end customer won't benefit from it even though Intel has done all that it can.

 

The official guidance at this point remains that you need to ensure your CA is set to use SHA-1 algorithm.

 

It would be good though to collect some evidence of regulations that are requiring use of SHA-2 and that could be used to see whether Intel can work on a better solution - but we need that information 1st of all to justify any significant effort - so please get in touch and articulate with as much details requirements / environments that require use of SHA-2.

 

 

Some additional pointers of what to pay attention to with PKI (this is NOT an exhaustive list, there are more):

  1. If you have more than 1 tier in your Enterprise CA (e.g. root and issuing CA) then you will need to have the root certificate but also (and this is where most issues occur) the intermediate certificate in the trusted root certificate storeof the system from which you are running your Management Console. Don't get confused with the chain of trust of the provisioning certificate; this pertains to the chain of trust of the Web Server duplicate template certificate that was issued to the vPro client as part of the provisioning process
  2. When creating a duplicate of the Web Server template, you might intuitively select Windows Server 2008, however you actually need to select Windows Server 2003. Below is a screen shot of the options when right clicking on the Web Server template and selecting duplicate. As mentioned, select Server 2003, as mentioned in the Microsoft Technet article - http://technet.microsoft.com/en-us/library/dd252737.aspx
  3. Previously, there was also a requirement that at no point throughout the entire chain of trust of the CA should there be a certificate with public keys larger than 2048-bits. This requirement is no longer as much of a hurdle, as many of the newer AMT Firmware versions support 4096-bit public keys. All you need to do in this case is to upgrade the AMT Firmware.

                             

                                                                                                                                                          

 

    1.  





Filter Blog

By author:
By date:
By tag: