I am trying to access an HTTPS url which my company controls with a SCM20260E. According to my coworker, apache doesn’t care about the certificate that my device is sending it, however if I do not use the matching certificate, then the webRequest.GetResponse() function fails at the internal library function “AuthenticateAsClient()”. I tried simply not providing an X509Certificate so that webRequest.HttpsAuthentCerts would be null, but that also fails the “AuthenticateAsClient()”. Is there any way to connect to an HTTPS url without providing a root certificate?
It might be possible but what is the benefit?
Gus,
We have devices that sit out in the field at customer sites for years. In order to download updates over the air, these devices need access to our servers. Our servers currently have a redirect from HTTP to HTTPS for security reasons, so HTTP will not work. Using a certificate following the methods outlined on the TLS client tutorial here: TLS Client, HTTPS will work when we install the latest firmware, but our certificates are only valid for a year, so if we wanted our units to be able to be updated over the air, we would have to update the certificate within the project properties to be valid again. This would require an annual update of tens of thousands of devices, which we would rather avoid, both for version number, and logistical reasons. The solution that we came up with was to see if TinyCLR could simply accept any certificate given to it and then it could receive update data over the HTTPS connection. We understand that security would be a concern here, but this is the path forward that my superiors have decided on. Please let me know if such a thing is possible so that I can either make the necessary changes in order to enable this behavior, or report back to my manager that it is not possible.
Makes sense. We will look to see if this is possibly next week.
Gus,
I appreciate it, thank you very much!
I think it is possible to add an “ignore certificate validation” option, but the security level will not be as high as it should be.
However, this would require changes in the next firmware release. There is no such option in the current release.
I am aware that the security level will be lowered, however it would be enormously helpful to me if you could add an option for it in the next firmware release!
Also, if you could either post on this thread or message me on my profile with the release version number when it comes out it would be a great help, as it will help me resolve this issue for my company as soon as possible, thanks!
Version 3.0.0.3000 has been released.
There are no firmware changes. The only update is in the GHIElectronics.TinyCLR.Networking.Http NuGet package but recommend to update all libraries and extension to 3.0.0.3000
Here is the test code we used (tested with https://google.com ). Please give it a try and let us know if it works.
// ----- Case 2: no root CA, accept any certificate (THE FIX) -----
// Uses the new HttpWebRequest.SslVerification property. Until the
// Networking.Http NuGet is rebuilt with the managed fix and refreshed in
// packages\, the marked line won't compile, so it's commented out — and
// Case 2 then fails exactly like Case 1. After the fix + repack, uncomment
// the line and this request succeeds with NO root CA (like curl -k).
Console.WriteLine("");
Console.WriteLine("--- Case 2: no root CA + SslVerification.None (expect SUCCESS after the fix) ---");
try {
var req = (HttpWebRequest)WebRequest.Create(URL);
req.Method = "GET";
req.Timeout = 15000;
req.ReadWriteTimeout = 15000;
req.KeepAlive = false;
req.UserAgent = "TinyCLR-TestSSL/1.0";
// >>> AFTER THE MANAGED FIX + Networking.Http REPACK, UNCOMMENT: <<<
req.SslVerification = SslVerification.None; /// GHI add to ignore certificate validation.
using (var resp = (HttpWebResponse)req.GetResponse()) {
Console.WriteLine(" SUCCESS: " + (int)resp.StatusCode + " — certificate accepted with NO root CA");
var body = ReadBodyText(resp, 256);
Console.WriteLine(" Body[0..120]: " + (body.Length > 120 ? body.Substring(0, 120) : body));
}
}
catch (Exception ex) {
Console.WriteLine(" FAILED: " + ex.GetType().Name + ": " + ex.Message);
Console.WriteLine(" (Expected until the SslVerification line is uncommented and the");
Console.WriteLine(" Networking.Http NuGet is rebuilt with the fix + refreshed in packages\\.)");
}
2 Likes
Perfect, thank you so much, I’ll try it out soon and let you know how it goes!
1 Like
I have attempted to update the project from firmware version 2.2.1.2000 to 3.0.0.2000, which appears to be the latest SITCore SC20xxx firmware version available on Downloads | GHI Electronics and after following the instructions here Migrating from v2 | GHI Electronics and referencing all the 3.0.0.3000 versions of all the NuGets that I referenced in my old project, the project builds without issue, however, I am running into the following error when attempting to deploy:
Generating device specific assemblies.
Failed to generate device specific assemblies:
file location/CommandParser.cs(43,9,43,10): error MMP0000: Cannot parse method signature ‘ProcessUpdateCommand’
MMP: error MMP0000: 0x81010009
The above function was working fine on my project on the old firmware and NuGet versions. I dug into the error code and here .NET Micro Framework it outlines the following:
0x81010009 CLR_E_PARSER_UNSUPPORTED_GENERICS
- Generics are not supported in .NET Micro Framework. Check System.Collections namespace for non-generic collections available.
- CLR\Tools\Parser\AssemblyParser.cpp
Please let me know if you have any insight into what is going wrong here.
What steps did you follow?
Sounds like you are not fully V3.
@Mike If you are referring to which steps I used to migrate from SITCore v2.x.x.xxxx to v3.x.x.xxxx, I followed the steps here Migrating from v2 | GHI Electronics which point out that the project structure is different between SITCore v2 and v3 projects, so you need to create an entirely new project then one by one add your .cs files into the projects manually in order to ensure that the project structure is correct for v3 projects.
You did update the firmware on your board?
Yes, however that shouldn’t matter since it is failing when generating the assemblies anyways, before it gets to the point of detecting the firmware on the board.
What happens if you create a simple hello world project?
Additional information:
The function that was causing the error was the following:
private static string ProcessUpdateCommand (string subData)
{
try
{
...
}
catch(Exception ex)
{
...
}
}
however if I remove the try catch then that function no longer causes the error, instead a different function with a try catch like above now causes the same error to show.
Also, I have now confirmed that my code does not include any generics and I am only using TinyCLR libraries in case that helps.
@Mike A simple hello world project works, but if I add certain functions from my desired project to it then it throws the same errors.
We will give it a try but if you can please provide us with a complete simple project that shows the issue.
1 Like
Could you please clarify what you mean by “remove the try…catch”? Do you mean removing only the try...catch statement, or also removing the code inside the try block?
Could you also send me the .csproj file, or the complete private static string ProcessUpdateCommand(string subData) method?
You can send it to me by clicking on Message .
