In recent months, some complex remote configuration situations have occurred. This article attempts to address recent changes to the Intel AMT firmware to support top-level domains, along with references and insights to the VeriSign G2 root hash change, UCC certificate usage, and more. The reader is expected to have a base understanding of Intel vPro technology, Intel AMT which is the management portion of the technology, and remote configuration.
When selecting a remote configuration certificate, the following resources may be of interest:
Yet if you are seeing errors in the provisioning logs that look similar to the following, than further investigation to the infrastructure, certificate, Intel AMT firmware, or how the certificate was placed are warranted
Sample errors:
- Cannot handle provisioning exception: (0xCFFF06AC) SOAP Failure (23): getFullCoreVersion: SSL error...
- This indicates the remote configuration authentication failed likely due to DHCP option 15 mismatch or top level domain situation
- Cannot handle provisioning exception: (0xCFFF06AC) SOAP Failure (23): Cannot get core version response...
- Similar to the previous error, this also indicates remote configuration authentication failed likely due to DHCP option 15 mismatch or top level domain situation
- Hash list does not contain root certificate hash. PKI provisioning failed
In the explanation above, a comment was made about "Third Level Domains". This is a recent addition to Intel AMT 4.1 or 5.1 and higher systems.
I reference this situation due to recent customer events and experiences. The firmware is available to support - yet some background information might help.
First - take a closer look at Figure 6 in the remote configuration selection utility - http://www.vproexpert.com/59JHE//RCFG-Cert-Util/docs/RemoteConfigurationCertificateSelection.pdf
If not readily available, the following image is similar with some additions and change of format. The addition is reference to TLDs for 4.1 and 5.1 platforms.
TLD refers to "Third Level Domains".
Some explanation is needed first on what "2nd level domain" refers to. Thus the following image, which shows that child domains of a single root can be provisioned by a single certificate. However - this model ONLY works with .COM or .NET situations.
This provided some flexibility for a variety of customers, and as long as the Intel AMT firmware supported - the model worked great.
The situation become more complex in some areas and easier in others. First - the number of certificates supported by a single instance of Intel SCS grew from 1 to 50. (If AMTconfig is version 3.x, than only one certificate per Intel SCS instance. If AMTconfig is version 5.x, than up to 50 certificates per Intel SCS instance). Keep in mind - The version of Intel SCS used is depended upon the version of Altiris - Altiris 6 is validated with Intel SCS 3.x, Altiris 7 is validated with SCS 5.x.
But the situation gets a bit complex when more is needed than just .net or .com at the end of the DNS suffix. What about country code specific DNS suffixes or an expansion to other top level domains?
If a customer has offices\operations in different countries, the DNS suffix and DHCP option 15 will likely vary throughout the infrastructure. As an example, see the following two scenarios below - they may look similar, yet the DNS context\naming is slightly different.
This is where TLDs (third level domains) will help out. The following image provides a chart indicating what is supported.
A final thought. In scenarios where multiple resource or peer domains exist, such as the example below were a single management environment traverses two distinct domains. In this scenario - a UCC or multiple provisioning certificates (1 per unique domain) is needed. Some decision will be needed on the breakeven point between multiple provisioning certificates versus a UCC certificate as compared to pricing by respective supported certificate authorities.
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