For SSL certificates - alternative to copying certificates

[borpin]

Continuing the discussion from Node-RED SSL using Letsencrypt & Certbot:

@Paul-Reed I have just setup an SSL certificate with certbot but then simply created a symbolic link to the live domain certificates (rather than copy them). They are globally readable.

Thinking about it (as I write this), could the settings file not just get the certificate files from the live folder?

The deploy script was largely to restart Node-Red which is now not required.

[Paul-Reed]

@borpin

...just get the certificate files from the live folder?

I haven't looked at this for a while, but I seem to recall that the file ownership would not be correct, and could not be read and used by node-RED, that's why they are changed in the script (as the certificates were moved).
Changing the owner in the original location seemed to upset certbot

I'll check tonight, and also have a look at your other point later Brian, when I can get to a laptop.

[Paul-Reed]

Hi Brian, just re-read the thread Node-RED SSL using Letsencrypt & Certbot where I wrote some time ago about the ownership issue that I had problems with, and the reason why I used the script. but if creating symlinks to the certificates in the 'live' folder works, then great.
PS remember that the 'certificates' in the 'live' folder are actually symlinks to the actual certificates which are stored in the 'archive' folder

Node-RED SSL using Letsencrypt & Certbot

Node-RED normally runs as a 'user', and Letsencrypt creates the certificates in etc/letsencrypt/live/ with root ownership, and therefore without changing the ownership of the certificates to pi, node_RED would not be able to read them. So... rather than start altering files that sit within the Letsencrypt directory, I prefer to copy the certificates to the node-RED user directory and then use chown to make them readable (it's all done by the script). That then keeps the two services independe…

@borpin

The deploy script was largely to restart Node-Red which is now not required

Yes, I mentioned about node-RED no longer needing a restart in the same thread.

@Paul-Reed

cp /etc/letsencrypt/live/$domain/*.pem "$node_dir"/
chown $node_user "$node_dir"/*.pem
node-red-restart      # Restart node-RED

EDIT: Since node-RED v1.1, it is unnecessary to include the last line in the script (node-red-restart) because the certificates can be re-loaded as a node-RED core function, without restarting. See this post for more details.

I'll edit the post and remove the reference to node-red-restart now that most people are using node-RED v1.1.0 or newer, but keep the script, and at least users will have the option to use it, use symlinks, or whatever.

[borpin]

@Paul-Reed

where I wrote some time ago about the ownership issue that I had problems with, and the reason why I used the script. but if creating symlinks to the certificates in the 'live' folder works, then great.
PS remember that the 'certificates' in the 'live' folder are actually symlinks to the actual certificates which are stored in the 'archive' folder

Yes, I noted that. I did though wonder if something had changed since then. I looked on 2 different systems and the certificates should be readable globally.

Yes, I appreciate the live is just a symlink created by the certbot renewal. Note I create a link to the folder not the files. The system in use is a little 'quirky' so I cannot test if it works for a 'normal' Pi setup.

[Paul-Reed]

@borpin

Note I create a link to the folder not the files

In the settings? can you paste how you've done that, as I thought the https: function() required the links to certs not the folder?

[borpin]

Sorry, I meant the Symlink I created into the ~/.node-red folder was done as a folder symlink (rather than each file). That worked and I then tried picking up the files directly in settings.js, and that worked as well.