Unable to send web request: SocketException - CLR_E_FAIL (1)

[jasonkaisersmith]

I am trying to send a webrequest to an internal server but am getting the following:

++++ Exception System.Net.Sockets.SocketException - CLR_E_FAIL (1) ++++
++++ Message:
++++ System.Net.Security.SslNative::SecureConnect [IP: 0000] ++++
++++ System.Net.Security.SslStream::Authenticate [IP: 0054] ++++
++++ System.Net.Security.SslStream::AuthenticateAsClient [IP: 000a] ++++
++++ System.Net.HttpWebRequest::EstablishConnection [IP: 027c] ++++
++++ System.Net.HttpWebRequest::SubmitRequest [IP: 001a] ++++
++++ System.Net.HttpWebRequest::GetRequestStream [IP: 0008] ++++
++++ System.Net.Http.HttpMessageInvoker::Send [IP: 0013] ++++
++++ System.Net.Http.HttpClient::Send [IP: 006f] ++++
++++ System.Net.Http.HttpClient::Post [IP: 0011] ++++

My code:

      private const string myCACertificate = @"-----BEGIN CERTIFICATE-----   text of my cert removed for brevity -----END CERTIFICATE-----";

     private static  HttpClient _httpClient = new HttpClient()
     {
            HttpsAuthentCert = new X509Certificate(myCACertificate),
            SslProtocols = System.Net.Security.SslProtocols.Tls12
     };

    string json = JsonConvert.SerializeObject(new MyObject());
    StringContent strcontent = new StringContent(json, Encoding.UTF8, "application/json");

    string url = $"https://myserver:8788/api/path";

    var response = _httpClient.Post(url, strcontent);

The exception is then thrown on executing the "post" command.

I suspect that something is wrong with my code, but I can't see what it is.

So, could somebody help me with this?

[pt2go]

me too，but i can run in ver 1.8.1.221 #1313

[josesimoes]

@jasonkaisersmith does your system has the correct date & time set? Are you sure that that root CA is the same as the one at the device you are connecting to? Are you using which fw version and which hardware?
Also can you succesfully run the SecureClient_WiFi sample from here?

[josesimoes]

PS: you can get almost instant reply if you ask your question on our Discord server. 😉

[jasonkaisersmith]

The SecureClient_WiFi sample does not throw an exception.

But I get "0 Bytes read", I assume that is not expected? (I ran example 1).

The HttpWebRequest sample does not work however.

I have validated that the date & Time are correct and that the certificate is the right one.

HW is ESP32 FW version 1.8.1.307

[josesimoes]

Do you see the HTML of the page being output in VS debug pane?

[jasonkaisersmith]

No. Full output:
Waiting for network up and IP address...
Opening socket...
Connecting...
Authenticating with server...
SSL handshake OK!
Wrote 18 bytes
Read 0 bytes

[josesimoes]

Something off with that digicert website.... if you switch to the howsmyssl it works.

That sample is "hammering" an HTTP GET request, most likely the digicert website is being picky with something missing on the request...

[pt2go]

#1313 SocketException - CLR_E_FAIL (1) , fixed in 1.8.1.307

[jasonkaisersmith]

I have flashed the new firmware, rebuilt and redeployed the SW onto the device, but I still have the same error!

[alberk8]

I think your issue is using self signed SSL certificate. The http request at the moment does not support bypassing SSL validation.

[josesimoes]

Despite certificate validation can't be bypassed, one can use the root CA that was used to sign the self sign certificate and that will work.

[jasonkaisersmith]

That is what I am trying to do. I have a Root CA (Self signed) which I used to sign the Server Certificate which is used by the Web app.
I have imported the Root CA in my Windows machine, and I can call the Web App without any certificate errors (also imported into POSTman with no errors).

But when using this Root CA in the nanoFramework then I am getting this problem. So then I don't know what is wrong.

[Ellerbach]

Something is odd. I have similar situation with Azure IoT Hub. Device certificate self-signed, imported the root self signed certificate in the Azure IoT hub used to create the device derivative certs and it works properly.

[josesimoes]

If you can check the SSL sample authenticating it confirms that your device is running the correct firmware and that the library is working.
The failure on your application it's an indication that either the code or most likely the root cert you're using there is not valid.

[shawty]

Guys, this is also happening with firmware 1.9.1.0 trying to send the certs you have built in to the resources for the Basic Azure IoT sample in the samples repo.

I'm running the sample unmodified, and just constantly hitting this when trying to do the Azure.Open call:

Time/Date is definitely correct as the app is using the built in WiFi connect calls to get/set it.

Certs being used are the ones in the runtime resources pool.

NuGet & FW versions are definitely a match.

Weirdly, if I kill my IoT hub devices, and the IoT hub then recreate it, things will work for a while, but after a time will start going wonky again.

Shawty

[alberk8]

if it work initially, then most likely there is a memory leak (native side) somewhere or some resource relating to SSL/TLS is not released after use.

[Ellerbach]

Can you clarify those 2 sentences?

I'm running the sample unmodified, and just constantly hitting this when trying to do the Azure.Open call

Weirdly, if I kill my IoT hub devices, and the IoT hub then recreate it, things will work for a while, but after a time will start going wonky again.

I don't really understand the sequence you are doing. And if you connect multiple times to Azure IoT Hub. Can you please clarify a bit?

[shawty]

@alberk8 I considered that it may be a memory leak, but once the error occurs, even if I reboot the PC, reprogram the app onto the device, make sure everything is freshly restarted, the error still occurs, the only remedy seems to be deleting and recreating the device ID in IoT hub, or creating a new device and re-programming the app into the device with the new deviceID. Memory leak would surely not survive a complete restart of all the parts involved, unless the system was using non-volatile memory as run-time memory?

[shawty]

Hi @Ellerbach , certainly... (Sorry I did write things in a bit of a rush last night)

"I'm running the sample unmodified, and just constantly hitting this when trying to do the Azure.Open call"

The code I am running to test this is not my own code, I'm 100% using one of the samples provided in the sample repository (The Azure Basic Sample to be exact), and in testing I have not modified the sample in any way that might cause the code to work incorrectly. The sample errors every time when the "Azure.Open" call is made in the Azure connection method.

"Weirdly, if I kill my IoT hub devices, and the IoT hub then recreate it, things will work for a while, but after a time will start going wonky again."

When I encounter the error, if I delete the device ID I am trying to connect too, then recreate that device ID , or if I create a brand new device ID within my IoT hub, then run the sample code on my device, it will work perfectly the first time, but if I then stop that code and re-run it, it will fail with the CLR_E_FAIL error.

Very occasionally it will run twice in succession (I've actually only got this to happen once) , in most cases it will fail.

When it fails, recreating or making new as mentioned works once more, then fails again on subsequent runs.

If you would like me to screen capture a demo I can easily do that, no problem.

Cheers
Shawty

[Ellerbach]

Thanks, got it. If you run it a second time, the device will certainly needs to be rebooted. For this:

1. clean the deployment area
2. then unplug physically and replug physically the device
3. redeploy your code

Depending how you stop the device, the native part may not be fully cleaned. This is related to IDF used in ESP.
In the real life, you can use a global try/catch and put the device to deep sleep for couple of milliseconds. It's the equivalent of a cold boot.

[shawty]

That's just it though @Ellerbach if you see my notes above, I reply to @alberk8 , I did just that, and upon restarting still encountered the same.

I will however re-test just to make sure and feed back, let you know on this.