My Node-Red server needs to support both HTTP and HTTPS request at the same time. My HTTPS configuration with LE-signed certificates works great but then I get no response on HTTP. If I disable HTTPS I can access it over HTTP. I have been playing around with setting requireHttps to false in settings.js without any luck. The property name would indicate disabling HTTP when set to true. I don't see the point with requireHttps. What I am looking for is a property 'allowHTTP' when HTTPS is configured. A normal Web Server would has port 80 for HTTP and port 443 for HTTPS while Node-Red listens only to one (1880). Is there a way to get both HTTP and HTTPS working at the same time?
It is generally best and easiest to do this with a reverse proxy. My preferred tool is NGINX.
Using a reverse proxy lets you easily redirect http to https as well which is the preferred approach.
This approach also lets you easily use the standard ports and will internally forward traffic from the incoming ports - 80 lets say - to port 1880 internally.
Services like NGINX also have many years of battle hardened experience of handling TLS and get a LOT of attention and security reviews/updates. So it would not be unreasonable to expect them to be more secure and resilient.
2 Likes
Sorry, I did not mention that I have an instance using Apache proxy 443->1880 and 80->1880. I also have a docker instance with port-mapping 443:1880 and 80:1880. Node-Red will not respond to HTTP request if HTTPS is enable. This would be similar to http://my.node-server.com:1880 and https://my.node-server.com:1880. One question is if a server can manage both HTTP and HTTPS on a single port? If so, can it be done on Node-Red?
As these are entirely different protocols, they cannot be served using the same port.
When using Apache or nginx as reverse proxies, they can be configured to serve both http on port 80 and https on port 443, for example. Your Node-RED instance can be served on localhost using only http, so you won't even need both protocols on that side.
Ahh, thanks! I will try removing HTTPS on Node-RED while having HTTPS on Apache. This will solve my Apache proxy instance but not my docker. That is sufficient.
No. They must be on different ports.
Node-RED already contains two web apps that share a port but they both have to deliver either http or https. I'm sure someone more knowledgeable will correct me if I'm wrong.
What I would do is configure Apache to accept both but redirect http to https so that effectively only https is supported. I would then configure docker/NR to only accept one or the other on a single port. I would only use 1880 for docker so you don't have to change that in case you wanted to switch later. Personally, I would configure NR to use http only (the default) - unless you want to have docker on a different server to Apache. In that case, I would use https between Apache<->docker<->NR.
1 Like
Thank you for these pointers. I will try and see how it works out.
1 Like
My usual production setup at work is an Apache as reverse proxy, serving everything over https.
Node-RED is strictly bound to localhost and uses http only.
That spares you the hassle to configure that stuff in NodeJS. As Julian said, Apache (and nginx) are well-tested products.
That is right.
Personally I prefer NGINX simply because it is a heck of a lot more efficient, especially when working on restricted platforms like a Pi or a cheap VPS.
And, as I said, the choice of http/https internally would be dependent on the security of internal networking and the sensitivity of the systems/data.
Yes, you are right. Nginx is my preferred choice, too.
But I forgot to mention, that most of our production machines are running Windows, unfortunately. Mostly due to customer requirements. I found that Apache provides better support on Windows platforms than Nginx. (haven't tried for some time, that might have changed in the meantime)
Probably a different topic but... I am still a bit confused over the NR setting 'requireHttps=true/false' in settings.js. I have not found any good documentation. What is the actual purpose since enabling HTTPS will require HTTPS.
In some environments, Node-RED may be running behind a proxy that allows both HTTP and HTTPS traffic to reach it. If requireHttps is set to true, and Node-RED sees an inbound request is HTTP, it will respond with a redirect to the HTTPS equivalent url.
Note this is only the case if your proxy allows both types of traffic through. If you have full control of the proxy, you probably wouldn't do that. But some environments, such as cloud hosted platforms, don't give you that choice and automatically accept both.
Well despite what some people think of it, IIS is a viable alternative.
Personally, in production, I would prefer to use NGINX/Apache edge servers and keep node.js services on separate servers (possibly VMs). There is little doubt that on equivalent hardware, unless it is really well kitted out, NGINX is very likely to give you better throughput than Apache or IIS - last time I bothered to look it up anyway. A Linux edge server with a minimal Debian installation plus NGINX and suitable security services is actually pretty easy to support even in a predominantly Windows environment.
1 Like
Thanks. Now it makes sense.
Thanks for all the pointers, now it works like a charm. The reason for needing both HTTP and HTTPS is that I have a local client that couldn't make HTTPS request. With this last change I switched to use HTTP on local LAN as my risks are limited. The public side will require HTTPS. Additionally I added client certificate authentication in my Apache HTTPS proxy so I can remove the password authentication in NR (I only target trusted clients).
3 Likes
Unfortunately, personal preferences and customer "wishes" and restrictions don't got well together in most cases, at least for us. 
If it were up to me, I would use a Linux system for running our backend system (where Node-RED is a part of) all the time. Much less painful than the same setup on Windows.
Even MariaDB/MySQL performs a lot faster on Linux systems than on Windows.
As for throughput with NGINX and Apache, our software front-end is locally restricted to a very limited number of users. So this won't become an issue, fortunately.
1 Like
