In preparing to configure Intel AMT via Remote Configuration with a certificate issued by VeriSign, you may have noticed that the root certificate is a G5. The VeriSign G5 certificate hash is not present in all version of Intel AMT firmware. Successful configuration may be intermittent.
The good news - the issued certificate can be rechained to a compliant VeriSign certificate root where the hash\thumbprint exists commonly in the Intel AMT firmware. The VeriSign support site provides brief guidance on what is needed - see https://knowledge.verisign.com/support/mpki-for-ssl-support/index?page=content&id=SO10703&actp=AGENT_REFERAL
This article will provide a few additional insights to rechain from a VeriSign G5 to a lower root certificate compliant with all generations of Intel AMT.
Background Information
A few points that will help and a big THANK YOU to VeriSign support contacts that augmented my understanding:
- For a list of supported root certificate hashes across Intel AMT firmware generations, click here
- If unsure exactly what Intel AMT firmware versions exist within your environment today, click here.
- To determine exactly where certificate hashes are in the Intel AMT firmware - the actual 40 characters - see part 2 of the previously shared link
- VeriSign issued certificates are commonly cross signed for G5 (2048 encryption) or G3 (1024 encryption)
- The issued certificate delivered as part of the Certificate Signing Request (CSR) will use the shortest path to a valid root (more on this later)
- If valid root and intermediate certificates are not already present on the server, the server may attempt to download from the internet.
- The issued certificate in this scenario is signed by VeriSign Class 3 Extended Validation SSL SGC CA (thumbprint 2c 48 dd 93 0d f5 59 8e f9 3c 99 54 7a 60 ed 43) - this is the secondary intermediate certificate
- The secondary intermediate certificate is issued by the cross signing certificate VeriSign Class 3 Public Primary Certification Authority - G5 (thumbprint 25 0c e8 e0 30 61 2e 9f 2b 89 f7 05 4d 7c f8 fd). NOTE: This is NOT the root certificate, but is building a chain of trust to several 1024 bit VeriSign self-signed root certificates issued to Class3 Public Primary Certification Authority. There are roots with MD5 hashing algorithms as well as sha 1 hashed roots.
The goal is to re-chain the issued certificate to a lowest common denominator. The process below provides steps for re-chaining to a VeriSign G3. However, as will be noted in the first link shared above, even some versions of Intel AMT do not support the VeriSign G3. In general, those are older and outdated versions. Updating to the most current version as provided by the OEM of the platform is recommended.
Process to Re-Chain a VeriSign Issued Certificate
As a starting point, here is a screenshot of a sample certificate. The screenshot shows the root certificate hash, which is a VeriSign G5 (more on how to determine this in a moment)
To ensure the VeriSign G3 root certificate is installed on the server, go to http://www.verisign.com/support/roots.html.
Search for the string 5cc6 - the last four hexadecimal characters of the VeriSign G3 root certificate. Shown below is a screenshot of the website, showing specifically the VeriSign G3 certificate. Download and save this to a .cer file (for this article, the saved file is "PCA-3G3.cer")
Next, download the cross-signed intermediate certificates needed for the re-chaining to complete correctly. These are available at http://www.verisign.com/support/verisign-intermediate-ca/extended-validation-pro/index.html. Save the individual certificates to text files as explained in at the link
You now have two additional certificate files as shown below
Next, import the VeriSign G3 certificate into your root certificate store. In the example below, the User Certificate store is shown. The G5 root certificate is already present.
Open the properties of the VeriSign G5 certificate - the one which we want to break from the certificate chain. Either right click on the certificate and select properties, or open the certificate, select the Detail tab, and click properties.
Unselect the Server and Client Authentication Purposes as shown below. The issued certificate will then be forced to look for a different root certificate for these purposes... and Intel AMT Remote Configuration requires Server and Client authentication of the certificate 
Import the two intermediate certificate files that were previously downloaded. The issued certificate will be cross-signed to the secondary intermediate, which will be signed\associate to the primary, which can then link to a valid 1024bit certificate... such as the VeriSign G3.
To ensure the intermediate certificates are chaining to the desired VeriSign G3 root, open the secondary intermediate. In the example above - this certificate ends with "SSL SGC CA". Select the Certification Path tab, and a screen similar to the following will appear.
If you're screen doesn't show the correct or expected chaining, go back and disable\remove errant intermediate and root certificates as needed. For example, in a prior screenshot is shown what appears to be two secondary intermediate certificates ending with "SSL SGC CA". The unselected copy could be deleted if needed.
Import the issued or leaf certificate, and recheck to ensure a correct re-chaining has occurred. In the example below, the "Default Web Site" certificate is now correctly chained to the VeriSign G3 root.
Concluding Thoughts
Remember the previous statement of "use the shortest path to root"? Notice that the re-chained certificate must include two intermediate certificates, whereas the first certificate chain has only one intermediate. The process above has forced a re-chaining to a lower security root certificate, in this case a VeriSign G3.
The above process could be repeated to re-chain to a valid VeriSign G1.5, and even a valid VeriSign G1. In the case of the latter, the root certificate does not need to be downloaded. By disabling all other valid root certificates, the VeriSign G1 will appear (at least, that was my experience. Perhaps someone at VeriSign can provide a better explanation why that happens)
The above process was tested both in a lab and production environment with a variety of Intel AMT versions, from 3.x to 7.x. Once the re-chained certificate was in place, all systems configured on the first attempt.
Interested to hear how your experience with Intel AMT remote configuration is working out
The opinions expressed on this site are mine alone and do not necessarily reflect the opinions or strategies of Intel Corporation or its worldwide subsidiaries