Intel vPro Expert Center Blog

How to procure and install a Verisign Cert for Remote Configuration on SCS

matthew.i.royer@intel.com — Wed, 19 Mar 2008 19:27:37 GMT

Here are some high level steps that walk you through procuring a VeriSign certificate and configuring it for the Intel Setup and Configuration Service (SCS). Other certificate vendors like Go Daddy, Starfield, Comdo, etc will have different purchasing processes.

Purchase Verisign Certificate

Generate Certificate Signing Request (CSR) by following the instruction in the link, http://www.verisign.com/support/ssl-certificates-support/page_dev019431.html.
The Common Name (CN) needs to be the FQDN of the server you want to install this certificate on. (i.e. host name + domain name)
Enter ‘Intel(R) Client Setup Certificate' for Organization Unit (OU).
Complete all the steps. Visit VeriSign website, [http://www.verisign.com/ssl/buy-ssl-certificates/] to start purchasing process. Select ‘Secure Site: SSL Certificates' under ‘Buy Individual SSL Certificates'.
Note: you could choose the other two, which are in more advanced level, depending on your need.
Enter all the information required and copy the CSR generated by the server
Complete all the steps and print out the order confirmation page for your record.
You will receive an email of Verisign automated order verification within few hours. You have only 24 hours, after receiving the email, to finish this process. Click the link in the email and go through the process.

*Important:* If you cannot recognize the second phone number listed on the webpage, cancel the automated verification process and have them call you instead.

Certificate Installation and Exporting

You will receive the link of installation instruction in the email containing the certificate. Follow the instruction to complete installation
VeriSign will send you the SSL certificate via email. If the certificate is an attachment (Cert.cer), save the file to the hard drive. If the certificate is in the body of the email, create a .cer file (example: NewCertificate.cer) by copying and pasting the certificate text into a plain text editor such as Notepad or Vi. Please be sure to include the header and footer as well as the surrounding dashes. Do not use Microsoft Word or other word processing programs that may add characters. Confirm that there are no extra lines or spaces in the file.
Open the Internet Services Manager (IIS). Click Start > All Programs > Administrative Tools > Internet Information Services (IIS) Manager.
Under Web Sites, right-click your web site and select Properties.
Click the Directory Security tab.
Under Secure Communications, click Server Certificate.
The Web Site Certificate Wizard will open, click Next.
Choose Process the Pending Request and Install the Certificate, then click Next.
Important: The pending request must match the response file. If you deleted the pending request in error you must generate a new CSR and replace this certificate.
Select the location of the certificate response file, and then click Next.
Read the summary screen to be sure that you are processing the correct certificate and then click Next.
You see a confirmation screen.
After you read this information, click Next.
Go back to IIS Manager (Start > Programs > Administrative Tasks > IIS Manager)
Expand Web Sites and right click Default Web Site
Under Secure Communications, click View Certificate...
select Detail tab
Click Copy to file at right bottom of window, the Certificate Export wizard will pop up. (N)
choose Yes, export the private key (N)
mark Include all certificates in the certification path if possible (N)
give a password (can be weak password) and confirm (N)
Give location and file name for the resulting PFX. (N), Finish, Ok.
Close all windows.

Adding Cert To SCS

Install the certificate created above in the System Certificate Store on the platform where the SCS executes. Follow the following steps:

Open certificates (local computer) using the Microsoft Management Console (MMC). To add the certificates plug-in to the MMC,
Select file/add snap-in.
Select Add....
Select Certificates.
Select computer account; click Next.
Select Local computer; click Next.
Select Finish; Close; select Certificates and click OK.
In the console tree, click the logical store where the mmc will import the certificate.
On the Action menu, point to All Tasks and then click Import to start the Certificate Import Wizard.
Type the path and file name of the certificate to be imported or click Browse and navigate to the file. Select automatically select the certificate store based on the type of certificate.

Invoke the loadcert utility

Located at <install_root>:\Program files\Intel\AMTConfServer\Tools.
Double-click on loadcert.exe
Select the certificate that was just imported. The utility will report any problems in the certificates that it detects that would prevent using it as a ZTC certificate.

Matt Royer

I’d Like to Tell YOU where to Stick that Certificate

gareth.j.bevan@intel.com — Fri, 05 Oct 2007 22:39:00 GMT

Well, it probably won’t work if you stick it there, but the

truth is that there are a lot of certificates used in AMT, and knowing where to

put those certificates and their private keys can save a lot of hair pulling

down the line.

<!--<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=ifgtevml+1">if gte vml 1>
id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t"

path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f">

]]>

<v:imagedata src="file:///C:\DOCUME_{1\gjbevan\LOCALS}1\Temp\msohtmlclip1\01\clip_image001.emz"

o:title=""/>

endif~~><!~~<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=if%21vml">if !vml</a>~~>!AMT Certs.jpg!<!~~<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=endif">endif</a>~~><!~~<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=ifgtemso9">if gte mso 9>

DrawAspect="Content" ObjectID="_1253102892">

endif-->]]>

AMT Certificates

Let’s start with the AMT system itself.

TLS Certificate

If the SCS profile calls for TLS to be enabled then a

private key and certificate are generated at the SCS and then installed on the

Amt device as part of the provisioning process. This certificate and key are

then used in future communications between the SCS and the AMT device and the

Management Console and the AMT device. I’m going to use the SMS Add-on as an

example of the management console because it uses gSOAP libraries which have

addition certificate storage requirements.

802.1x Certificate

If the SCS profile calls for and 802.1x certificate then a

private key and certificate are generated at the SCS and installed on the AMT

device as part of the provisioning process. This certificate and key are used

to allow the AMT device to connect to an 802.1x protected network without the

host operating system being available.

Mutual Authentication Root Certificate (MTLS Root)

The MTLS root certificate is used by the AMT device to

validate the mutual authentication certificate provided by the SCS or

management console after provisioning has completed. (Assuming of course that

the SCS profile used for provisioning configures MTLS). This certificate is

installed during the provisioning process. Note only the certificate is

installed – there is no private key installed for this certificate.

h1. Remote Configuration

The remaining two certificates on the AMT device are used

for Remote Configuration. This feature is available in AMT 2.2, 2.6 and 3.0.

(Note that does not include 2.5).

Remote Configuration Root Certificate (RCFG Root)

Actually this is not a whole certificate. It’s just the

certificate thumbnail, referred to as a hash. The certificate hashes can come

from a couple of places:

<!~~<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=if+%21supportLists">if !supportLists</a>~~>·

<!~~<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=endif">endif</a>~~>The AMT systems come with default certificate

hashes from VeriSign, GoDaddy and Comodo.

<!~~<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=if+%21supportLists">if !supportLists</a>~~>·

<!~~<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=endif">endif</a>~~>Your OEM can place a certificate hash of your

choosing on to the AMT devices you buy as part of their manufacturing process.

E.g. if you have your own PKI and wish to use your own root certificate.

<!~~<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=if+%21supportLists">if !supportLists</a>~~>·

<!~~<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=endif">endif</a>~~> You can

manually enter the certificate hash into the MEBx screen.

The advantages and disadvantages of each of these methods

are best left for another discussion.

This certificate is used to validate the remote

configuration certificate provided to the AMT device by the SCS service that is

trying to provision the AMT device. The details of this validation are somewhat

complicated and also best left to another discussion.

Remote Configuration Self Signed Certificate

Finally the remote

configuration processes requires the AMT device to generated its own self

signed (i.e. there is no certificate authority involved – and hence no trust

established) certificate to serve as a TLS/SSL certificate in place of the Pre

Shared Key (PSK) that was used to protect provision in earlier version of AMT.

Both the certificate and the key are generated locally on the AMT system.

SCS Certificates

Once we get to the server side, certificates become more

interesting as we have to know which Windows certificate store to put the

certificate and private key.

The SCS requires four certificates.

SSL Certificate

The SCS service runs as a web service within IIS.

Connections to the service can be carried out by the SCS console or by an ISV

supplied UI. To secure this traffic the SCS service requires that these web

services be protected by TLS/SSL. The SSL certificate is the same type used to

secure other web servers like amazon.com or eBay.

This certificate is installed in the Windows certificate

store of the service account used to run IIS. If you use the IIS “Server

Certificate” this is a two step process. First the IIS server generates the

private key and a certificate request. The private key is stored in the IIS

service account key store, and the request is stored in a text file. The

certificate request is then sent to the CA who issues the certificate. The

wizard then installs the certificate and matches it up with the private key.

<!--<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=ifgtevml+1">if gte vml 1>
type="#_x0000_t75" style='width:555pt;height:444pt' o:ole="">

]]>

<v:imagedata src="file:///C:\DOCUME_{1\gjbevan\LOCALS}1\Temp\msohtmlclip1\01\clip_image003.emz"

o:title=""/>

endif~~><!~~<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=if%21vml">if !vml</a>~~>!SCS Certs.jpg!<!~~<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=endif">endif</a>~~><!~~<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=ifgtemso9">if gte mso 9>

DrawAspect="Content" ObjectID="_1253102893">

endif-->]]>

TLS Root

The TLS root certificate is the root certificate from the

certificate chain that issued the TLS certificates to the AMT devices. This may

or may not be the same as your MTLS Root, depending on how you issue your

certs. This certificate is used to validate the TLS certificate provided by the

AMT device when the SCS connects to the device to perform some function after

initial provisioning. This could be re-provisioning or one of the maintenance

tasks that the SCS performs – like setting the AMT system time.

There is no private key associated with this certificate.

The certificate should be stored in the “Trusted Root Certification

Authorities” folder of the SCS service accounts certificate store.

Mutual TLS Authentication Certificate

This certificate is used by the SCS to authenticate itself

to the AMT devices. Both the certificate and the private key should be stored

in the SCS service accounts “Personal” certificate store. The root certificate

of the chain must be installed on the AMT device during provisioning to allow

this authentication mechanism to work correctly.

Remote Configuration Certificate

This is the most interesting of the three SCS service

certificates. This is because the certificate needs to be in two certificate

stores – but the private key only needs to be in one. The SCS service presents

this certificate to the AMT device to start remote provisioning. As this is a

mutually authenticated TLS session, the SCS service must have access to the

private key. So the certificate and private key should be installed in the SCS

service accounts certificate store.

To configure SCS for remote configuration, a utility called

“loadcert.exe” is run. This utility lists the certificates in the local

computer store and you select the one you want the SCS service to use for

remote configuration. The utility then make a registry entry containing the

thumbnail of the certificate. The SCS service looks at this registry entry and

then looks up the selected certificate in the SCS service account certificate

store. Because the loadcert.exe utility reads from the local computer store,

the remote configuration certificate needs to be installed in there. But,

because it is only read by the utility to extract the thumbnail, the private

key does not have to be installed in the local computer store.

SMS (Management Console) Certificates

Certificates for the SMS Add-on are complicated by the use

of the gSOAP libraries. GSOAP is a cross platform, open source web services

development toolkit. Because it is cross platform it does not (obviously) use

the windows certificate store. Instead it uses a file format called PEM (from

the Privacy Enhanced Mail system). PEM files store certificates and keys as

base-64 encoded strings. This makes them easy to manipulate (with things like

notepad) and portable between systems. The following discussion assumes a 3

level PKI hierarchy, with a root CA, policy CA and an issuing CA. If there is

sufficient interest I can talk about PKI hierarchies on a separate thread.

As the SMS is also a windows program, it also needs its

certificates in the windows store.

<!--<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=ifgtevml+1">if gte vml 1>
type="#_x0000_t75" style='width:566.25pt;height:407.25pt' o:ole="">

]]>

<v:imagedata src="file:///C:\DOCUME_{1\gjbevan\LOCALS}1\Temp\msohtmlclip1\01\clip_image005.emz"

o:title=""/>

endif~~><!~~<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=if%21vml">if !vml</a>~~>!SMS Certs.jpg!<!~~<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=endif">endif</a>~~><!~~<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=ifgtemso9">if gte mso 9>

DrawAspect="Content" ObjectID="_1253102894">

endif-->]]>

h2. Mutual Authentication Certificate (MTLS)

If the AMT profile the SCS calls for mutual TLS, then the

management console needs to supply an MTLSS certificate. This certificate, and

its private key, needs to be installed in SMS Add-on Service account

certificate store. This allows the SMS Add-on service to access the key for

operations such as power management. Because

the windows certificate store can “walk certificate chains”, only the MTLS cert

needs to be installed. Windows will work out where to get the rest of the chain

from on its own.

This is not true for the PEM file. In order for the gSOAP

library to have access to the certificate chain, all the chain entries must be

placed in the file (in the right order).

TLS Root Certificate

When a connection to the AMT device is made, it presents its

TLS certificate. In order for the Management console to trust the certificate,

the root certificate the issued the AMT certificate must be installed in the

“Trusted Root Certification Authorities” folder in the SMS Add-on’s certificate

store. . Because the windows certificate

store can “walk certificate chains”, only the TLS root cert needs to be installed.

Again, this is not true for the PEM file. In order for the

gSOAP library to have access to the certificate chain, all the chain entries

must be placed in the file (in the right order).