SOL Redirection in Enterprise Mode

[xerex]

Hi,

I am doing SOL Redirection in Enterprise Mode, anybody from you who knows how to create certificate to be passed to IMR_SetCertificateInfo() using the AMT SDK ???I tried below;

IMR_SetCertificate( "cchain.raw", "newkey.pem", NULL) , returns IMR_RES_OK

ClientType ConnectionType = CLI_TLS;

IMR_AddClient( ConnectionType, (char*)sIP.GetBuffer(), NULL), returns IMR_RES_OK

but IMR_SOLOpenTCPSession() returns IMR_RES_TLS_CONNECTION_FAILED.

What is the relationship of the certificates being used during Enterprise configuration(cchain.raw & newkey.pem)of AMT device and with the one passed in IMR_SetCertificate() for SOL Redirection ? Or do they have relationship at all ?

Please guide me, I am newby to internet security but I know how SSL/TLS works.

[Ajith_I_Intel]

Hi xerex,

Thanks for your question on the forum. Before we get into why the TLS connection failed, I would like to know about your environment. What version of firmware is AMT, is it configured in enterprise mode, if using TLS - are you using TLS server authentication or TLS mutual authentication?

If you are using TLS, can you make sure you can connect to the webUI of AMT? The error code clearly indicates there is problem with the certificates setup. I would highly recommend you to read section "3.1.5 Secure session support" in the Redirection Library Design Guide.pdf that can be found in the SDK.

Thanks.

[xerex]

Hi Ajith,

Iusing Windows XPPro SP2. The AMT Firmware version is 2.1.3.1031. Yes, I've succesfully configured it in Enterprise Mode thru remote configuration. In fact, I've successfully done remote control commands like reset, shutdown andpower up in Enterprise mode. And I'm using TLS Server authentication for its security. And Yes, I can connect to the remote AMT device both using webUI and AMT Commander.

Actually, I just picked up the cchain.raw and newkey.pem certificates generated using the batch files used by the sample SCA. I have seen other certificates like newreq.pem, newcert.pem and those found in rootCA and subCA folders. But I am not sure which one of those certificates I found is to be used in SOL server authentication.

And Yes, the first thing I did was read the user guide for Redirection Library particularly Section 3.1.5. And from it, it says "In order to perform the verification, the library must be provided with trusted Certificate Authority (CA) certificates that were used to sign the SSL server-provided certificate. " My problem, I don't know which one of those certificates I found is to be supplied to the library in order to perform server authentication ?

IMR_SetCertificateInfo("????", NULL, NULL);

I tried placing newcert.pem/der and cacert.pem/cer as first parameter for IMR_SetCertificateInfo(), andit returns OK. But still IMR_SOLOpenTCPSession() returns IMR_RES_TLS_CONNECTION_FAILED.

Hoping for your help and thank you very much,

xerex

[Ajith_I_Intel]

Hi Xerex,

Thanks for all of the information. Since you have configured AMT with TLS server authentication, you have basically installed a server certificate in AMT signed by your trusted root certificate. In order for you to authenticate with AMT, you must have installed the trusted root certificate into your cert store. The trusted root certificate that was installed needs to be used for redirection application. SubCA is there only to request a certificate on behalf of the AMT device.

Hope this helps.

[xerex]

Hi Ajith,

Fordemo purposes, I just used the certificates generated using the sample ConfigurationServer. Areyou saying thatI need to install the trusted root certificate where I am running my configurationserver ? In my case where I used the demo CA certificates, which is the trusted root certificate? Is it cacert.pem or newcert.pem? I need to know which file is to be inputted as first parameter for IMR_SetCertificateInfo().

Thanks.

[Ajith_I_Intel]

Hi xerex,

You have to use the cacert.pem(trusted root CA)that signed the AMT web server certificate for TLS server authentication. When you connect through the web UI, do you get any message about trusted certificate not being in your certificate store? If yes, in the same warning window, you can see an option to view AMT certificate. you can look at the chain of the certificates and figure out which trust root to install or pass it to IDE-R application. I need to see the AMT certificate and the CA certificate to let you know if there is any problem.

Thanks.

[xerex]

Hi Ajith,

Talking about certificates, I found from AMT Director.exe that there's a section "Certicate Manager" wherein you can create root certificate and issue new certificate.

I would just want you to ask what type of certificate being generated in "Create Root Certificate.." button, is it the Trusted CA certificate ??? Can I used this to generate the certificate to be passedas 1stparameter in IMR_SetCertificateInfo() ?

And also in "Issue New Certificate.." button, kindly discuss to methe usage of each Certificate Type option, namely, "Sub-CA Certicate", "Intel AMT Remote Console Certificate", "Intel AMT Local Agent Certificate" ,"Intel AMT Remote Configuration Certificate" and "All Permissions Certificate".

Btw, do I need to install different server certificate in AMT-enabled terminalthat is specialized only forRedirection ? During setup and configuration, the chain certificate (contains newcert.pem and subcacert.pem ) and newkey.pem is passed. And I think it is signed by cacert.pem ( Trusted CA ), right ??? But passing cacert.pem in Redirection lib, still returns TLS connection failure when calling API for opening SOL session.

Thanks,

xerex

[Ylian_S_Intel]

Hi,

I just reviewed my own source code in the DTKto try to answer this. From what I know, the call to IMR_SetCertificate() will last for all connections to SOL and IDE-R until you change the values with another IMR_SetCertificate() call. It has no relation with AddClient, and AddClient does not store any information about the certificate (that I know of).

The first parameter of the certificate chain is the list of trusted root certificates in PEM format. In the DTK, I just take all of the certificates in the trusted store of the Microsoft Certificate Store and convert them into a single PEM file I feed into the first argument.

The second argument is a PEM encoded certificate file with both public and private portions of the certificate. It should look like:

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----

I make calls to OpenSSL to make the certificate conversion. This second parameter is only useful if you use Mutual-authentication. I don't recommand you start with that configuration, it's much more difficult.

Also, one more thing that could cause problems. The name you use to connect to the computer must match the name that is in the certificate of the Intel AMT computer. So if thecomputer certificate is "foo.domain.com", you can't use "192.16.5.100" to connect to it, it will fail. You have to use the same name.

Ylian (Intel AMT Blog)

[Ylian_S_Intel]

Ok, about Intel AMT Director. The first parameter of SetCertificateInfo() is a list of trusted root certificates. When you run Intel AMT Commander, it creates the file and leaves it there, it's name is "Tursted Root Certificates.pem", that is what I pass in the first parameter. It's the public key of all trusted root certificates. If you create a new root certificate in Director and add it to the list of trusted certificates, it will be added to this list next time Commander starts.

Once you created a root certificate using Intel AMT Director, you can issue new certificates from that root. You don't really need to use any of these unless you use Remote Configuration or Mutual-Authentication.

A sub-CA certificate is like a sub-root certificate. A local agent certificate is used when mutual-authentication is used on the agent side (When Intel AMT Outpost would need a certificate to log into AMT). A console certificate is when the console requires mutual-authentication (When Intel AMT Commander needs a certificate). A remote configuration certificate is for AMT 3.0 setup, and an "All Permission Certificate" has all of the options of all previous certificates enabled. Again, you should not need to use these unless you perform advanced usages.

Minimaly to perform TLS you need to put a certificate into Intel AMT, then pass the root certificate that signed the Intel AMT certificate into the first argument of SetCertificateInfo(). Also, the connection name must match the certificate name and the AMT certificate must not be expired.

Ylian (Intel AMT Blog)

[xerex]

Hi,

You've said that in your DTK code you justtake all of the certificates in the trusted store of the Microsoft Certificate Store. Does it mean that if I have correct a trusted root certificate installed it will be included in Trusted Root Certificates.pem when starting AMTCommander ???Assume the answer is Yes, so I tried usingthe same file with the one you've used in DTK(Trusted Root Certificates.pem)as 1st parameter for IMR_SetCertificateInfo but still open SOL session in TLS connection fails. Maybe I am wrong with the making of certificates. Please correct me on the steps I've done below.

Here are actually what I did when generating demo certificates using the batch files that sample SCA provide, these arenumbered accordingly. These files are in ConfigurationCertGeneratorSecScripts folder of the SDK

1. Edited the certgen.bat file to set my own

UUID = equalto UUID sent by AMT device during configuration, is this reallyunique for different clientAMT devices ???Is thisbased from the PID-PSS pair ????I see it in certificate details tab underSubject field as CN value, how important is this for the certificates???Isit really needed that the certificate installedin AMT devicehassame UUID as with the UUID in the certificate???

HOSTNAME = hostname of the computer where AMT device installed, is this correct?????? I tried also hostname of the configuring server, webUI still works. But which is which that would run SOL/IDER in TLS connection???

DOMAIN= domain name like corp.company.com

RSA_KEY_BITS= set it 2048 bits since I use AMT 2.0, is this correct?????

2. Run clean.bat, then it deletesold certificate files.

3. Run checkca.bat, then it creates subCA and rootCA folders with files.

4. Run gencertchain.bat, and generates cchain.raw file. For the CertChainBuilder.exe, I only provide 2 certificates the newcert.pem and subCA's subcacert.pem. Do I have to include the rootCA's cacert.pem in the certificate chain ???

OUTPUT files cchain.raw and newkey.pem are used in LoadAMTCertificateAndKey() and works fine. I succesfully configured the AMT device, I can use the webUI remote controlfunctionalities and I can remotely restart, on/off the terminal with AMT device using my own SCA. Only in the webUI, I always I get Certificate warning. From that pop-up warning dialog box, I viewed the certificate and installed it in Trusted Root Certification Authorities store. But still certificate warning pop-ups everytime I open the webUI. That certificate sent by AMT device is the newcert.pem, right???

Thecertification path of that certificatein the warning is:

IAMTroot CA demo ->IAMTsub CA demo 2-> HostName.corp.companyname.com

I tried also installing the root CA demo( cacert.cer), followed by subCA demo 2 ( subcacert.der) and the serv er certificate( newcert.der). After installing these certificates, I run AMTCommander and yes I found the IAMT root CA demo in Trusted Root Certificates.pem. But using the Trusted Root Certificates.pem as 1st parameter for IMR_SetCertificate() still fails when opening SOL session.And still webUI certificate warning appears.

May I know how you created Trusted Root Certiifcate.pem, I mean the openssl command. I am not so familiar with openssl , your help would greatly lessen my researh time about openssl.

One more silly question.., Is it possible in Enterprise Mode setup that I will use No Authentication for both LocalInterface and NetworkInterface during SOAP SetTLSOptions() ???? So that in this way I can avoid the hassle of using certificates because I am sure that my targeted environment issafe andisolated.

Thank you very much.

[ckirchhammer]

Hi,
I am gambling also with the redirection library support. The DIRECTOR shows all my certs and the toplevel CA cert is in the trusted file. The commander generates from the keystore the private and temp cert. So far so good, the COMMANDER is connecting through the soap interface with mutual authentication and all settings of the AMT client machine are available and alterable. If i want to take control via SOL/IDER the COMMANDER complains with SSL verify error(SSLSocket::connect: func SSL3_GET_SERVER_CERTIFICATE, reason certificate verify failed). It seems that the commander is missing the intermediate cert (sub CA) because the pkcs12 export (private/tem) cert file shows only the root CA cert and the console private key.
Used PKI:
rootca-->subca(MS enterprise)-->amtclients
|-->remoteConsole
|-->ProvisionServer (SMS/SCS)
|-->

thats the windows part. Another question is there ongoing linux support for the SDK because the newest SDK only supports realy old linux distributions and the redirection lib is only binary and therfore distribution dependend?

Cheers

[Sreelekshm_S_Intel]

Hi,

we are looking into the SOL question.

Regarding the Linux support for SDK, the next release of SDK will have more Linux versions.

Thanks,

Sree

[Ylian_S_Intel]

Hi and thanks for a long mail. I will try to answer everything I can, make sure to post again if I miss anything.

Yes, when starting Commander, all of the root certificates in the Microsoft Windows certificate store and encoded into a single .PEM file. If you add a new root certificate, you may have to restart Commander to have it take effect.

About the UUID, that value is included in the certificate name when creating a certificate of Intel AMT. The SCS and the latest version of Intel AMT Director do this, but it's completely optional. It's an additional way to know that the certificate is tied to the correct computer. Also, since the platform UUID is always unique and often used to uniquely identify a given computer, it's logical that it be also secured in the certificate. This said, I don't check this value and can be ignored.

About host and domain name. This is often overlooked. The computer's full network name must be in the certificate and it must also be the name used to connect to the computer. So a computer with "bob.intel.com" as a certificate could not be accessed using it's IP address, or an alias such as "bob" or "alias.intel.com". It's important that you have a DNS server that works correctly. Certificates are checked by performing a reverse-DNS lookup, and comparing it to the certificate name and connection name. If you do mutual-auth, make sure other computer on the network can ping you using the exact name that is in your console certificate.

Certificate key size is not important: 1024, 1536, 2048 are the allowed values.

The Intel AMT DTK tools have not been tested well with sub-CA's. You probably have found that it does not work and I will have to go and fix it. You can save yourself a lot of trouble and using Intel AMT Director to create and manage your certificates. Just run Intel AMT Director, go in the certificate folder. You don't have to use any of the other features. In this panel, you can create root certificates, sub-CA's and many other certificates. You can also import and export in many formats. You can import a certificate by drag & droping on the certificate box too. It's so much easier than using the SDK.

I also want to note that once a computer is in enterprise mode, you can use Director to turn TLS on and off and change certificate configuration very quickly. Just create a new security profile and set it on the computer you want. No need to go thru re-provisioning. Create a profile that is simple TLS and set the root certificate that will issue the certificate to Intel AMT. When you set the profile to a computer, Director will get the cert request from Intel AMT, sign it and send the certificate back to Intel AMT.

With mutual-auth, you need to do all of this:

1. Set the root that will sign the Intel AMT cert.
2. Set one or more trusted root certificates. The console cert will have to be signed by one of these.
3. Set the list of trusted FQDN's. This can be "intel.com" or "anydomain.com". In any case, the console certificate must end with one of the trusted FQDN's.
4. Create a console certificate, use Director to do this. It must have the name of the console computer and this certificate will have a special usage tag that AMT will look for. No tag that it will not work.
5. Make sure you have a working DNS and other compute rs on the network can ping the name on the console's certificate and get a response from the console computer.

In general, I don't recommand trying mutual-auth unless you are a pro. You can also start by trying mutual-auth on the agent side only. This way, if you have problems, you can use Director to fix it.

One last thing about mutual-auth. Commander and Director will automaticaly try all the console certificates you have installed on your computer when connecting to an Intel AMT computer. The DTK tools will only try certificates that are marked with the special console usage tag.

Ok, give it a try without a Sub-CA, it sould work well.
Ylian (Intel AMT Blog)