TLS connection error when using Intel Manageability Commander

[ICIT]

I have a Dell Precision 3460 with AMT 16.1. This version now requires the use of TLS. When I attempt to connect to this device using Intel Manageability Commander, an error message is displayed stating "imcException - A TLS connection could not be established".

MeshCommander however connects with no problem. Likewise, I can connect via web browser via HTTPS on port 16993.

Manageability Commander is the latest version (2.4) installed using the IMCInstaller-2.4.0.msi, although the interface reports that it's 2.3. I suspect this is just a developer oversight.

See attached screenshot of AMT embedded certificate as reported by MeshCommander. No obvious issues there.

Any ideas why IMC won't connect?

[MIGUEL_C_Intel]

Hello, ICIT,

I hope this email finds you well.

The engineering validated the following answers.

a- Intel® Manageability Commander (IMC) does not support CIRA mode.

b- The endpoints were provisioned by Mesh Commander with CIRA; it is necessary to change the profile to TLS relay.

c- Finally, the client machines can be accessed with IMC, since the Mesh Root Certificate was imported into the client's trusted root store.

Regards,

Miguel C.

Intel Customer Support Technician

[Jools86]

Thanks for confirming A Miguel.

B&C does not work.

If we provision a machine via TLS Relay, only MeshCommander works. IMC always throws up an error.

See this tkt for further information and a screenshot of it not working with Meshroot imported

TLS Relay Provisioned machines - Configuring IMC / MeshCommander to talk to them - Intel Community

[ICIT]

Thanks for the follow up however the response from engineering seems disconnected to the problem I described. In this case everything is manually set up, there is no CIRA mode in play, there's no EMA server, there's no MeshCentral server, all AMT endpoint settings were provisioned via MEBx.

I just simply want to connect to an AMT device via TLS using IMC. This is extremely easy to do with MeshCommander, and seeming very difficult with IMC. 

To address your bullet list specifically...

A - CIRA mode is not in use

B - The endpoint was not provisioned by Mesh Commander, it was provisioned using MEBx

C - Yes, the client machine should be accessible by IMC but IMC is throwing an error

In addition, see my post from yesterday explaining how I went through the process of adding a certificate again using PowerShell and OpenSSL and got the same result.

[MIGUEL_C_Intel]

Hello, Jools86 and ICIT,

Thank you for your findings.

Please give us some time to work on your issue. I will update you next week.

Regards,

Miguel C.

Intel Customer Support Technician

[MIGUEL_C_Intel]

Hello, Jools86 and ICIT,

Thank you for your patience while the engineering team reviews the issue.

Intel introduced security updates to Intel® AMT, and only pre-validated OEM Certificates with SHA256 are supported.  Their hash is pre-installed into the BIOS firmware of vPRO-capable machines.  Self-Certificates are not supported anymore.

Vendor Certificates to Support Intel® AMT, go to the bottom of the page.

https://www.intel.com/content/www/us/en/architecture-and-technology/vpro/active-management-technology/implementation.html

Regards,

Miguel C.

Intel Customer Support Technician

[ICIT]

Miguel,

You keep referring to provisioning certificates - certificates required on the server side during the remote provisioning process. The issue I've detailed here is not with provisioning of an AMT device, it's about trying to connect to it once it is provisioned. 

[MIGUEL_C_Intel]

Hello, ICIT,

I understand the provisioning of the machine was completed.  The limitation is related to how the endpoint validates EMC and how EMC validates the endpoint connection.  This process requires a pre-validated Certificate (SHA256 – TLS).

Regards,

Miguel C.

Intel Customer Support Technician

[ICIT]

The limitation is related to how the endpoint validates EMC and how EMC validates the endpoint connection.  This process requires a pre-validated Certificate (SHA256 – TLS).

---

By EMC do you mean IMC?

I don't believe this is accurate. If true this is not mentioned in any documentation. Are you saying that every AMT endpoint has to have a special AMT TLS certificated issued from a public CA in order for IMC to connect using TLS?

[MIGUEL_C_Intel]

Hello, ICIT,

You are right, I was referring to IMC - Intel® Manageability Commander.

The latest version of IMC and according to AMT requirements, only dedicated (authorized AMT certificates) are valid.  Intel will clarify at IMC software documentation the Certificate specifications.

Vendor Certificates to Support Intel® AMT, go to the bottom of the page.

https://www.intel.com/content/www/us/en/architecture-and-technology/vpro/active-management-technology/implementation.html

Regards,

Miguel C.

Intel Customer Support Technician

[ICIT]

I still feel like that can't be true. So if I have 100 AMT endpoints, I need to purchase 100 authorized AMT certificates from an authorized public CA in order to connect via TLS using IMC?

[MIGUEL_C_Intel]

Hello, ICIT,

It is necessary 1 Certificate per Intel® EMA instance, no matter the number of endpoints.

Regards,

Miguel C.

Intel Customer Support Technician

[ICIT]

Miguel, I don't think we're on the same page here. I realize that an authorized AMT certificate from an authorized public CA is required for EMA and the provisioning process, but that's not the issue here.

To further illustrate, this document states the following:

An Introduction To Intel® AMT Remote Configuration Certificate Selection

Keep in mind that the remote configuration certificate is only used for the initial provisioning of an Intel AMT client that is provisioned using remote configuration. The remote configuration certificate is separate from the certificates needed for secure communications such as the certificates for TLS, Mutual TLS, 802.1x, or the SSL certificate for web services.

The issue I'm describing has nothing to do with EMA and is not related to provisioning. As mentioned previously, I want to use IMC to connect to a manually configured AMT device. That requires a certificate to be installed on the AMT device. This certificate does NOT need to be an authorized AMT certificate from an authorized public CA.

Per all available documentation, I have it set up so that it should be working but it is not working. Does engineering have anything more to say on this?

[MIGUEL_C_Intel]

Hello, ICIT,

Yesterday, I mentioned Intel® EMA because it is the latest software released by Intel.  The communication is validated in the same way and requires the authorized Certificate.

The summary of the validation is available in section 6, called Certificate Checking of the Intel® Manageability Commander (Intel® MC) User Guide v2.3

https://downloadmirror.intel.com/27807/Intel%20Manageability%20Commander%20User%20Guide.pdf#page=17

Intel® MC automatically verifies that certificates, used in TLS, chain down to a root in the Windows Computer Account Trusted Root certificate store of the machine from which it is run. Additionally, the Intel® MC will verify that the DNS name or Subject Name in the certificate matches the hostname of the Intel® AMT device.  Just like in web browsers, the machine will automatically connect and display a lock indicating that the connection is secured via TLS.  If the certificate cannot chain to a root in the certificate store, then Intel® MC will reject the connection and display an appropriate error message.

Regards,

Miguel C.

Intel Customer Support Technician

[ICIT]

I posted that same paragraph from the IMC user manual back on 7/17 in this thread. Nowhere does it say that an authorized AMT certificate is needed. What it does say is

Intel® MC automatically verifies that certificates, used in TLS, chain down to a root in the Windows Computer Account Trusted Root certificate store of the machine from which it is run.

In other words when IMC connects to an AMT device, the certificate installed on the AMT device is sent to IMC. IMC, running on a Windows machine, then checks the trusted root certificate store on the Windows machine it is running on to ensure that the root certificate that issued the AMT certificate, along with any necessary intermediate root certificates, are in fact installed into the trusted root certificate store.

This process does not require the certificate installed on the AMT device to be the same type of special provisioning certificate issued from an AMT authorized public CA.

Is there anyone on this forum that has successfully connected to an AMT device with IMC using TLS? I know there's another recent thread on here from @Jools86 describing the same problem I'm having here. 

[Eduardo_B_Intel]

Hello ICIT,

I wish you an excellent Friday and upcoming weekend, Sir.

If you review the latest release date of IMC (late last year) and the release AMT 16 platforms (currently the latest and greatest) it looks like a new release of IMC may be overdue to comprehend some of the newer security requirements. Using Mesh is a great and available alternative for AMT 16 and newer systems for a user-friendly TLS connection. IMC should still works fine on AMT 15 localhost interfaces not using TLS, but when trying to do remote communications to AMT 16 or newer Mesh makes a great user-friendly alternative that works well with TLS.  It is important to highlight the availability of an alternative that makes this achievable.

Warm regards,

Eduardo B

Intel Customer Support.

[ICIT]

Hi Eduardo,

True, MeshCommander doesn't have these TLS connection problems, and frankly is just an overall better solution. I'm familiar with it and have referenced it earlier in this thread. One big potential problem with MeshCommander though is that it is open source software and the two primary contributors, both Intel employees, were laid off from Intel in November. 

Ylianst/MeshCentral · Discussions · GitHub

While the open source community may continue development, the level of commitment that Ylian had, along with the level of insider knowledge of being an Intel employee and interfacing directly with the hardware team, will not be matched. The future of MeshCommander, along with MeshCentral, looks a little shaky.

IMC on the other hand, being a product developed and supported by Intel, should have the resources behind it to make it a usable, bug free, functional application. If Intel is going to kill, or at least significantly cripple, MeshCommander development, they should be focused on making sure their own supported product works as expected.

As it stands, per all of the information I've posted in this thread, it is not working as expected.

As for newer AMT versions being a possible contributor to the error I'm getting, all testing I've done in this thread is on an AMT 11.8.70 device. 

[Eduardo_B_Intel]

Hello ICIT,

I wish you an excellent day, Sir.

Your considerations and feedback are truly appreciated and will be shared with our team which is always information used and considered for future implementations. At the movement there is no additional information which can be added to this support inquirer from our side. If you consider something else important and substantial do not hesitate to write back and will be taken into consideration. Thank you for contacting Intel Customer Support and have a great rest of your week, Sir.

[rgord1]

Have a great rest of your week is no substitute for a properly functioning Intel Manageability Commander, which still declares on its web page "Note that trying to connect to a target system that uses self-signed TLS certificates will result in an error. This is expected behavior."

Target systems include Intel's own products!

When is Intel going to address this issue by developing a version of Intel Manageability Commander that is not rendered unusable by self-signed TLS certificates?

[ICIT]

Good question. And it's not just self-signed certificates, it doesn't work with trusted certificates either. On top of that, the quite capable and useful alternative, MeshCommander, has been effectively killed by Intel.