Use the generated certificate also for Node-RED

[dcaccount]

Hello,

I have issued the certificate for my domain and everything is fine. In my Raspberry Pi4 they have been stored under: /etc/letsencrypt/live.

I would like to use the certificate also to secure the connection with Node-RED but Node-RED is running not as root and cannot have access to the path where the certificate is stored.

Is there a security risk if I allow a standard use to read access the certificates?

Is there another way to solve this issue?
Thanks,
Daniele

[rg305]

You could copy the certificate files to a location where the Node-RED user can read it.

You could even schedule that copy into the renewal process [with a --deploy-hook].

[webprofusion]

I'd also say that there's no reason a user (e.g. the service account for node red) shouldn't be allowed to read the certificate and private key if you set the permissions to allow it, you just have to ensure that only that user gets read permission and not all users.

[Osiris]

Another commonly used strategy is to place a "regular" webserver (e.g. Apache or nginx) in front of Node as a reverse proxy and let that do all the TLS stuff.

[dcaccount]

@webprofusion

I'd also say that there's no reason a user (e.g. the service account for node red) shouldn't be allowed to read the certificate and private key if you set the permissions to allow it, you just have to ensure that only that user gets read permission and not all users.

This is my concern, the user that runs the process will be allowed to read the private key, isn’t a security flaw or am I mistaking?

[dcaccount]

@Osiris

Another commonly used strategy is to place a "regular" webserver (e.g. Apache or nginx) in front of Node as a reverse proxy and let that do all the TLS stuff.

I have read and I like the idea but I have never setup a reverse proxy, is there a guide, tutorial that you would recommend me?

Thanks!

[Osiris]

@dcaccount

is there a guide, tutorial that you would recommend me?

Not really, it also totally depends on your requirements. Often people have a webserver running anyway, so it's easy to simply add a reverse proxy part to its existing configuration.

On the other hand, if you ONLY require Node without any additional webserver, you might choose a more "dedicated" reverse proxy software like HAProxy. That said, I searched for things like "memory footprint" to see if someone has made a list of reverse proxies with their resource usage, as you could imagine a full featured webserver might use more memory than a dedicated reverse proxy. But I'm simply not sure

[webprofusion]

@dcaccount

the user that runs the process will be allowed to read the private key

I'm assuming this "user" is not a real person who logs in, it's a service that's running, in which case that's perfectly normal. If it's an actual person that logs in then you could debate it.

The point of protecting a private key is that anyone who has it can decrypt the initial conversation between any other users to the same service. So it could be like you're protecting the crown jewels or it could like your protecting the coffee machine, depending on the context

[Osiris]

@webprofusion

I'm assuming this "user" is not a real person who logs in, it's a service that's running, in which case that's perfectly normal.

It's common for services requiring access to a private key to start with root permissions, read the private key into memory and afterwards drop permissions to some non-root user level which doesn't have access to the private key or any other sensitive data. This to prevent exploits in the server itself being used to access e.g. the private key.

[dcaccount]

@Osiris

@webprofusion

I'm assuming this "user" is not a real person who logs in, it's a service that's running, in which case that's perfectly normal.

It's common for services requiring access to a private key to start with root permissions, read the private key into memory and afterwards drop permissions to some non-root user level which doesn't have access to the private key or any other sensitive data. This to prevent exploits in the server itself being used to access e.g. the private key.

Thanks, clear.

Actually the service is Node-RED executed as standard user, at least it has been installed from a user "daniele" without sudo but "daniele" can log in, in fact "daniele" is my account and it belongs to sudoers.

So, if I want for Node-RED to access the private key, I need to allow user "daniele" to read it and this is my concern.

I am not an expert but I would not know how to make Node-RED to start with root permissions and then to drop root privileges after having read the private key.

Please advise if this is clear and your considerations.

Thanks,
Daniele

[webprofusion]

My suggestion for production services if to have a dedicated account that service will run as. Linux has some distinction between different account types, see https://www.makeuseof.com/types-of-user-accounts-on-linux/ (Service Accounts)

Personally I would consider it ok to then grant that service account read permissions on the certificate files (including the private key) because it's not an account normal users will login as. I actually don't think root should be used for anything app related (on linux), but that's my preference and certainly many production systems rely on root access somewhere.

There are no rules, there are only best practices for optimum security, but an important part of a best practice is that it should be practical and the relative importance of security (and usually therefore how much effort/complexity to add) depends on the environment you are working in. Some organizations have specific audited requirements for security and you would working within those.

For production systems it depends on the impact of your system being eventually compromised. If this is a development system or home hobby then how much you want to secure it depends on the impact to you if someone else gets access.