URL problem with SSL certificate on CentOS7

General
1

Hello,

We've been working on data acquisition with Node-RED on this website : https://rucheconnectee.mc.
The GNU/Linux OS used is CentOS7.

I had a self-signed SSL certificate to encrypt the website, but I had security warnings on all the web browsers. I eventually got a SSL certificate from Let's Encrypt that listens to 443 port and works well.

On Google Chrome, Mozilla Firefox and Microsoft Edge, when I get to the page that embeds the Node-RED page, it doesn't display and the user needs to open the page in a new tab and to accept to surf on the website despite the security warning.

chrome_error_displaying_node_red
chrome_error_displaying_node_red2987Ă—1920 155 KB

In Chrome and Edge, a security warning remains on the URL bar. When I click on the warning, the web browser tells the SSL certificate is valid, but it's apparently self-signed.

chrome_rucheconnectee_certificat_ssl

I looked at the /home/user directory, in which I can find ca.crt, ca.csr and ca.key - strange for me! These are the names of the self-signed SSL certificate I had generated, but these files may be different, as the ones I had created are in another folder.

When I type the openssl command:

$ openssl s_client -showcerts -connect 80.94.97.61:1880

here's what I get:

CONNECTED(00000003)
depth=0 C = MC, ST = MONACO, L = Monaco, O = DENJS, OU = DENJS, CN = rucheconnectee.mc, emailAddress = fnguyen@gouv.mc
verify error:num=18:self signed certificate
verify return:1
depth=0 C = MC, ST = MONACO, L = Monaco, O = DENJS, OU = DENJS, CN = rucheconnectee.mc, emailAddress = fnguyen@gouv.mc
verify return:1

Certificate chain
0 s:/C=MC/ST=MONACO/L=Monaco/O=DENJS/OU=DENJS/CN=rucheconnectee.mc/emailAddress=fnguyen@gouv.mc
i:/C=MC/ST=MONACO/L=Monaco/O=DENJS/OU=DENJS/CN=rucheconnectee.mc/emailAddress=fnguyen@gouv.mc
-----BEGIN CERTIFICATE-----
XXX
-----END CERTIFICATE-----

Server certificate
subject=/C=MC/ST=MONACO/L=Monaco/O=DENJS/OU=DENJS/CN=rucheconnectee.mc/emailAddress=fnguyen@gouv.mc
issuer=/C=MC/ST=MONACO/L=Monaco/O=DENJS/OU=DENJS/CN=rucheconnectee.mc/emailAddress=fnguyen@gouv.mc

No client certificate CA names sent
Peer signing digest: SHA256
Server Temp Key: ECDH, P-256, 256 bits

SSL handshake has read 1606 bytes and written 415 bytes

New, TLSv1/SSLv3, Cipher is XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : XXXXXXXXXX
Session-ID: XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Session-ID-ctx:
Master-Key: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
XXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXX
Start Time: 1666684067
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)

So, Node-RED actually uses a self-signed SSL certiticate on my webserver.

Does anyone know where I can change the Node-RED certificate so that it uses the Let's Ecrypt one in CentOS7?

Thanks!

2

Sorry, didn't get to read all of your provided details but I can see that your embedded iframe on that page has an invalid certificate because you specified the page as an IP address instead of a name. Certificates are only valid for specified ip names/addresses.

image
image611Ă—653 24.7 KB

In fact, the TLS cert for the iframe is invalid anyway and appears to be a malformed self-signed cert. Not an LE cert. Though actually, this is slightly complicated by the fact that I have adguard turned on with certificate interception so I am not seeing the original.

Anyway, that is the issue. Don't mix ip names and addresses in web apps as it makes the browser think that they are separate domains. Even when you fix the wrong cert issue, you may still get browsers rejecting the iframe because of cross-domain restrictions.

3

Hello,

Thanks for your reply!

I tried what you proposed, changing the iframe URL from /80.94.97.61:1880/ui to rucheconnectee.mc:1880/ui.

When I save the webpage, the Node-RED iframe doesn't display. And when I click to open https://rucheconnectee.mc:1880/ui in a new tab, I get this message in Chrome and Edge :

edge_probleme_ssl_nom_de_domaine
edge_probleme_ssl_nom_de_domaine1262Ă—753 143 KB

What am I doing wrong?

4

You still haven't fixed the TLS cert that the frame is using. But at least you now see the error :wink:

5

Yep !
So does anyone know how to change the Node-RED SSL declaration on CentOS7?

6

Is Apache doing the HTTPS for the iframe or is Node-RED supposed to serve-up HTTPS? The former would be better 'cause it avoids the situation you're in, which is two certs locations to manage and two processes to restart when you update them.
If you really want to serve HTTPS from Node-RED then after configuring it in settings.js and double-checking the paths unless you post the section of the config there's not much anyone here can do...

1 Like
7

Hello!

Thanks for your reply.

I've found these two files:
• /home/udirsernum/.node-red/settings.js
• /usr/local/lib/node_modules/node-red-admin/settings.

and tried to update these lines:

/** The following property can be used to enable HTTPS
* This property can be either an object, containing both a (private) key
* and a (public) certificate, or a function that returns such an object.
* See HTTPS | Node.js v21.4.0 Documentation
* for details of its contents.
*/

/** Option 1: static object */
https: {
  key: require("fs").readFileSync('/etc/letsencrypt/live/rucheconnectee.mc/privkey.pem'),
  cert: require("fs").readFileSync('/etc/letsencrypt/live/rucheconnectee.mc/cert.pem')
},

/** Option 2: function that returns the HTTP configuration object */
// https: function() {
//     // This function should return the options object, or a Promise
//     // that resolves to the options object
//     return {
//         key: require("fs").readFileSync('privkey.pem'),
//         cert: require("fs").readFileSync('cert.pem')
//     }
// },

I restarted Node-RED - I think -, but the openssl shows it still uses the self-signed certificate.

Do I need to modify anything else?

8

You didn't answer the question. Do you already have a proxy set up to handle TLS termination for the outer page? If so, remove the entries in Node-RED and use the proxy to do all of the TLS.

1 Like
9

He has Apache on 443 and port 1880 goes straight to NR. Should set apache up as reverse-proxy for NR and then either use any port (could stay with 1880) or perhaps better map port 443 /ui to NR (but I don't know whether additional routes would be required).

1 Like
10

And replace Apache with something more efficient such as NGINX.

11

Hello!

Thanks for your reply.

There's no proxy set up for the TLS termination as far as I know. The TLS is done through Apache.

12

Hello!

Thanks for your reply, but I think this set up outranges my skills in server administration :frowning: !

13

Thanks for your suggestion!
Maybe I'll move from Apache to NGINX... when I know NGINX better!

14

That IS the proxy. :smiley: or at least it should be but it doesn't actually appear to be proxying node-red

I thought that the proxy might be handling one of the TLS sessions and node-red the other.

However, I've gone back to your site and I can see that you haven't done one of the things I said to do. Which is that your link to the iframe MUST use the same IP NAME as the top frame.

Currently:

An end user browser cannot connect to 80.94.97.61 so it fails to load. You also have a failing link to jquery in the top frame as well.

As always, use your browser's dev tools to analyse what is and isn't loading and any errors or misconfiguration.

Ideally, you would use Apache to proxy the node-red Dashboard so that it appears as the main domain, something like https://rucheconnectee.mc/dash or whatever you wanted. This will avoid cross-domain issues in the browser. You could then also let Apache handle the TLS connection and remove it from node-red. That would generally be more efficient and would keep it in 1 place.

15

Thanks for your detailed reply and for your advice!

As I wrote in this thread, I tried to use https://rucheconnectee.mc:1880 in the iframe but, in the iframe or in a new tab, Chrome/Edge didn't allow it to display :


I evenetually switched back to the IP address for the iframe to have Node-RED displayed.

I changed the SSL certificate filename in the Apache ssl.conf file for the rucheconnectee.mc website. I also tried to add the line about the 1880 port to the Apache ssl.conf file :

Whe we also provide SSL we have to listen to the
the HTTPS port in addition.

Listen 443 https
#Listen 1880 https

I restarted Apache after the addition of the port 1880 line, but I had errors. I finally commented that line to have Apache working proprely.

How can I add the 1880 port to be handled by Apache? Does the set up have to be done in this ssl.conf file?

16

I've not used Apache for years I'm afraid, so not sure I can be of much specific help. However, you need to configure it to be a reverse proxy for the part(s) of node-red you want to allow externally. Probably just the /ui part in your case. You will also need to proxy the websockets connection. I expect that a suitable config will be searchable on the internet.

17

Thanks for your reply!
But I think it really outranges my Apache skills!

18

Just a little friendly nudge then that you may want to rethink trying to put something onto the Internet - especially with it seeming to carry an official Monaco government logo.

As you have hopefully seen from another recent thread about hacked node-red servers, this is no joke. Exposing anything to the Internet takes care and attention.

19

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.