Redirection Exception - Page 2

jacace · ‎10-30-2008

Hi there,

I'm trying to use SOL/IDE-R in an Enterprise provisioned machine with TLS enabled (basic, not mutual) and I'm getting a Exception.

I'm able to see the asset information and to power up/down the machine (with EOI, NOT WsMan), but SOL/IDE-R does not work, so I'm sure it's not an access issue (cause the machine security certificate is added is the client trusted root certificate store and the user being used is admin).

The method which one returns the error is (AmtRedirectorWrapper.cs line 617):
r = IMR_SOLOpenTCPSession(clientId, login, data, IntPtr.Zero);

An the error is in r = IMRResult.IMR_RES_SOCKET_ERROR

Help!

Javier Andrs Cceres Alvis

Andrew_S_Intel2 · ‎11-24-2008

I'll keep using this thread to answer questions about standard TLS (not mutual), and continue addressing the mutual TLS questions in the other thread.

When you set up the profile to provision in normal TLS, you checked the box for TLS in the profile, then chose the local system and set a profile of WebServer, correct? At that point an AMTsystem provisioned using that profile would automatically get the trusted root, and you should be able to access the webUI (assuming the profile is setup for that), from the CA without issueusing https:// :16993. For instance, if the AMT system FQDN was intelamt4.vprodemo.com, https://intelamt4.vprodemo.com:16993 should take you to the webUI login.

If you can't access the webUI, then something has gone wrong in the provisioning and we'll need to dig deeper there. If you can access the webUI, then we can start looking at the application or code. We'll start with the RedirectionConfig.exe, since most of the SDK examples are smart enough to look in the Windows trust store. If the same arguments you used before (RedirectionConfig.exe -g -user admin -pass PB4e

RBens2 · ‎11-25-2008

You need to double-check the name that was given to the AMT system by Director. Sometimes, Director will give the system a name that you didn't expect, and if the name given by Director in the configuration process doesn't match the name that has already been registered in DNS by the OS, then the certificate match to the system name will not match.

jacace · ‎11-25-2008

Quoting - rogerb

You need to double-check the name that was given to the AMT system by Director. Sometimes, Director will give the system a name that you didn't expect, and if the name given by Director in the configuration process doesn't match the name that has already been registered in DNS by the OS, then the certificate match to the system name will not match.

Hello Roger,

I have tried by repeating the provisionprocess but Director always gave a not expected name.

So at that point, I thinkcan not influence or change the way DIrector names machines.

Thanks a lot,

Javier Andrs Cceres Alvis

jacace · ‎11-25-2008

Quoting - Andrew Schiestl (Intel)

I'll keep using this thread to answer questions about standard TLS (not mutual), and continue addressing the mutual TLS questions in the other thread.

When you set up the profile to provision in normal TLS, you checked the box for TLS in the profile, then chose the local system and set a profile of WebServer, correct? At that point an AMTsystem provisioned using that profile would automatically get the trusted root, and you should be able to access the webUI (assuming the profile is setup for that), from the CA without issueusing https:// :16993. For instance, if the AMT system FQDN was intelamt4.vprodemo.com, https://intelamt4.vprodemo.com:16993 should take you to the webUI login.

If you can't access the webUI, then something has gone wrong in the provisioning and we'll need to dig deeper there. If you can access the webUI, then we can start looking at the application or code. We'll start with the RedirectionConfig.exe, since most of the SDK examples are smart enough to look in the Windows trust store. If the same arguments you used before (RedirectionConfig.exe -g -user admin -pass PB4e

Gael_H_Intel · ‎11-25-2008

Javier, can you do anything with the AMT on your system? It sounds like the provisioning did not complete correctly. I just put a blog out there that addresses thissituation. Basically if something goes wrong, you have to unconfigure the system and reprovision it.

Very Important Note:If a serious operational error occurs during the setup and configuration process (for example, TLS is configured incorrectly because a certificate or private key was installed inadvertently, or a certificate replacement was performed that does not align with current keys), and the platform is then transitioned to Operational Mode, the Intel AMT device may not be accessible remotely. The Intel AMT device needs to be returned to the Factory Mode by using the BIOS sub-menu Unprovision option.

Gael_H_Intel · ‎11-25-2008

Hi Javier - I just wanted to add on to my last post that I don't think you shouldchange your provisioning method - I was just thinking that looking at what the SCA sample is doing might help you/us understand what is actually happening and why Mutual Authentication isn't working.

Andrew_S_Intel2 · ‎11-25-2008

Quoting - javierandrescaceres@gmail.com

Hello Andy ,

If I use TLS basic I can access the Web UI but when I switch to TLS mutual it appears a window like the one shown in the attached picture and no matter which certificate I select, becasue it's always rejected (I have selected the root trust certificate and others I have created by deriving itbut they do not work). I'm running the RedirectorConfig.exe tool under the machine I'm developing, and this machine has nothing to do with the test domain or amt test machine. It is necesary to run the tool for example in the SCS server? (under the SCS user)
I actually can notconnect the amt machine by WebUI neither RedirectorConfig.exe.

Thanks a lot,

Javier Andrs Cceres Alvis

Javier,

The certificate that shows up in the image you attached, is that the one you created for mutual authentication? The machine you're running the tool or your code from should also have the certificate for mutual authentication, sincethat's how the AMT system is validating thatthe system has permission to connect. Every system thatwill be talking to AMT would needa cert in the mutual authentication case. You wouldn't necessarily need to runthrough the process on page 53 for each system, you could export the cert created from the CA into a file and import it in that manner (I can give you some more details here if you like).

You don't need to run the tool example on the SCS server, but I suggested it since I was guessing that's where you requested the cert from.

jacace · ‎11-26-2008

Hello Gael and Andy,

Please see these steps I did with Director:

First round:
1-I created a Basic profile
2-I created a Key
3-I entered the key into BIOS
4-Director received the Hello message and provisioned the machine
5-I was able to connect to machine with Director, Commander (redirection) and WebUI.

Second round:
1-I created created a root certificate and added it into windows trusted certificate store
2-I issued an all permissions certificate based on the root certificate
3-I issued a sub-ca certificate based on the root certificate
4-I created a server only TLS profile by selecting the certificate I created in (1) to be the issuer certificate and pushed it into machine:
5-Director configured the machine with the server only TLS profile correctly
6-I was able to connect to machine with Director, Commander (redirection) and WebUI.

Third (and most important) round:
1-I created a server + console TLS profile by selecting the certificate I created in (1-second round) to be the root trusted one and by I selecting the certificate I created in (1-second round) to be the issuer certificate. I finally entered the Director host machine FQDN name as the Trusted Certificate Names and pushed into machine
2-Director configured the machine with the server + console TLS profile correctly and it was able to connect only ONCE; as soon as I disconnected it and I tried to connect it again Director could not do it.
5-I was not able to connect to machine with Director, Commander.
6-When I tried to access the machine by its WebUI, IE browser prompted a window to choose one of the certificates I created in 1 or 2 (second round) but all of them were rejected.

I repeated the 3 rounds twice with same bad results.
I finally did all again with "streams events to file" option enabled for sending you but I don't know why Director and WebUI could connect to AMT machine after pushed the server + console TLS profile, so I went happily to run Commander and it could connect it, but when I clicked on the take control button I received the error what I have always received: "Serial-over-LAN error: IMR_RES_TLS_CONNECTION_FAILED" (see attached file).

So, I have a bitter sweet taste now:
Sweet bacause Director did not lose the connection as SCS did it
...and bad taste cause I do not why it "partially" worked if I have tried it before.

I'm going to repeat all steps again with other machine just to see that happens.

Thanks a lot,

Javier Andrs Cceres Alvis

jacace · ‎11-26-2008

Hello Gael& Andy,

I repeated the steps in another machine and I got the same resultsat first time.

Imean, I could connect with server + console TLS with Director and WebUI, but when I try to connect for using the "Remote Control" featuresin Commander I got the same error message: "Serial-over-LAN error: IMR_RES_TLS_CONNECTION_FAILED".

I'm going to move one of the machines to work with SCS just to test if works like Director (I mean, everything running ok except by Remote Control).

Thanks a lot,

Javier Andrs Cceres Alvis

jacace · ‎11-26-2008

Hello Gael and Andy,

I moved on SCS and this is my feedback:

I did these steps all afternon with SCS:

First round:
1-I created a Basic profile (NO TLS)
2-I created a key
3-I manually entered the key into BIOS
4-SCS applied configuration correctly
5-I was able to acces the machine by the WebUI, commander (redirection) and my code.

Second round:
1-I created a Basic TLS profile (only server) by selecting a root certificate I created in MS Cert. Authority
2-I changed the machine profile to the new one
4-SCS applied configuration correctly.
5-I was able to access the machine by the WebUI (but only typing the FQDN in IE browser) and commander showed me connections warnings, so I could not redirect it. It's really important redirecting the machine by using its IP because for example in discovery event you do not have other info or the host name property in AMT Sytem object is returned as the same IP.
My code did not work for redirection and I got the same error which one I started this thread.

I was not able to perform the third round cause I was not able to complete the second one.

After working all day in this issue I can say that SCS and Director name security certificates a bit different. Director names them with IP address and SCS names them with FQDN. This can be a pain in the neck. I actually try to connect with Commander and it shows me connections warnings because of the "Connection name, DNS name, certificate name mismatch.".

Thanks a lot,

Javier Andrs Cceres Alvis

THOMAS_P_Intel1 · ‎12-11-2008

Javier,

The handling of certificates will be dependent on the software you are using. There are options that some software may implement and others do not. Here is what is going on in the second round you describe above.

The SCS is indeed only using the FQDN in the certificate. This is the most robust option. Using the IP address in a DHCP environment wouldn't make sense since the IP address may change. SCS requires DHCP.
It is common for the client software in a TLS handshake to require a match between the FQDN and the certificate CN from the endpoint it is negotiating with. The SCS behaves this way and most browsers do to although some will allow you to override this after displaying a security warning. To demonstrate this, try pointing your browser to https://www.wellsfargo.com and again to https://151.151.88.144. In the latter case, you should see a warning from your browser about the certificate only being valid for the URL and not the IP address (unless Wells Fargo's IP has changed). If you require the use of TLS and connections through IP addresses, your software will have to allow a mismatch but this practice has security implications.

Hope this helps.

Tom

jacace · ‎01-07-2009

Quoting - Thomas Propst (Intel)

Javier,

The handling of certificates will be dependent on the software you are using. There are options that some software may implement and others do not. Here is what is going on in the second round you describe above.

The SCS is indeed only using the FQDN in the certificate. This is the most robust option. Using the IP address in a DHCP environment wouldn't make sense since the IP address may change. SCS requires DHCP.

It is common for the client software in a TLS handshake to require a match between the FQDN and the certificate CN from the endpoint it is negotiating with. The SCS behaves this way and most browsers do to although some will allow you to override this after displaying a security warning. To demonstrate this, try pointing your browser to https://www.wellsfargo.com and again to https://151.151.88.144. In the latter case, you should see a warning from your browser about the certificate only being valid for the URL and not the IP address (unless Wells Fargo's IP has changed). If you require the use of TLS and connections through IP addresses, your software will have to allow a mismatch but this practice has security implications.

Hope this helps.

Tom

Hello Tom,

I'm back again after holyday season.
I solved the redirection issue and I could find out the warnings you mentioned during the process; there were many things that made the problem happened but I'll discuss them in a next post, by the meanwhile I can say briefly that it was about certificate and settings.

Thanks a lot,

=)

Gael_H_Intel · ‎01-07-2009

Hi Javier,
I am glad that you solved this problem - again - we would love to see your next post - or perhaps a blog? :-)
I'm going to close this thread - please open a new thread for new questions.

Thanks,
Gael

Gael_H_Intel · ‎01-07-2009

Hi Javier,
I am glad that you solved this problem - again - we would love to see your next post - or perhaps a blog? :-)
I'm going to close this thread - please open a new thread for new questions.

Thanks,
Gael