Cannot contact provisioned intel AMT device at FQDN:

[david_t_Intel]

Hi,

I tried toconfig anAMT device with a pofile, whose network is set withUse TLS,TLSServer AuthentificationtoLocal Interface and TLS Mutual Authentifcication to Network Interface.

Though it was indicated as Provisioned on Console, but i could not connect to the AMT deviceneither by Commander nor by WebUI. When by WebUI method, i was given a popup to confirm the cerficate, but failed afterwards.On SCS console, the log said: "Cannot contact provisioned intel AMT device at FQDN: ...."

Here is part of my environment:

AMT : V 3.0

SCS: V 3.1

SCS environment was set up following the manual (Intel AMT SCS Installation and User Manual.pdf) from the SCS_3[1].1_Gold package.

So far, i doubted it might have something to do with CA, but Ifailed tofind any way to solve this issue after much work.

Any help/hint from your guys is very much appriciated.

Thanks in advance.

David

[Ajith_I_Intel]

Hi David,

Thanks for posting the question on the forum. First, I am assuming that you are trying to connect to AMT remotely from another machine. According to your profile parameters, you are using TLS mutual authentication for remote interface. This means that both sides of the connection need to identify themselves using certificates. This requires that on the machine where the connection is being inititated, the root certificate and a client certificate is installed. Also AMT needs to be configured with a certificate for proving its identity during the TLS handshake operations.

We can try a small experiment here. Can you create a profle with no TLS first and after the AMT client is provisioned, try connecting to it using WebUI or commander. Once you are successful, you can try TLS with server authentication on remote interface and try connecting via WebUI. If you are successful in the last two modes, we can root cause the issue further.

Are you doing any Active Directory integration? Please let us know how things go and we will take it from there.

Thanks.

[david_t_Intel]

Hi Ajith,

Thanks for your reply.

I try the small experiments you talked about. Here are the results:

With Profilewith no TLS and WITHOUT AD integrated, the AMT CAN be connected;
With Profile with no TLS but WITH AD integrated, the AMT CANNOT be connected, via WebURL, I just cannot login with correct Password;

With profile with TLS, and TLS Server authentication to local interface and TLS Server authentication to Network interface, but WIHTOUT AD integrated, the AMT CAN be connected, but with warnings Connection name, DNS name, certificate name mismatch shown on commander.

With profile with TLS, and TLS Server authentication to local interface and TLS Server authentication to Network interface, and WITH AD integrated, the AMT CAN NOT be connected, on commander, it is shown as 192.168.1.3---intel amt with TLS or not configured.

With profile with TLS and TLS Server authentication to local interface and TLS Mutual authentication to Network interface, no matter if with AD integrated or not, the AMT device CANNOT be connected;

In all, AD makes difference in the first 4 trials, and Mutual authentication cannot work with or without AD integrated.

About AD, I installed it following the manual and also ran the BuildSchema.vbs after SCS installation.

About what you said Also AMT needs to be configured with a certificate for proving its identity during the TLS handshake operations., I do not know how to configure AMT with a certificate.Are there any specific steps to make it?

Thanks

David

[Ylian_S_Intel]

Hi,

I should record a tutorial video just on Mutual-authentication. Ok, for starters, I don't have much luck with Active Directory. The very latest version of Intel AMT Commander could be able to login using Kerberos. You have to leave the username and password blank to use local user credentials, or enter "" in the username field of Commander with a password to perform Kerberos (Commander will detect the and switch from Digest to Kerberos).

For a regular server-side TLS authentication, make sure that you connect to the computer using the same IP or name that is in the computer's certificate. So if the computer name is "bob.lab.com", make sure to use that name in a browser or Commander, don't use "bob" or the a.b.c.d, because it will not match the certificate name.

Mutual-auth is more complex. You need to give Commander a "Console" certificate. For Intel AMT to accept a connection in Mutual-auth, all of these conditions must be true:

• The console must have a certificate.
• Console certificate must have TLS client and AMT console key usage flags.
• Console certificate must not be expired (according to AMT's clock).
• Console certificate name must match a reverse DNS lookup of the console IP.
• Console certificate must be signed by a trusted root that is in AMT's root store.
• Console ceriticate must have an FQDN that match one in AMT's trusted FQDN list.

Anything here fails, and the connection is rejected. I suggest you try agent-side mutual-auth first. If you using the DTK, generate an Agent certificate with Director and load it up (with the private key) in the certificate manager of Intel AMT Outpost. Also note that if you don't use a passwork to log into Microsoft Windows, the certificate store will reject use of stored private keys and so, the connection will also fail.

Hope this helps,
Ylian (Intel AMT Blog)

[Ajith_I_Intel]

This does sound like an issue with the certificates. When you create a profile in SCS, depending on the mode of TLS authentication, you have to chose the certificate template that SCS needs to request from CA and provision it to AMT device. AD integration is another problem. I would first try to resolve without AD and then introduce AD once things begin to work. Please read Ylian's comments about TLS mutual authentication and ensure that you done all of the steps he has listed out.

[david_t_Intel]

Hi,

Thanks for reply.

Here are more details about the ways I did:

I used SCS Console to configure an AMT device, then used DTK Commander to connect it; besides, SCS Console is installed on the same 2003 Server with SCS, on which DNS, DHCP, AD are all installed for convenience.

Since the Console and SCS are installed on the same server whose CA are installed according to Intel AMT SCS Installation and User Manual.pdf, I am not sure if the Console certificate conditions are met automatically.

Thanks

David

[Ajith_I_Intel]

Hello David,

In order for mutual authentication to work, a certificate need to be installed to the console with the certificate name as FQDN of the machine from which you are connecting to AMT. Since TLS Server authentication works, AMT is configured correctly.

We need to configure the machine from which you are connecting to AMT. Your server machine should have two certificates installed on it. One is the root certificate, which is there because TLS server authentication worked. Another certificate that is needed is the one issued to the machine that can be used for mutual authentiation.

Please refer to the section - "Installing an Intel AMT Client Certificate for TLS Mutual Authentication" , page 35 in SCS Installation and User Manual.pdf document. You will have to create a new template (page 119 has instructons)based on the user certificate and will have to add a intel specific OID to the extended properties of that template. After the template is issued, you will need to request a certificate with the certificate name as FQDN of the machine name. Once you install this certificate, TLS mutual authentication should work. If you run into any issues, please send us the root certificate and the console certificate.

Hope this helps.

[david_t_Intel]

Hi,

A good news.After configuredby SCS, now AMT with Server-Auth or Mutual-auth is working with Commander, which means I can connect to AMT device by Commander and work on it . However, we still have some bad news. On SCS console, after provisioning, it still shows the error like: Cannot contact provisioned intel AMT device at FQDN:, and also, if click the webURL on commander like https://amt09.dns02.intel.com:16993, we cannot log into AMT, and it also does not work at using IP likehttps://192.168.1.2:16993.

Do you have any idea about it?

Note that AD is not integrated as you suggested.

Thanks

David