Intel vPro Expert Center Blog

4 Posts tagged with the certificates tag
1

Get Going with GoDaddy

Posted by sftaylor Sep 30, 2008

Going with GoDaddy


GoDaddy is one of the more popular sources for SSL certificates that support remote configuration. But GoDaddy doesn't take security lightly and will do a good bit of homework to validate that you are authorizated to recieve a Deluxe High-Assurance certificate on behalf of your organization. In order to make your purchasing process smooth and successful, here are some tips.

Bill York wrote an excellent blog on how to order such a certificate from GoDaddy that can be found at: http://communities.intel.com/openport/blogs/proexpert/2008/03/03/steps-to-purchase-a-godaddy-certificate-for-the-purpose-of-vpro-remote-configuration. Start by reading this article to familiarize yourself with the technical steps to complete the order. There are some tips below for setting up a new account that you may want to refer to as you start to follow his steps.

GoDaddy performs a good deal of "due diligence" research before they will issue a Deluxe High-Assurance SSL certificate. You can help to ensure the ordering process goes smoothly by anticipating the GoDaddy requirements to facilitate their research.

The "checks" that GoDaddy needs to perform are: domain authorization, corporate document approval, and online and verbal phone verification. You can see the on-going status of these steps when you log into your GoDaddy account after placing your order. As each step is completed, the icon next to that step will change in the Certification Steps Status page, shown below:

http://communities.intel.com/openport/servlet/JiveServlet/downloadImage/38-11589-1904/GoDaddy+Cert+Status+Steps.JPG

Account Setup

But prior to even ordering your SSL certificate, if you have to create a new account, be sure to use your company's formal legal name. GoDaddy will attempt to look up the company in a database, such as your state's list of registered companies maintained by the Secretary of State to see if your company is established. If not found, you may need to supply a letter of authorization from the company on letterhead for "Corporate Documents Approval" (see below).

Also be careful with your company address and phone number. GoDaddy will lookup your company in a online phone directory for the "Corporate Phone Number Found" step. If your business and location are listed with a phone number where you can be reached, you are in good shape since they are going to want to call a published phone number and be transferred to your extension.

If you are in a remote office that is not listed in a directory, be prepared to supply a phone bill in your name where you can be reached instead. Your mobile or home phone may be used if you cannot get a transferred call from an office that resolves to your business in a db like Yellowpages.com or Yellowbook.com. If you know that your address and office number will not be found in an online directory, have a copy of a phone bill (mobile or home) on an account in your name available to fax to them.

When ordering your Deluxe High-Assurance SSL certificate, be sure to follow the instructions from the articles shown above to generate the CSR and specify the appropriate OU to equal "Intel(R) Client Setup Certificate". Once the order is placed, you can start to monitor the status of your order.

Administrative Approval

As soon as you place the order, check the WHOIS lookup for your domain by using the link on the form or another method. Then, call or email your internal administrative contact for the domain to let them know to expect an email from GoDaddy requesting authorization for the certificate. Ask that person in your organization to let you know when they've replied and log back in to check the status after they do. The first three steps, "CSR Being Generated", "WHOIS Lookup Being Performed", and "Awaiting Administrative Approval," should be completed at this point. If not, you may want to call GoDaddy Technical Support to let them know of your progress.

Corporate Document Approval

At that time while you have GoDaddy on the phone, inquire as to whether they can find your company in the Sec. of State database and if not, verify what will substitute for Corporate Document Approval. In some cases, be prepared to submit Articles of Incorporation or copies of a SEC filing at this stage if necessary.

In other cases, you will need to fax a letter that includes the date and CommonName for the certificate signed by the department manager that authorizes you getting the certificate. This manager's position or title will need to be verified through either an on-line directory on your company's web site or by calling your HR department or contact. If you know that person's position or title cannot be verified on-line by GoDaddy, include the phone number for HR in the letter.

Corporate Phone Number Found

At this point, GoDaddy may need to forward your corporate documents to an administrative researcher within GoDaddy and there may be a delay for the documents to be verified. After this is done, and your "Corporate Document Approval" step status changes from In Progress to Completed, you may want to call Technical Support to help them find the best phone number to reach you at in an online directory. If this doesn't work for your phone number, ask for the Request for Verification form that you can complete and fax with the phone bill described above.

Once they have found the right number to call or received your phone bill and Request for Verification form, all that is left is to wait for the call. Verbally verify your identity and soon the certificate will be issued. In some cases, GoDaddy has sent an additional certificate with a P7X file extension, along with instructions on how to install it. I've not seen a case where the installation of this was necessary, and it may only serve to confuse you. You should only need to install the SSL cert for your domain in accordance with the documentation for your management console or provisioning server such as Intel's Setup and Configuration Service (SCS).

Remember, your certificate needs to have a CN matching the domain suffix of the machine where it will be installed and an OU matching "Intel(R) Client Setup Certificate" in the details of the Subject field. Also, the cert will need to "chain up" to the GoDaddy trusted root cert with a thumbprint matching one of the pre-installed trusted root CA thumbprints in the AMT firmware. For more information about certificate format requirements, installation of this cert, and other PKI-related questions regarding remote configuration, as alway,s a good place to look online is here at the vPro Expert Center.

Best of luck in getting going with GoDaddy!

1 Comments Permalink
1

I've been getting quite a few questions recenly regarding provisioning. Many folks are confused when it comes to what type of provisioning works with which versions of AMT and I'm hoping that this post will help to clear up some of that confusion.

Currently, there are two types of provisioning, PKI (Protected Key Infrastructure) and PSK (Pre Shared Key). For those who are not familiar with what is involved with these two types of provisioning, PKI involves using a formatted provisioning certificate in order to establish a trust relationship between the AMT client and provisioning server where PSK uses a PID/PPS key pair to establish the trust for provisioning. There is quite a bit of documentation regarding how to setup PKI and PSK provisioning in the deployment documents for AMT, so I won't go into that detail here. What I'd like to cover here is what are the differences between these types of provisioning and which versions of AMT use which types of provisioning.


First, lets cover the different types of provisioning and a brief overview how each of them work.

PSK provisioning uses a Pre Shared Key to encrypt the provisioning process. In order for an AMT client to use a Pre Shared Key, however, the MEBx must first be programed with the correct key. This can be done in either one of two ways, manual entry or via a setup.bin file located on a USB thumb drive.

Manual entry is just that, a user must access the MEBx and manually type in the characters for the PID and PPS and any other settings that are required in order to get provisioning to work (system name, password change, etc). Once the user saves the changes to the MEBx, AMT starts sending out 'hello' packets to the provisioning server to start the provisioning process. This method is the most straight forward but is also the most time consuming, especially when attempting to deploy many systems at the same time.

USB thumb drive provisioning shortens the PSK entry process by using a formatted setup.bin file located on a USB thumb drive that can hold many PID/PPS pairs as well as password change information for MEBx. This key is then used on each system as it boots up to load the PSK information into MEBx. When the system boots, ME detects that a setup.bin file is located on the USB key and, if AMT isn't provisioned already, will prompt the user if they would like to load the provisioning information from the USB key. If the user confirms the request, then ME loads the first available PID/PPS entry into the PSK settings as well as changes the password for MEBx to the password set in the file. ME then marks that entry in the setup.bin file as used and reboots the system. Once rebooted, AMT starts sending out 'hello' packets using the PID/PPS pair. This method is better than manual entry, but only barely. This still requires a user to be at the system and to interact with the process.

PKI provisioning is split into two different types of provisioning as well, Bare Metal and Agent Based/Delayed provisioning.

Bare metal provisioning is where the factory settings in AMT are set at the OEM/System Integrator so that as soon as power and a network connection are applied to the system, then AMT will send out 'hello' packets and provisioning starts. If provisioning doesn't happen right away the provisioning period will continue for 24 hours, sending out 'hello' packets at a decreasing rate, after which AMT goes into delayed provisioning mode. This method of provisioning greatly improves the time savings from a deployment aspect by enabling many systems to be provisioned with minimal interaction from deployment personnel. This method works well when using a 3rd party trusted certificate that is natively supported in AMT (Verisign, GoDaddy, etc).

Agent based/delayed provisoining is where either the 24 hour provisioning period has expired without a successful provisioning transaction or, due to the AMT version, AMT requires an in-band agent or tool to start the PKI provisioning process. In order to start agent based/delayed provisioning the agent or tool sends a command down through the HECI driver in the host OS and tells AMT to start sending out 'hello' packets to the provisioning server. In addition, some basic configuration settings can also be sent to AMT in order to get it ready for provisioning (enable AMT, set PKI provisoining, etc). This method of provisioning tends to be the most reliable. Again this works best when using a 3rd party trusted certificate that is natively supported in AMT but in addition you gain the benefits of having an in-band agent that is able to assist the provisioning process by providing the provision server in-band information that helps keep the out of band aspects of AMT synced with the in-band host OS. Configured correctly, provisioning AMT with the assistance of an in-band agent can make the entire provisioning process hands free for deployment personnel.

Lastly, I want to touch on how each of these provisioning processes relates to the different AMT versions. Different versions of AMT support different types of provisioning. AMT 2.0, 2.1, 2.5 only support PSK provisioning. AMT 2.2 and 2.6 support PKI provisioning (as well as PSK) but only agent based PKI provisioning. AMT 3.0 and higher versions of AMT support bare metal PKI provisioning (as well as agent based/delayed PKI and PSK provisioning). A common utility used to accomplish agent based provisioning is the RCT (Remote Configuration Tool).

Provisioning is a very complex topic and what I've touched on here is really just the tip of the iceburg when it comes to understanding the intricacies involved. I hope I've provided more answers than questions, but if there is something you still don't understand, feel free to comment and I'll try to clear it up!

Thanks,
Matt Primrose

1 Comments Permalink
2


The following information contains the detailed steps used to order a Remote Configuration Client Certificate from GoDaddy. There are many methods that can be used, but this was tested and validated that the certificate worked for both SMS and SCCM SP1 to provide Remote Configuration Provisioning to vPro clients.

SUMMARY: You will be required to prove that you, or your company, own the rights to the domain for which you are applying for this certificate. In the following example, I first registered my lab domain before ordering my Remote Configuration Certificate. I also needed a Company representative to submit a letter of approval (Company Letterhead) to GoDaddy giving me authority to request this certificate. I also tested the certificate I received from GoDaddy did work with Remote Configuring AMT clients in SMS and SCCM SP1 environment.

Key items that are detailed in the steps below that were required to get my certificate:
○ Certificate type must be a Deluxe Assurance SSL certificate
○ Certificate request is for an Organization
○ OU = Intel(R) Client Setup Certificate
○ CN = ServerName.domain.com (this must be the FQDN of the Provisioning Server for Remote Configuration generating the CSR)
○ Organization = The legal name of your organization that can approve your certificate request
○ Required Documentation to be submitted (Driver's License, Bank Statement, and Approval Letter on Company Letterhead)

STEPS TO PURCHASE THE REMOTE CONFIGURATION CERTIFICATE
1. Go to GoDaddy Web site: www.godaddy.com
2. Select the SSL Certificate link: https://www.godaddy.com/gdshop/ssl/ssl.asp?ci=8979

http://communities.intel.com/openport/servlet/JiveServlet/downloadImage/1281/1.png

3. From the SSL Certificate page, choose the Deluxe SSL certificate and click ADD
a. select Single (your choice of 1, 2, or 3 years) for a single Domain environment
b. Unlimited Subdomains - wild cards are support for version of AMT 2.6 / 3.2 and higher
4. In the next screen, you will be prompted to customize your order. No additional items are necessary on this screen, select Continue
5. At the Checkout Now screen, you should see the Deluxe Assurance SSL certificate (other options may vary if you selected additional items to purchase)
http://communities.intel.com/openport/servlet/JiveServlet/downloadImage/1282/2.png

6. In the Billing information Window, make sure to include your valid company name. You will be required to have someone from your company submit an approval letter for this certificate request on company letterhead (more detailed steps to follow).
7. After you fill out your billing information, you will need to login to your account to configure the certificate you have just purchased.
8. After logging in to your account, select Manage SSL Certificates.
9. You will see you have an available credit in the Secure Certificates, Click Set up Certificate link and Click Activate Account
a. You may need to Login in to your account or Create a new Certificate account - this is different than your GoDaddy Account
http://communities.intel.com/openport/servlet/JiveServlet/downloadImage/1283/3.png

10. Select the Deluxe High-Assurance SSL Certificate and Click Request Certificate

http://communities.intel.com/openport/servlet/JiveServlet/downloadImage/1284/4.png

11. Select Corporate option in Step 1
Fill out Personal Information in Step 2, including your company name
Generate you CSR and paste text in the box provided in Step 3 (make sure to indicate the type of server used to produce CSR)
They provide a link in Step 3 on How to generate a CSR (follow these steps).

The CSR MUST include the following fields to be a valid vPro Remote Configuration Certificate and approved by GoDaddy:

  • OU = Intel(R) Client Setup Certificate
  • CN = ServerName.domain.com (this must be the FQDN of the Provisioning Server for Remote Configuration generating the CSR)
  • Organization = The legal name of your organization that can approve your certificate request

http://communities.intel.com/openport/servlet/JiveServlet/downloadImage/1285/5.png
12. After you paste your CSR information and click Submit, your request will be routed to GoDaddy and they will follow up via email for next steps.
13. You will be asked to send them two forms of Identification (Driver License and Bank Statement)
14. Additionally, you will be asked to have someone within your company provide an approval letter on company letterhead stating that you have the authority to request the SSL certificate for this server and domain.
15. After GoDaddy has validated the required documentation, they will send you an email stating that your SSL certificate is available.
16. You can now download your SSL certificate and apply it to your IIS Web Server on your requesting Provisioning Server.

2 Comments 0 References Permalink
1

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.

AMT Certs.jpg


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:

·{font:'Times New Roman'}
The AMT systems come with default certificate
hashes from VeriSign, GoDaddy and Comodo.


·{font:'Times New Roman'}
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.

{font:Symbol}·{font:'Times New Roman'}


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.

SCS Certs.jpg


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.

SMS Certs.jpg


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).


1 Comments Permalink