SSL Spider throwing CLR_E_FAIL (4)

I cannot get any SSL request working using the exact code from the 4.3 SDK sample. Anyone have any luck with this?

Exception System.Net.Sockets.SocketException - CLR_E_FAIL (4)

#### Message: 
#### Microsoft.SPOT.Net.Security.SslNative::SecureConnect [IP: 0000] ####
#### Microsoft.SPOT.Net.Security.SslStream::Authenticate [IP: 0060] ####
#### Microsoft.SPOT.Net.Security.SslStream::AuthenticateAsClient [IP: 000c] ####

I updated the SSL seed using MFDeploy. I have tried the Verisign cert from the sample as well as my own exported one from my PC. The certs and code work perfectly fine in the emulator, which leads me to believe this is clearly a Spider issue.

Also note: I am setting my system time to be current.

Microsoft.SPOT.Hardware.Utility.SetLocalTime(new DateTime(2014, 12, 2));

I have scoured the web and these forums only to find things like:

  • Update your SSL Seed - did that
  • Update your firmware - did that
  • Set your device/system time - did that
  • Use a valid cert - did that, so far as I know

Regarding certs, the thing is, the Verisign cert that is in the sample shows an expiration of 8/1/2028. And it works in the emulator - so does that mean its valid, or is the emulator somehow using the network stack of the PC and it’s certs?

And to make matters worse, I read about there being a memory leak bug using SSL… for 4 years now. Is MS going to get up and fix that? I mean, IoT kinda requires ‘connected’ devices, no? I would think SSL connection to Azure is a pretty BIG deal.

I don’t know about this specific problem but in Microsoft’s recent announcement of their re-commitment to NETMF they listed fixing the networking problems as one of the items at the top of the list. I believe 2015 will finally be the year we have useful networking :slight_smile:

@ dapug - If you can post a small sample and send us the certificate you used, we can take a look.

@ John, the code I used is right here:
https://netmf.codeplex.com/SourceControl/latest#client_v4_3/Product/Samples/HttpClient/HttpClient.cs

netmf installs this in the Docs folder as you probably know. All I did was copy the code into the Gadgeteer project for the spider, all the logic as-is. And I added the same Verisign cert from that example as a resource in the Gadgeteer project. As mentioned, I also tried other certs (happy to send those if it’s something worth looking at).

Did you want me to just zip up the gadgeteer project with this code and a few certs to try? Or is the above info sufficient?

ian, I appreciate your enthusiasm. I hope for the best here with you. I have to admit though, having spent nearly 10 years at MS, never assume! MS is unfortunately extremely good at fumbling what seems perfectly obvious and logical to the customer (and dev community). Unless I see a post by ScottGu or some exec or GM (as appropriate) specifically state exact descriptions of features and delivery… assume it is NOT on their radar or agenda. A general statement about renewed interest in netmf means almost nothing to me. Must be proven by show n tell. On the bright side, like I said, I do hope for the best, and maybe they will surprise us - specifically to this level of detail like the SSL memory leak fix here.

But aside from little fixes, MS has a long, [em]long[/em] way to go if they are to succeed at all with NetMF. They are late to the IoT party, to say the least, and this is where the industry energy/movement is. Far more than netmf itself is needed (warrants another thread)). This is something I pushed on before leaving the company, and it fell mostly on deaf ears. Colin Miller and others must have struck an opportunity finally - and a welcomed change for sure. That said, you’ll noticed that the focus is on Windows Embedded more than it is actual tiny devices.

Anyway, I suppose I forked the issue in two: SLL memory leak, and then just flat out SSL not even working at all. The latter has me pretty puzzled at the moment.

I’m referring specifically to the “Networking” paragraph here. It doesn’t quite outline exact features but we’ve outlined those features that need work and hopefully its safe to assume this is what they are referring to. We’ll all cross our fingers and wait to see…

http://blogs.msdn.com/b/netmfteam/archive/2014/09/23/net-micro-framework-sdk-beta-released.aspx

[quote=“dapug”]
That said, you’ll noticed that the focus is on Windows Embedded more than it is actual tiny devices.[/quote]

Of course I can’t find it now… But somewhere there is a video from a recent conference (MVP Summit?) that clearly shows a slide where NETMF not just Windows Embedded is a major part of their new plan. But, believe me I think I’ve become the biggest skeptic on the forum… I’ll believe it when I see it. But, I really think it just might happen now. Mr. Nadella seems to have the right vision.

@ dapug - I’ve noticed that the certificate you choose is very important. Some don’t work at all while others do. I have verified that the VeriSign one in the sample does not work, but a few I have tested do. So it looks like it might be an issue with NETMF itself since it seems the emulator uses the computer’s networking stack and not NETMF’s lwip. If you have a board from a different manufacturer that supports lwip, testing that could help narrow down the cause.

I’ve usually had success with going to the site in question and using the certificate your browser shows as the root CA used to identify the site.

John, excellent point and idea. But still no luck.

Try this: super simple hello-world, download https://www.google.com

I went to the browser, opened up the cert/CA google uses, exported it as a base64 .cer file, loaded this into the spider project, made the request, and poof… Exception System.Net.Sockets.SocketException - CLR_E_FAIL (4)

I’m not sure how to make this any more simple.

I have similar problems with SSL usage on the Spider and the Raptor board. Like John mentioned it could be a problem with specific certificates, which could be confirmed with the detailed description of CLR_E_FAIL(4) on this page:

Which states:

With some certificates it works and with some not.

@ dapug - We will keep looking to see if it is anything on our side that is causing it. For now, though, I would just keep looking for a certificate that does work.

Thank you all. I think we can agree it is a cert issue. The problem I have is “some work, some don’t”, and I am not comfortable shooting from the hip at random here. There is a reason and explanation for everything, and we should know the cause for the ones that don’t work on netmf/gadgeteer vs PC. Error 4 = Could not decrypt. Excellent. Now why?

When Google’s own cert doesn’t work on google, what other certs do you suggest? Its silly to say try another. I can only think of the following explanations:

  • I exported the cert improperly (in fairness I always blame myself before coming to the forums :slight_smile: )
  • I applied the wrong cert (but what should I try beyond the actual CA of the site I am targeting?)
  • my httpwebrequest is not applying the cert (not sure what I would need to do beyond setting the x509 object as shown in the sample)
  • netmf has a bug
  • gadgeteer spider has a bug

Any other possibilities?

Btw, here are the steps I followed in exporting the cert, which seemed to work for this guy on his spider, at least with netmf 4.2:

John, I don’t have another board to try, but I am tempted to buy another spider for prototyping once this one is decrypting SSL and put into full time use.

1 Like

@ dapug - The OpenSSL version found in NETMF is quite a few years old now, it’s 1.0.0d, so it is possible it is related to that. If it helps, the certificate that I used that worked for the sites I tried is “Equifax Secure Certificate Authority”.

I believe that the error 4 “The certificate signature could not be decrypted” is actually related to the RTIP stack which we no longer use. So the 4 is a different error.

1 Like

ah, interesting. So do you know what the 4 code would map to?

Maybe already obvious, but on the spider I am running the latest everything (netmf 4.3, and the 2014 R5 GHI sdk, firmware, loader, etc).

@ John Interesting. I am going to dig deeper today. Could it be possible to nail down the issue checking the current code?

@ dapug - I was not able to find what code 4 maps to immediately.

@ AWSOMEDEVSIGNER - I’m not sure what you mean by checking the current code.

@ John, I tried the Equifax cert, no love. I haven’t tried all of this on my Hydra… is that worth a try? (again, not sure if this is a netmf issue, or gadgeteer, or me, or what right now).

ok, glad I didn’t bother to set up and try. Though I admit my assumption came from a glance at the Hydra spec page… (see pic)

@ dapug - The Hydra catalog entries have been updated. It only supports Ethernet over ENC28.

@ John - The source code of the NETMF CodePlex distribution. Maybe that helps to identify errors. But not sure.

@ AWSOMEDEVSIGNER - Yes, it would definitely be possible to find the issue by looking at the code you see on CodePlex.

1 Like