Link Copied
Hello, ICIT,
I hope all is well.
The tests were performed with both electron versions. The only difference is with the option SHA1. Intel has improved the security with the latest version, only TLS connections are supported, and SHA256 is a requirement. Please try with the option unchecked.
I am pasting a picture of what I have from add or remove a program.
Regards,
Miguel C.
Intel Customer Support Technician
BTW, I uninstalled IMC again and reinstalled using Electron v25.3.0. When I launch IMC it just shows a blank window.
After another uninstall and reinstall using Electron 8.5.5, I'm back where I started. IMC is running but still reports v2.3.0 in the UI.
And under Help > About
In Windows Control Panel > Programs and Features it does report as v2.4
So I'm working under the assumption that this is just a UI issue where a version number was not updated in a source file somewhere and likely not a concern regarding functionality.
Getting back to the original issue of IMC displaying an error when connecting using TLS...
Initially was attempting to connect with AMT configured using the embedded self-signed TLS certificate, which, as noted above, is not supported by IMC.
To use TLS to connect to an AMT client using IMC, the following must be in place...
- The hostname must be set to a FQDN, IP address cannot be used
- Use TLS enabled
- A certificate must be installed on the AMT device with the Subject CN set to match the FQDN of the device
* Screenshot of certificate in Windows
* Screenshot showing above certificate installed an AMT device
- The root CA certificate (issuer certificate) must be installed in the Trusted Root Certificate store on the Windows computer where IMC is running. This enables IMC to trust the certificate installed on the AMT device
* Screenshot showing the certificate is indeed trusted on the Windows computer where IMC is running
- IMC v2.4 supports TLS 1.1 and newer, it does not support TLS 1.0. TLS 1.1 was implemented in AMT 11.6 so the connection must be to a computer running this version of AMT firmware or newer.
All of the above is in place however I still receive the same connection error.
To troubleshoot further I launched IMC in debug mode from the command line
C:\Program Files (x86)\Intel\Intel Manageability Commander\electron.exe --loglevel=debug
This generates debug level messages in the log file located here
C:\Users\Username\AppData\Roaming\Intel\Intel Manageability Commander\application.log
From these messages I gather that IMC receives the certificate from the AMT device and saves it as tempCert.cer. It then runs
certutil -verify
to get details and checks the hostname against the Subject CN
{"level":"debug","message":"Setting up connection: host=muse.homenet.local; port=16993; authMode=0; username=admin; password=mypassword; useKerberos=false; tls=true"}
{"level":"verbose","message":"Getting AMT class CIM_SoftwareIdentity"}
{"level":"debug","message":"Writing TLS cert temp file: C:\\Users\\USER~1\\AppData\\Local\\Temp\\tempCert.cer"}
{"level":"verbose","message":"CertUtil output: \r\nIssuer:\r\n O=ICIT\r\n S=IN\r\n C=US\r\n CN=MeshCommander Root CA\r\n Name Hash(sha1): e6773dcb281d379b6b0a2b5337f57bab814031b9\r\n Name Hash(md5): 7b92aadae2c55fc114b9cf2a27f55b9a\r\nSubject:\r\n O=ICIT\r\n S=IN\r\n C=US\r\n CN=muse.homenet.local\r\n Name Hash(sha1): 8b860183a274ed79ca3edfcb2bede31a3857aa0d\r\n Name Hash(md5): 2a6a59ff610b774414ba5d27bf19fed0\r\nCert Serial Number: 023615\r\n\r\ndwFlags = CA_VERIFY_FLAGS_ALLOW_UNTRUSTED_ROOT (0x1)\r\ndwFlags = CA_VERIFY_FLAGS_IGNORE_OFFLINE (0x2)\r\ndwFlags = CA_VERIFY_FLAGS_FULL_CHAIN_REVOCATION (0x8)\r\ndwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)\r\ndwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)\r\nChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN (0x20000000)\r\nHCCE_LOCAL_MACHINE\r\nCERT_CHAIN_POLICY_BASE\r\n-------- CERT_CHAIN_CONTEXT --------\r\nChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)\r\nChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)\r\n\r\nSimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)\r\nSimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)\r\n\r\nCertContext[0][0]: dwInfoStatus=104 dwErrorStatus=40\r\n Issuer: O=ICIT, S=IN, C=US, CN=MeshCommander Root CA\r\n NotBefore: 1/1/2018 1:00 AM\r\n NotAfter: 12/31/2049 1:00 AM\r\n Subject: O=ICIT, S=IN, C=US, CN=muse.homenet.local\r\n Serial: 023615\r\n Cert: 90f01f5b7f0eaa083461992a87274b03d8af38e2\r\n Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)\r\n Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)\r\n Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)\r\n ---------------- Certificate AIA ----------------\r\n No URLs \"None\" Time: 0 (null)\r\n ---------------- Certificate CDP ----------------\r\n No URLs \"None\" Time: 0 (null)\r\n ---------------- Certificate OCSP ----------------\r\n No URLs \"None\" Time: 0 (null)\r\n --------------------------------\r\n Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication\r\n\r\nCertContext[0][1]: dwInfoStatus=10c dwErrorStatus=0\r\n Issuer: O=ICIT, S=IN, C=US, CN=MeshCommander Root CA\r\n NotBefore: 1/1/2018 1:00 AM\r\n NotAfter: 12/31/2049 1:00 AM\r\n Subject: O=ICIT, S=IN, C=US, CN=MeshCommander Root CA\r\n Serial: 065494\r\n Cert: 47c7ee6ffcf018ecd493631b7909cbd61cc8030d\r\n Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)\r\n Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)\r\n Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)\r\n ---------------- Certificate AIA ----------------\r\n No URLs \"None\" Time: 0 (null)\r\n ---------------- Certificate CDP ----------------\r\n No URLs \"None\" Time: 0 (null)\r\n ---------------- Certificate OCSP ----------------\r\n No URLs \"None\" Time: 0 (null)\r\n --------------------------------\r\n\r\nExclude leaf cert:\r\n Chain: 90f01f5b7f0eaa083461992a87274b03d8af38e2\r\nFull chain:\r\n Chain: 3bf2b959269132595796685978af13f681842665\r\n------------------------------------\r\nVerified Issuance Policies: None\r\nVerified Application Policies:\r\n 1.3.6.1.5.5.7.3.1 Server Authentication\r\nCert is an End Entity certificate\r\nCannot check leaf certificate revocation status\r\nCertUtil: -verify command completed successfully.\r\n"}
{"level":"debug","message":"TLS cert subject CN matches target hostname (muse.homenet.local)? false"}
{"level":"debug","message":"TLS cert DNS Name matches target hostname? false"}
{"level":"verbose","message":"TLS certificate verification results: false"}
For some reason IMC is determining that the hostname does not match the certificate Subject CN, when in fact it does. See the false results in the log messages above.
Looking for some insight on why this is happening and what to try next.
I just meant that I verified the SHA1 hash of the file I downloaded matched was is shown on the download page
Also, I see that my missing post finally showed up (twice).
This is not a self-signed certificate though. I created it using MeshCommander's built-in certificate authority. It is signed by a root CA certificate, also created in MeshCommander, that is trusted on the Windows system that IMC is running on.
There is a valid chain of trust so it should work.
As far as Intel AMT specific certificates, it's my understanding that those are needed only for initial provisioning when the AMT client is reaching out to the Setup and Configuration Application (SCA). That type of certificate must be installed on the SCA device, for example, when using Endpoint Management Assistant server.
I can't find any documentation stating that creating TLS connections to a client require a special certificate. Per the IMC documentation, the only requirement mentioned regarding certificates is that a certificate must be trusted on the Windows computer.
6 Certificate Checking
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 host name 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.
Additionally, I looked at section 4 of the IMC release notes but there is nothing mentioned about certificates.
Thanks. In the meantime I tried a different approach by adding an AMT certificate via PowerShell, using OpenSSL to generate the certificate. I followed the procedure documented here:
Intel vPro Technology Module for Windows PowerShell Installation and User Guide.pdf
6.14 TLS Configuration Flow Using PowerShell Snippets
here:
Intel AMT Implementation and Reference Guide
and here:
GitHub - rgl/intel-amt-notes: notes about intel amt
I created a new root CA certificate in OpenSSL that is trusted on the Windows computer where IMC is running. The AMT certificate is signed by that root CA.
In the end no luck, I still get the TLS error when attempting to connect. Although I did notice the IMC debug log was lightly different
{"level":"debug","message":"TLS cert subject CN matches target hostname (muse.homenet.local)? true"}
{"level":"debug","message":"TLS cert DNS Name matches target hostname? false"}
{"level":"verbose","message":"TLS certificate verification results: false"}
It now shows that the cert subject CN matches the target hostname, whereas before it returned false. The DNS name match is still false, although I'm not certain if that's required to be true. There's nothing in the documentation that I can find that mentions anything about a DNS name needing to be in the TLS certificate other than the Subject CN.
