There are several ways to configure an Intel® vPro™ machine and the most popular among corporate companies is the Zero Touch configuration method, which is based on PKI. You must issue a certificate for a provisioning server in order to establish a trusted relationship between the provisioning server and the ME. VeriSign is one company that can provide a certificate for this.


Since the launch of Intel® vPro™ in 2006, VeriSign has made some changes to their products. Rather than issuing certificates from G1 and G3 roots in their Secure Site (Standard SSL) and Secure Site Pro (Premium SSL) SKUs, these products now issue certificates of different roots. Unfortunately, Intel ME is firmware and updating the list of root certificate authorities is not as easy as it is in an operating system. Updating this list in the Intel ME will instead require a firmware upgrade.


If you have different Intel® vPro™ generations in your environment, you are most likely looking for a solution that uses the least common denominator like we have displayed in this table:


Firmware version

VeriSign Hash


G1 and G3


G1, G2 and G3


G1 and G3


G1, G2 and G3


G1 and G3


G1, G2 and G3


G1 and G3


G1, G2 and G3


G1, G2, G3 and G5


G1, G2, G3 and G5


G1, G2, G3 and G5


G1, G2 and G3


G1, G2, G3 and G5


G1, G2, G3 and G5


As you can see, the latest version of each firmware generation is accompanied with a complete list of trusted roots.


However, a problem occurs if you have multiple versions of vPro but are only able to use one certificate for provisioning server (and cannot issue a certificate from G1 or G3 anymore). Fortunately, in order to avoid interoperability issues with legacy browsers, VeriSign makes a cross-signed of VeriSign Class 3 PPCA-G5 with Class 3 PPCA (G1.3). This is called Secure Site Pro, creating a cross certificate as shown in this diagram:




Usually, OpenSSL libraries use a PEM file format when building the trust chain in order to validate the certificate. We can statically define the trusted certificates that we would like to use in this chain. Microsoft has some wrapper code available to build the PEM list of certificates and, in this particular case, Windows has 3 possible root certificates to be used. All three are equally valid and Windows built the trusted chain using the shortest chain, i.e. VeriSign "G5" Class 3 PCA Root or VeriSign "G1.5" Class 3 PCA Root, both of which are not present in some old ME firmware. When you install the certificate, without any modification you see the root certificate VeriSign "G5" Class 3 PCA Root as shown here:





In order to force Windows to build the trusted chain up to VeriSign Class 3 Primary CA - G1, we have to eliminate VeriSign "G5" Class 3 PCA Root and VeriSign "G1.5" Class 3 PCA Root from the Root folder (or at least disable Client Authentication and Server Authentication from the purpose list of these certificates).




Without these two certificates, the only valid chain will be with VeriSign Class 3 Primary CA - G1. That chain is present in every ME firmware version, since the first version, i.e. 2.0 through 7.1 - See below:



Now you don’t have to be concerned about these VeriSign certificate issues with your Intel vPro versions, just follow the instructions presented in this document and have yourself a happy vPro configuration.

In summary - these are not compatible, as explained below.


Intel AMT Remote Configuration enables the authentication to the firmware for an initial Intel AMT configuration event.  Remote configuration for Admin Control Mode configuration of the Intel AMT firmware is typically done via a valid certificate for the environment.


More information on the remote configuration process is available at


The authentication process should complete without user interaction.   If the requesting application (i.e. Intel SCS) is prompted everytime when the private key is accessed, the autonomy is lost.


When importing the certificate to your target server, if the Strong Key Protection option is selected and grayed out this indicates a conflicting group policy for cryptography has been applied to the server.



If you miss the first prompt, another clear indication that the conflicting group policy is in affect is shown below.

CertImport-PrivateKeyProtect prompt.png

Changing the group policy setting of the server will remove this barrier.


In the example below, the incorrect or conflicting setting is shown.



Change the System Cryptography policy to the "User input is not required when new keys are stored and used"



Filter Blog

By date:
By tag: