June 24, 2018 at 7:17 am #3897
I’ve been trying for the past 2 days to get HTTPS working with Rapid SCADA on a Linux machine. I’m using Apache and the “scada_5.5.2_mono_en” package on Debian 9.3.
I’ve read the other forum posts about this, but those solutions haven’t worked for me. Here are the things I’ve tried so far:
– Editing the (2) web.config files included in the “scada_5.5.2_mono_en” package, un-commenting the parts with HTTPS code
– Editing the (4) web.config files in the source code (also un-commenting the parts with HTTPS code), compiling the DLLs from source on Windows, and transferring them over to Linux
– Running a reverse HTTPS proxy on Apache to route HTTPS traffic to Rapid SCADA on plain HTTP internally
– Telling Apache to listen on alternative ports (such as 8080), just in case there is a privilege issue for ports below 1024
– Reinstalling Rapid SCADA from scratch
Each time, accessing the web interface over plain HTTP works fine, but when I use HTTPS, I get this error:
Rapid SCADA Application Error An application error occurred. If it repeats often, please contact the support. Details: Could not find base address that matches Scheme http for endpoint WebHttpBinding
All I need is for someone to point me in the right direction so I can fix this myself (and I will post the solution here). Any help would be greatly appreciated!June 24, 2018 at 2:10 pm #3901
Try these config files. They work for enabling HTTPS on Windows, you can help to test them on Linux.
If it doesn’t help, you can try deleting the folder ScadaWeb/plugins/Scheme for testing purposes. This is the Schemes plugin that caused the above error.June 25, 2018 at 5:30 am #3903
Unfortunately, neither of these solutions seem to have worked. I’m still getting the same error even with the new config files and the ScadaWeb/plugins/Scheme folder deleted.
Here’s something interesting. When I access the site over HTTP, the error says “Could not find base address that matches Scheme https for endpoint WebHttpBinding,” but when I access the site over HTTPS, the error says “Could not find base address that matches Scheme http for endpoint WebHttpBinding.” (Perhaps this is just because I deleted the ScadaWeb/plugins/Scheme folder, so now it can’t load either one.)
I’m not very familiar with the Microsoft frameworks that Rapid SCADA runs on, otherwise I would probably know where to look. Does this error come from the .NET subsystem, and can it be fixed by modifying the web.config file?
I really appreciate the effort you put into helping the community (are you the only one maintaining this project?) I’d be happy to contribute code back to the project to fix this issue (if something needs to be fixed); I just don’t know where the error originates.
June 25, 2018 at 4:21 pm #3907
- This reply was modified 11 months ago by hbwhite.
Does this error come from the .NET subsystem, and can it be fixed by modifying the web.config file?
Likely. On Linux we use Mono .NET Framework that is not fully compatible with original Microsoft .NET Framework. That’s why we get issues.
If you provide screenshots of the errors, it helps to generate ideas.
HTTPS in Linux is an important issue.
What is your version of Mono .NET framework?
Type the following command to check:
mono --versionJune 26, 2018 at 7:03 am #3914
My Mono version is 126.96.36.199. You can see the problem here (I’m using the default credentials while testing):
If this is offline when you visit it, I’m probably busy testing it with different web.config files.
It won’t be able to load the scheme or the table over HTTPS, but if you change it to plain HTTP, they will load fine. You can see the error above if you go to Google Chrome, right-click and select Inspect > Console while browsing the HTTPS version.
June 26, 2018 at 7:57 am #3916
- This reply was modified 10 months, 4 weeks ago by hbwhite.
The scheme and table will load over plain HTTP when using the default web.config files.
When I uncomment the HTTPS part of the web.config files, they won’t load on either HTTP or HTTPS (the same thing happens when I use the web.config files you provided).June 26, 2018 at 1:57 pm #3928
I opened your URL. I can say that all AJAX requests that are polled WCF web services cause Internal Server Error.
Where do you see the error like “Could not find base address that matches Scheme https for endpoint WebHttpBinding”?June 26, 2018 at 2:07 pm #3929
What if you comment all XML blocks related to HTTP?
Most likely, it’s enough to test with the main ScadaWeb/Web.config. Table view have to show current data if it works.
Remove httpGetEnabled at line 51
Comment the endpoint at lines 63-64June 26, 2018 at 2:26 pm #3932
On the next week, I can compare with my Linux machine.June 26, 2018 at 3:33 pm #3933
I already tried commenting out the plain HTTP parts. It threw an exception related to the XML when trying to load the Scheme.
You can see the error message I mentioned if you open the URLs that caused internal server errors manually.
I will keep trying different things and let you know if I get something to work. Thanks!June 27, 2018 at 5:54 pm #3935
Waiting for the news from you.
On the next week I will try on my Linux computer.June 28, 2018 at 7:01 am #3936
I had to get this project finished on time with SSL support, so I ended up writing my own SCADA system in Python over the past few days using pymodbus, OpenSSL, Flask, and Apache. It doesn’t have as many features as Rapid SCADA, but it meets my requirements and runs “natively” on Linux. It actually wasn’t as difficult as I expected it to be! 🙂
If I was using a Windows computer, Rapid SCADA would have been a better choice, but since I’m trying to run this on a Raspberry Pi, I needed something that could run on Linux with minimal CPU load (Mono used a lot of CPU cycles).
I’d still be happy to help test Rapid SCADA’s SSL support on Linux, if you want me to try some new web.config files.June 28, 2018 at 4:02 pm #3943
I’m going to continue work on this issue.
Thank you for help with testing.July 9, 2018 at 1:39 pm #3975
I’ve opened an issue on Mono https://github.com/mono/mono/issues/9458
Hope the Mono team will work on it.July 31, 2018 at 1:37 pm #4077
The workaround is creating Apache reverse proxy or use Nginx to tranfer HTTPS requests for existing HTTP web application. This is a good option.
You must be logged in to reply to this topic.