Home > Intel Communities > Open Port IT Community > Intel® vPro™ Expert Center > Blog > Tags > ca
Up to Blog Posts in Intel® vPro™ Expert Center

Intel vPro Expert Center Blog

2 Posts tagged with the ca tag
Trevor Sullivan

Hello,

 

This is my first contribution to the Intel vPro Expert center, and although I would not consider myself an expert on this product, I've still been graciously allowed to post here. Thanks Josh!

 

I'd like to start out by introducing myself. My name is Trevor Sullivan, and I am a desktop systems engineer at a large retail corporation. Over the past 8 months or so, I've been working quite a bit with several people from Intel and Microsoft to better understand the Intel vPro technology, and how it can benefit my company. Overall, I'm really impressed with the technology, and I am fortunate enough to be working with an environment that has a pretty decent install base of Intel vPro-enabled systems.

 

I'd like to take a few minutes to explain a few issues that we recently experienced with our production vPro implementation.

 

 

-

Provisioning Certificate Chain Invalid

 

We're using Intel vPro with Microsoft Configuration Manager 2007 SP1, and for a while, we had been running into issues that prevented us from provisioning a vPro device. It turns out that the reasoning behind this was related to our provisioning certificate. We requested a certificate from Verisign, and imported it into our central SCCM site server. We have several child primaries to our central SCCM primary site server, however, and we were using the same provisioning certificate on those systems (Intel confirmed that this was possible).

 

 

 

 

 

When I exported the certificate (using the Certificates MMC snap-in), with its private key, from my central SCCM site server, I did not choose the option to export the certificate chain with it. Importing the certificate, with its private key, went just fine on the other SCCM primaries, but provisioning just didn't work. After working with Bill York from Intel for several hours, it was finally determined that the Verisign Class 3 Intermediate Certificate Authority's public key certificate was expired in the Intermediate certificate store on the SCCM site server running the out-of-band (OOB) service point. I imported the updated Verisign Intermediate certificate into the server's Intermediate CA certificate store, which resolved the issue I was having.

 

 

 

 

 

If you are experiencing this specific problem, you should see something like the following in your amtopmgr.log on the SCCM site server running the OOB service point:

 

 

 

 

 

Try to use provisioning account to connect target machine vprosystem.subdomain.mydomain.com...

Server unexpectedly disconnected when TLS handshaking.

**** Error 0x382b948 returned by ApplyControlToken

 

 

 

 

Although this probably should have been obvious to me, I did not actually open the provisioning certificate on the server I had imported the certificate on, to verify that the certificate was valid. If I had done so, I would have seen a message stating that the certificate was invalid, and then I could have looked at the certificate chain tab to see that the Verisign Intermediate CA's certificate was not valid. After examining the certificate for the Intermediate CA, it was determined that it had expired, causing my provisoning certificate to become invalid.

 

 

 

-

Microsoft PKI -Auto-Approval of Pending Certificate Requests

 

 

After resolving the certificate issue, we started seeing another issue. This issue was related to our internal Microsoft PKI. The next symptom we saw was again in the amtopmgr.log file (+in case you haven't figured it out, this is probably the most useful AMT log in SCCM). Here are the messages we saw:

 

Send request to AMT proxy component to generate client certificate. (MachineId = 60752)

Successfully created instruction file for AMT proxy task: D:\SMS\inboxes\amtproxymgr.box

RETRY(1) - Validate client certificate for AMT device vprosystem.subdomain.mydomain.com being generated.

Wait 20 seconds to find client certificate for AMT device vprosystem.subdomain.mydomain.com being generated again...

AMT Provision Worker: Wakes up to process instruction files

AMT Provision Worker: Wait 20 seconds...

RETRY(2) - Validate client certificate for AMT device vprosystem.subdomain.mydomain.com being generated.

Wait 20 seconds to find client certificate for AMT device vprosystem.subdomain.mydomain.com being generated again...

AMT Provision Worker: Wakes up to process instruction files

AMT Provision Worker: Wait 20 seconds...

RETRY(3) - Validate client certificate for AMT device vprosystem.subdomain.mydomain.com being generated.

Wait 20 seconds to find client certificate for AMT device vprosystem.subdomain.mydomain.com being generated again...

AMT Provision Worker: Wakes up to process instruction files

AMT Provision Worker: Wait 20 seconds...

RETRY(4) - Validate client certificate for AMT device vprosystem.subdomain.mydomain.com being generated.

Wait 20 seconds to find client certificate for AMT device vprosystem.subdomain.mydomain.com being generated again...

AMT Provision Worker: Wakes up to process instruction files

AMT Provision Worker: Wait 20 seconds...

RETRY(5) - Validate client certificate for AMT device vprosystem.subdomain.mydomain.com being generated.

Error: Missed device certificate. To provision device with TLS server or Mutual authentication mode, device certficate is required. (MachineId = 60752)

Error: Can't finish provision on AMT device vprosystem.subdomain.mydomain.com with configuration code (0)!

>>>>>>>>>>>>>>>Provision task end<<<<<<<<<<<<<<<

 

 

 

 

What this is telling you, is that the OOB service point was unsuccessful with its attempt to generate and retrieve a web server certificate, for the vPro client, from your internal Microsoft CA (either root or subordinate, but in our case, a subordinate). Although we had duplicated and configured the web server certificate template on our CA, the certificate was not getting created as we expected. The issue, in this case, was that our CA was not configured to automatically approve pending certificate requests.

 

 

 

 

In order to resolve this issue, follow these steps:

 

 

 

 

1. Open the Certification Authority MMC snap-in and connect to your CA

2. Right-click the CA node, and select Properties

3. Select the "Policy Module" tab

4. Click the Properties button

5. Choose the lower radio button (It reads: "Follow the settings in the certificate template, if applicable. Otherwise, automatically issue the certificate.")

6. Click OK on all dialog boxes

7. Restart the CA service, to allow the setting to take effect

 

 

 

 

-

 

I have a few more issues I'd like to talk about, mostly related to DNS. I will post again with details.

 

 

 

 

Thanks for reading,

 

 

 

 

Trevor Sullivan

Systems Engineer

 

 

Permalink Tags: trevor, sullivan, sccm, configuration, manager, configmgr, microsoft, sms, 2007, sp1, sccm_sp1, vpro, amt, provision, oob, out-of-band, generate, client, certificate, ca, pki, webserver, template, web_server, error, failure, fail, applycontroltoken
Russ Pam
2

Welcome and Future Topics

 

This blog posting is being created to discuss/highlight the key areas you should be aware of when implementing and activating vPro and Centrino Pro Technology within your environment. To start we will focus on Infrastructure, Requirements and Dependencies, and The Setup and Configuration Server.

 

If you have any additional topics you would like to see that fall under implementation and activation, please let me know.

 

Infrastructure:

 

In general an enterprise looking to deploy Intel® Active Management Technology will require at a minimum three servers in addition to your existing management framework to take full advantage of these capabilities. It is also recommended that for a fully functional enterprise that these servers be redundant as appropriate for their service to provide for high availability. Most, if not all enterprises require the robustness of service that can only be attained via high availability configurations. The three additional servers are as follows:

 

    1. One to host the Microsoft Certificate Authority

    2. One to host the Intel® AMT Setup & Configuration Server (depending on your ISV of choice)

    3. One to host the Microsoft SQL® Server Database

 

If an enterprise already has a SQL Server database or database farm in place, it could possibly be utilized eliminating the need to standup a separate service. Similarly, if an enterprise has an existing PKI in place, it could possibly be utilized for the Intel® AMT deployment. However, in this case it is likely that a successful startup of a pilot within an enterprise would be bolstered by implementing the PKI in standalone mode and then migrating to the existing PKI.

 

Another option for the enterprise that has a fully supported virtualization environment is to place the Microsoft Certificate Authority and the Intel® AMT Setup & Configuration Server in within that environment. The caveat is that the environment must be supported just like standard physical server environment. Process and procedures should account for standard server support in the virtual environment. Note: Virtualization of the SQL Server database cluster is not recommended.

 

It is assumed that a fully functional Windows networking infrastructure is in place prior to the deployment of Intel® AMT management capabilities. These assumptions include the highly available configurations most common to enterprise deployments of Windows Active Directory, Domain Name Servers, DHCP servers, and your Manageability Software that was support for Intel® vPro Technology.

Windows Server 2003 Active Directory (AD)

Microsoft Active Directory is assumed to be part of the overall network infrastructure supporting the existing Windows network environment. This architecture requires AD as the authentication mechanism allowing the Intel® Setup & Configuration Server, vPro ISV enabled Software, and potential web clients to logon to Intel® AMT hosts. AD should inherently be designed in a high availability configuration as prescribed by the existing environment and geographic requirements as well as best practices for AD in general.

Domain Name Server (DNS)

A domain name server is used to supply the name to IP resolution for the Intel® AMT hosts as well as resolving the Setup & Configuration server IP address for provisioning purposes. The name and IP address of each Intel® AMT host will be automatically registered in the DNS by the DHCP server.

 

Each Intel® AMT host will try to resolve the static name "ProvisionServer" during the initial activation process. ProvisionServer will be manually registered in the DNS and assigned to the Setup & Configuration Server IP address.

 

DNS is expected to be integral to the existing Windows network infrastructure. DNS should inherently be designed in a high availability configuration as prescribed by the existing environment and geographic requirements as well as best practices for DNS in general.

 

Dynamic Host Configuration Protocol (DHCP) Server

DHCP services must be in place to properly register Intel® AMT hosts within the enterprise. The hosts require that the DHCP server register their fully qualified domain name (FQDN) with the DNS. If the Microsoft DHCP server is employed it should be configured to automatically register the hosts in the DNS. Standard DHCP option 81 should be used to accomplish the task of registering the Intel® AMT hosts in the DNS as the FQDN is required as part of the PKI certificate generated for the device. The DNS is queried by the configuration server or add-on to compare against the certificate received in order to properly accept the TLS encryption with the Intel® AMT host.

Microsoft Certificate Authority (CA)

At a minimum a stand-alone PKI certificate authority would need to be in place to enable encrypted and secure communication with the Intel® AMT hosts. The Microsoft certificate authority (CA) is required to properly interoperate with the Intel® Setup & Configuration Server. The CA is required to issue certificates to the Intel® AMT hosts, the Setup & Configuration Server, and in the case of Mutual Transport Layer Security (MTLS) the vPro enabled ISV software (that using the Intel SCS). These certificates allow for SSL encryption and Transport Layer Security (TLS) and MTLS.

A certificate can be purchased from an outside vendor such as Verisign®. This enables easier provisioning (Remote Configuration) of the Intel® AMT 3.0 hosts as the Verisign root certificate hash is already defined in the host. This will be covered in later when we focus on Intel® AMT 3.0 devices.

 

These servers may be considered for virtual hosting environments. It is a requirement that the virtual hosting environment be fully supported within the environment through standard operating procedures. It is expected that if these servers are virtually hosted they will receive equivalent operational support as if they were hosted in a physical environment.

2 Comments Permalink Tags: client_management, vpro, centrino_pro, infrastructure, dns, dhcp, ad, amt, ca

Popular Blog Posts