Behind Traefik proxy, cert shows valid but still insecure?

General
1

I have my node-red running in docker behind the Traefik proxy. Traefik terminates ssl at nodered.mydomain.com, and forwards the traffic to the 1880 port of the container.

In my browser, node-red loads normally but the page is "not secure" When I click the padlock though, it says the certificate is valid and issued to the correct domain.

Is there anything I need to do in node-red to have it accept the ssl connection properly?

thanks

2

For the browser to mark it as "secure", you have to have a verified "chain" of certificates - this is something that really annoys me about the way browsers currently handle this.

What this really means is that your certificate chain does not have a "trusted" root certificate. E.g. one signed by a 3rd-party that your browser (or the proxy?) recognises.

It is possible to fix that by loading a self-signed root certificate into the trusted root certificate store. But it isn't simple.

Got to go, I'll explain another way later when I get time if someone doesn't beat me to it. Using Let's Encrypt.

1 Like
3

hmmm. I fired up grafana, homeassistant, influx, and other similar services behind the same traefik instance. Each one gets a secure SSL in the browser at https://subdomain.mydomain.com.

Traefik reads the config of the container, you just put a label telling it what path to listen to, and it gets the SSL from lets encrypt automagically. It just works, ssl-terminated subdomains pop up in seconds. Except for node-red. It takes the request on port 80 of the subdomain, upgrades it to https and forwards it to the right container. Everything works, just shows insecure still (but with a valid cert?)

nodered:

image

grafana:

image

The whole cert path appears to be present, if I look up the path in the browser it shows the DTS Root CA X3, then the Lets Encrypt Authority, then the cert

In Home-Assistant, you have to put some extra lines in the config for it to play nicely with an ssl termination proxy, like this:

# Uncomment this if you are using SSL/TLS, running in Docker container, etc.
http:
  base_url: https://homeassistant.mydomain.com
  use_x_forwarded_for: true
  trusted_proxies: 127.0.0.1

I'm just wondering if there are environment variables or anything I need to do to node-red to have it behave like the other services?

4

OK, so you've already got a properly external certified cert then. Let me check my own config in Node-RED ....

... right, so here are my settings:

	https: {
        key: fs.readFileSync( path.join('..','.acme.sh','DOMAINNAME', 'DOMAINNAME.key') ),
        cert: fs.readFileSync( path.join('..','.acme.sh','DOMAINNAME', 'fullchain.cer') ),
        // rejectUnauthorized: true // require client cert to be valid and known
    },

    // The following property can be used to cause insecure HTTP connections to
    // be redirected to HTTPS.
    requireHttps: true,

You will note that the cert setting refers to the fullchain.cer file and not to the servers cert. It may be that you have the wrong cert file specified. The fullchain file contains the full chain of certs back to the trusted root.

5

I'm sorry for some reason I have a hard time grasping certs and ssl.

I guess what I'm not understanding is why are all these other apps working the way I intended but node-red is not? Is it something I'm doing uniquely or something node-red is?

6

Without seeing all of the details for each, I couldn't comment I'm afraid.

The issue with certificate based security has always been that it is very fragile. When working and configured exactly right, it is very secure indeed. But it is far too easy to get one little thing wrong and it all breaks down.

All I can say is that the configuration I shared with you works, I have 2 systems similarly configured and they both work thanks to the wonderful wildcard certificates from Let's Encrypt. Though I had to wrangle my local router to allow the local DNS to serve the domain I'm using instead of just IP Addresses.

I can also say that you get 2 certificate files. One only has the server certificate in it. The other, the one you need to use, has the full chain of certificates back to the trusted route.