Whats the difference between these two certificates

[sohaib2y]

Hi

Whats the difference between these two root certificates, one placed at "CertGeneratorClientSecScripts rusted_rootCA" named "trusted_cert.cer" and other placed at "CertGeneratorSecScripts ootCA" named "cacert.cer", these are placed by Sample SCA.

The default.conf.xml files has the name of trusted_cert.pem as trusted root certificate, but when I include this in browser as trusted root certificate, browser does't automatically allow https connection with AMT, but when I specify "cacert.cer" as trusted root in browser, it works automatically.

Sohaib

[Ajith_I_Intel]

Hi Sohaib,

That is an excellent question. In order for the sample SCA to issue certificates for the client Intel AMT devices, it needs to act as an subordinate CA. When you first start the SCA, it will create a request file for subordinate CA which needs to be signed by an enterprise root CA. SCA also allows you an option to create a demo rootCA that can be used to sign the subordinate CA request file and issue a certificate for SCA. The demo rootCA file here is named as cacert.cer.

SCA must provide root certificates to an Intel AMT device as a step in configuring mutual authentication. The device uses the root certificates so it can trust client certificates presented by management applications. This is the reason SCA prompts the user to generate a trusted root CA(trusted_cert.cer) which will be sent to Intel AMT devices if the configuration file specifies it. Alternatively, an enterprise root CA (if available)can be used for this task.

Hope this answers your questions. Please let us know if there are further questions.

[sohaib2y]

Hi Ajith,

May be I did't ask the question intelligently. What I wanna ask is: SCA only needs one root (enterprise or demo) CA's certificate (that I think is cacert.cer) that will be given to AMT if mutual authentication is used, and one subordinate certificate (and the private key, ofcourse) signed by above mentioned root CA. These are located as subdirectories in directory "CertGeneratorSecScripts".

Now what that "trusted_cert.cer" certificate is used for? Is this root CA's certificate, but that is "cacert.cer", and "cacert.cer" is used to sign SubCA's certificate, should't we send this "cacert.cer" to AMT machines (if mutual authentication is used).

Hope I asked it in a better way now.

[Ajith_I_Intel]

Hi Sohaib,

I am working on getting more clarification to your question. Hope to get back to you very soon. Thanks for your patience.

[sohaib2y]

Hi Ajith,

OK, Thanks

[virtual_walker]

Hi Sohaib,

AMT TLS mutual authentication works by authenticating the certificates of both AMT (which is the server) and the management console (MC). AMT authenticates the certificate of the MC and on the other endMC authenticates the certificate of AMT before secured communication begins. Its just like server authentication that works on both ends.

To setup the certificates of both AMT and MC, first you need to create the certificates. For mutual authentication you need to create two sets of certicate chains, one for AMT and one for MC.

For the AMT certificate chain, the procedure is the same as server authentication.

1.Create a root certicate. (let say AMTroot.cer)

2.Create a subordinate certificate. (let say AMTsub.cer)

3.Create a certificate signed using the subordinate certificate. (AMT.cer)

4. Build the certificate chain using CertChainBuilder.exe provided with the SDK. (let say the output certificate chain file is AMT.raw)

For the MC certificate chain, the procedure is the same as above. Let say you have the certificate named MCroot.cer, MCsub.cer and MC.cer.

Certicate Installation

The next thing that we should do is send the certificates needed in the AMT side. We need to send the certficate chain file (AMT.raw)and MC root certificate (MCroot.cer). Then set MCroot.ceras the trusted certicate in AMT. The trusted root certificate will be used to authenticate the client. The trusted certificate in AMT acts like any root certificate stored in the certificate store of your PC. Client certificates are basically compared with it during authentication. Client certificate in this example is the MC.cer, which is trusted by the MCroot.cert installed in the AMT device.

Certificate Handshaking (Simplified) Before a secured Communication Channel w/ AMT Is Established(Assuming that configuration is finished, meaning the trusted certificate was set in AMT and AMT.raw was sent to AMT.)

1. MC sends MC.cer to AMT.

2. AMT authenticates MC by comparing MC.cer w/ the set trusted root certificate which is in this example: MCroot.cer.

3. When it is authenticated, AMT sends AMT.cer(contained inAMT.raw sent to AMT during configuration) to MC.

4. MC authenticates AMT.cer by comparing it with AMTroot.cer.

5. Once authenticatedthe secured communication channel is established.

(Note: This is a very simplified handshaking. Otherparts like private keys and public keys also play a role in the authentication.)

I hope this helps!

virtual walker

[sohaib2y]

Thanks VW for such a comprehensive reply, actually I am asking a different quesiton, My question is "why two roots?". In ur example u also created 2 roots, One root can perform equally well. AMTsub.cer and MCsub.cer could be signed by a single root.

In an enterprise environment there may be only one root and above mentioned two subordinate certificates 'll get signed by that root only.

Sohaib

[virtual_walker]

Yes, using one trusted root certificate will definitely work. Actually, you can use the same set of certificates for client and server authentication. But obviously that doesn't make sense:-) its like trying to authenticate something that we already know is trusted.

virtual walker

[Ajith_I_Intel]

Thanks Virtual_Walker for the great explanation. This is very useful for somebody beginning to use TLS and dealing with certificates.

Sohaib,

Please download AMT 3.0 SDK when you get a chance. You can find it here http://software.intel.com/en-us/articles/download-the-latest-intel-amt-software-development-kit-sdk. After you unzip the folder, in the docs directory, please look for "Developers Guide to the Sample Setup and Configuration Application.pdf" document. This document describes a lot about the sample configuration server. Let me know if you find it useful and have further questions.

Thanks.