Whether you are planning to implement a Vendor TLS Certificate in the future, or you are having trouble applying a certificate you've already obtained, this article walks through the best practices. The details include all the steps to properly install the right items and resolve issues we've encountered up until this point. This article applies to Out of Band Management Solution 6.2. Since certificates introduce tight encryption security, if the right items and steps are not in place or followed, it can break the ability of AMT systems to provision with Remote Configuration.
Introduction
Using Remote Configuration to Provision your Intel AMT vPro capable computers takes the work out of the progress. All 2.6, 3.0+ AMT systems come preconfigured to automatically use Remote Configuration to provision with a valid Provisioning Server. The hashes from vendors (AMT 3.0 includes Verisign, GoDaddy, Comodo) are already configured in the firmware, and upon connection to power and the network, will begin to send out requests for provisioning. Thus in this way the managed vPro systems are already prepared to be provisioned without any needed intervention by the IT staff.
The issues we see then arise from the server-side application of a certificate that matches the hashes already loaded. Obtaining and installing a vendor TLS Remote Configuration certificate needs to be done the right way so that authentication can succeed. Once in place, provisioning will roll forward without any further intervention. This article focuses on applying the server-side certificate so that provisioning can move forward automatically.
Obtaining a Remote Configuration Certificate
This subject has been covered previously. I wanted to lightly touch upon this as there is a vital step that should be taken so that if anything goes wrong we can correct it. First, the following article covers how to properly obtain a certificate:
Note that part of obtaining a Remote Configuration is submitting the request from the Server you plan to install the certificate onto. This process creates the private key for the server-side certificate, and this piece will not be available until partway through the application of the crt (or cer) file obtained from the vendor. The specific step that provides the full key, both private and public, is when the certificate is exported after the initial import into a PFX format, checking the option to export the private key will give you a complete backup of the full certificate. If something happens, or if the application didn't go right, we'll need both, so it's essential to export this as soon as possible.
During the steps to install the certificate emphasis will be given on the step where the export should take place.
Installing the Certificate
I've condensed the steps required into the following list. This process works for all vendors once you've obtained a certificate. Note that these steps are provided to consolidate both recommended steps and documentation into one whole.
Go to Start > Run > type mmc > and click OK.
In the resulting console click under File and choose Add/Remove Snap-in...
Near the bottom of the resulting window click the Add button.
From the list that appears select Certificates and then click the Add button.
Leave the radial button selected on ‘My user account' and click Finish.
From the same list select Certificates again and click the Add button.
From the resulting window change the radial select to ‘Computer account' and click Next.
Leave the selection at ‘Local computer: (the computer this console is running on) and click Finish.
Click the Close button in the window offering you the list of available snap-ins.
At the original add/remove snap-in screen verify that you have two entries:
Certificates - Current User
Certificates (Local Computer)
Click OK.
Expand both trees in the left-hand pane within the console. You should see the full certificate stores.
Right-click on the Personal folder under the Current User certificate store and highlight ‘All Tasks' and click on ‘Import' in the pop-out menu.
Click Next on the Welcome page of the Certificate Import Wizard and click the Browse button.
Browse to the cer or crt file provided by the vendor, highlight it, and click Open.
Click Next, and leave the radial option on ‘Place all certificates in the following store', which should be set to ‘Personal'. Click Next.
Under the Completing section of the wizard, Click Finish. You should receive a pop-up .
NOTE! This is the vital step mentioned previously in the article. We will now export the certificate with both public and private keys, which will give us the full set and allow us to remove and reapply if necessary. In the MMC select the newly imported certificate > right-click > and choose All Tasks > Export...
Click Next on the Welcome screen. In the resulting list you should have an active option for ‘Personal Information Exchange - PKCS #12 (.PFX)'. If this option is not available there is a problem with the certificate and the private key is not accessible.
Follow the wizard, and ensure you select the option ‘Yes, export the private key'. When saving the file, it will prompt you to set a password to protect the private key (this is recommended for security reasons). The export should leave you a PFX file. Keep this in a safe place, and back it up just in case.
Next we need to import the full key into the Computer store. Start back in the MMC, under the Local Computer certificate store, right-click on the Personal folder, select All Tasks > Import...
Click Next on the Welcome screen and click the Browse button on the subsequent screen.
Browse to the newly exported PFX file. Note that you will need to change the ‘Files of type' to include the PFX format. Click Next.
The Password screen prompts for the password you set when you exported the key in step #20. Enter the password and click Next.
Choose or leave the select to ‘Place all certificates in the following store'. The value should be Personal. Click Next.
Click Finish on the end details page to complete the import.
Next, we need to load the certificate into Intel SCS so it can properly authenticate with the AMT systems requesting Remote Configuration. Browse to the following location: \Program Files\Intel\AMTConfServer\Tools.
Execute the file loadcert.exe.
Press Y and Enter.
A ‘Select Certificate' popup will appear. Select the name of the cer or crt file you received from the vendor and click OK. The window will disappear.
Now both Personal certificate stores and Intel SCS should have all the needed certificates to successfully work with Remote Configuration. However, we are not done as other steps may be needed.
Reinstalling the Certificate
If you need to reinstall the certificate and have a PFX file, you can do so by opening both certificate stores (User and Local Computer) as outlined in the previous steps. Browse through the certificate stores and delete any instance of the vendor certificate. This will remove any associations and allow a clean application of the certificate to occur. Look for the following:
NOTE: Be careful when removing vendor certificates as they may not be part of the Remote Configuration. The best example is Verisign, which may have many entries. If unsure, leave the certificate in place, or export it before deleting it so you can restore it if necessary.
Other Setup Requirements
The following items may be required, depending on the environment.
ProvisionServer
Each zone within DNS should have a ProvisionServer entry to ensure that Remote Configuration requests are properly routed. This will also help properly resolve names during the authentication process. To test, log onto a system on the subnet you're trying to conduct Remote Configuration from. Run a command prompt and use the following command:
We should see the responding IP Address by the IP Address of the Notification Server, or, if you've set it up this way, the Intel SCS Server conducting provisioning. Another test you can try is to run the following command:
We should get the data on the Notification Server's name.
DNS Zones
In a multiple domain structure this is especially important, but all environments need to have the right data in DNS to properly pass and authenticate in a TLS environment. The DNS Primary Zone should be set to the Domain path contained within the certificate. For example, if the certificate name is MyNSServer_My1Domain_local, the DNS Primary Zone should be My1Domain.local. Without this, authentication can fail as the FQDN is used during authentication, and if the name being transmitted across the wire doesn't match what's in the certificate, authentication will fail. Here is another example:
DHCP Option
Another Network related requirement may be DHCP Option 15. While I'm not sure why this has proven to be required in some environments and not others, creating this option has resolved failed authentication issues within Remote Configuration.
In DNS, create an entry for Option 15, with the value of the domain path. This will often be the same as what is located in the DNS Primary Zone. The following details are an example:
Certificate: MyNSServer_My1Domain_local.crt
DNS Primary lookup Zone: My1Domain.local
DHCP Option 15: My1Domain.local
Conclusion
Following the above procedure should allow remote configuration to occur without problems. Once in place, the configuration will move forward with automatically provisioning systems that support Remote Configuration.
