@krambriw
Walter, do you have a view on this?
Nowadays, not even that more setting up. Unless you would like a shiny A+ rating to show up on ssllabs, which takes a bit more effort in configuration. But setting up LE is hardly more work than calling OpenSSL yourself to generate a certificate and deploy that one instead. Especially once you have certbot running adding more domains is a piece of cake, and renewing just an extra line in cron below your previous certificate.
2 Likes
Dear Paul, not really anything to add. I have had my vpn running on a Pi for years now with self signed certs. If I would redo it again today, I would maybe do it a bit differently, using pivpn and also use Let's Encrypt
Here are some guides I would look into (the third in German, it describes a smart solution how you can automate the certificate renewals)
https://chasingtech.net/wp/2017/01/03/pivpn-create-your-own-vpn-for-your-home-network/
1 Like
The built-in Let's Encrypt renewal script works just fine. I'm using it and have done now for probably a year or so.
1 Like
https://www.sparklabs.com/forum/viewtopic.php?t=2453
Just this statement makes me a bit worried:
Using a Let's Encrypt certificate, or any public certificate authority issued SSL certificate, is insecure by default.
Like many others I presume, I run the openvpn server on a RPi3 with self signed certificates. In the discussion thread in the link above, it is stated that it is unsecure to to use Let's Encrypt certificates in combo with openvpn, instead self created are encouraged!
Could someone kindly sort things out for us? What to do and how to? Provided running the openvpn as your vpn server. Is there a risk using Let's Encrypt certs in such combo?
I think this would be extremely useful for all our NR users to know, wanting access to NR from outside their home network. Especially now when it has been made so much easier to install and setup a vpn server (PiVPN installer)
Certificates only provide assurance. If a client doesn't validate the whole certificate chain, by definition it is insecure.
So a self-signed certificate can be a lot more secure than one that is signed by a "trusted" public root certificate(1). But only if you take the time to generate and manage your certificate chains and keys very carefully. And only if you provide your own root certificate to the clients so that they can validate the certificate chain. Consider a root certificate and its private key as the "keys to the kingdom". Mismanage that and every certificate and key that you've generated from it is insecure and ones that an attacker may have generated from it may also be in your network.
If you've spotted a load of if's and but's in there then 10/10. Certificate-based security is HARD to get right, even harder to KEEP secure. And very EASY to screw-up.
The most important point here though is whether this makes any material difference in your case? And I would say that it does simply because you have put your security endpoint on a VPS. Is it enough of an issue to worry about? Well, that depends on what your home network has access to, what you are controlling, what could a botnet make use of? Only you can answer that.
The advantage of using Let's Encrypt (apart from it being free) is its short lifetime. This limits exposure by requiring an attacker to regularly have to grab your new cert/keys.
In your case, I would estimate that an LE cert would be marginally more secure than something you create yourself (assuming the clients are all validating them) but it does require you to have one or more public domains to register against. Though I doubt it will make much actual difference to you.
(1) The big problem with public certificate authorities is that there are too many of them and it is hard to prevent root CA's signing inappropriate certificates - for example some foreign government creating "Google" certs. Because trusted root certs mean that browsers and other clients automatically trust a cert signed by one, that can introduce massive vulnerabilities. For example, there are Arabic countries (they are not alone) that have managed to get trusted root certs created by government sponsored organisations which lets them stage man-in-the-middle attacks at a nation level.
3 Likes
I've updated my original post for installing/configuring on the Oracle Cloud to mention securing with username/password as well as posted a link to a new post that shows how to set up CertBot with Let's Encrypt to generate a valid cert. Thanks for the feedback. Let me know if you do try out the always free VM on Oracle Cloud and have any other feedback or questions.
Original Post (now updated):
New Post:
2 Likes
Great! Nice write up Todd @recursivecodes
I've just purchased a .tech domain name from namecheap.com (£1.60p for 12 months!) to fully evaluate the Oracle VM hosting, but I'm away from home till next week, so haven't got SSH access until then....
Just one observation on the tutorial; in the section 'Creating a certificate' you copy the new certificates to /home/opc/.node-red/certs/ and then create a script to automatically move renewed certs to the same folder.
But, in 'Deploying a site with your new certificate' the path that you have included in node-RED settings is /etc/letsencrypt/live instead of /home/opc/.node-red/certs/
(or simply ('certs/cert.pem'), should also work?)
Ahh, that's definitely a typo on my behalf. It won't work if you point to the LE directory (permissions). Thanks, I'll update the post!
1 Like
Hi Todd @recursivecodes
I think there's a small typo in the latest tutorial, should sudo firewall-cmd —reload be sudo firewall-cmd —-reload
otherwise it errors firewall-cmd: error: unrecognized arguments: -reload
Also, I'm having problems copying the certificates to .node-red/certs.
If I run cp /etc/letsencrypt/live/mydomain.co.uk/*.pem /home/opc/.node-red/certs/
I get cp: cannot stat ‘/etc/letsencrypt/live/myserver.co.uk/*.pem’: Permission denied
adding sudo, I get cp: cannot stat ‘/etc/letsencrypt/live/myserver.co.uk/*.pem’: No such file or directory
If I check ownership;
sudo ls -la /etc/letsencrypt/live/myserver.co.uk/`
total 4
drwxr-xr-x. 2 root root 93 Oct 29 21:11 .
drwx------. 3 root root 52 Oct 29 21:11 ..
lrwxrwxrwx. 1 root root 48 Oct 29 21:11 cert.pem -> ../../archive/myserver.co.uk/cert1.pem
(Plus the other 3 certs)
Doing the same with the symlink locations;
sudo ls -la /etc/letsencrypt/archive/myserver.co.uk/cert1.pem
I get;
-rw-r--r--. 1 root root 1935 Oct 29 21:11 /etc/letsencrypt/archive/myserver.co.uk/cert1.pem
I eventually got there!!
Before the command in the guide cp /etc/letsencrypt/live/node-red.toddrsharp.com/*.pem /home/opc/.node-red/certs/ it's necessary to change to 'root' privileges by entering sudo su, then everything thereafter runs smoothly.
Prefacing 'sudo' to the command instead, does not work, and results in error messages.
Also, in the section;
domain=[your domain name]
node_dir=/path/to/cert/copy/dir
node_user=opc
is
domain=your_domain_name
node_dir=/path/to/cert/copy/dir
node_user=opc
(no square brackets!)
Got mine going as well thanks to the @recursivecodes instructions
Wish I'd read @Paul-Reed notes before I did but worked out the --reload and the sudo for the certs myself 
One question though - do we not have to alter
node_dir=/path/to/cert/copy/dir
to be
node_dir=/home/opc/.node-red/certs
???
1 Like
Yes, that's correct.
I've just created a TIG Stack (Telegraf, Influx & Grafana) in my second 'free' instance which is working really well, and have used the same shell script to copy the certs, and change their ownership.
#!/bin/bash
domain=dashboard.digitalnut.co.uk
node_dir=/etc/grafana/certs
node_user=grafana
cp /etc/letsencrypt/live/$domain/*.pem "$node_dir"/
chown $node_user "$node_dir"/*.pem
Once you get it all running smoothly, you can create & store a backup within Oracle of your instance, which can then be used to restore the image, should things go badly wrong 
In the 'free' version, you can store up to 5 backups (per each 'free' account - or more if you sign up to a paid plan).
As they are full backups (instead of incremental), it's quite adequate, as you can delete off the oldest and stay within the 5 limit.
It can run the backup with the instance running, but I prefer to stop the instance first, do the backup, then restart.
1 Like
@cymplecy Do you have any issues logging into the Oracle Cloud admin interface?
Oracle seem to have invoked some security measures which make life difficult.
Most times that I login, I have to reset my password first and then login by following the email links, which is far from ideal.
Once its auto-logged me out after period on inactivty - I've never been able to make it back in from the page it sends me to.
I just go back to
and I can get in from there every time with no bother
That's a different url than I've been using, thanks Simon.
....Oracle is such a vast provider of so many products, and many interconnect, so maybe I was choosing the wrong route.
1 Like
@cymplecy Simon, are you using Todd's cloud backup script?
I've just got it working in the Oracle Linux environment (it didn't work 'out-of-the-box' for me...).
If you decide to give it a try, give me a shout & I'll share the changes that I've made.
1 Like
Not using it - I'm not running anything critical yet
Well before I forget...
The oracle compartment id is a required parameter of the command bv boot-volume-backup list (line 11 of the script), and without it, the script fails, so the solution is to add it into the script.
First grab the compartment id by scrolling to the bottom of your Oracle instance management page, and select Administration > Tenancy Details
Show & copy your Tenancy OCID
Then edit the script to include the OCID, and add it as parameter to the bv boot-volume-backup list command. (2 changes).
#!/usr/bin/env bash
source ~/.bashrc
PROFILE_NAME=DEFAULT
BACKUP_NAME=grafana_monthly
TMP_BACKUP_NAME=$(date +%Y-%m-%d_%H-%M-%S)
COMP_OCID=ocid1.tenancy.oc1..aaaaaaaaot2dmwrtkyourownocidreferencepczfgitlq
echo "Running at ${TMP_BACKUP_NAME}."
echo "Getting previous backup..."
OUTPUT=$(oci bv boot-volume-backup list --compartment-id ${COMP_OCID} --display-name ${BACKUP_NAME} --lifecycle-state A$LAST_BACKUP_ID=$(echo $OUTPUT | /bin/jq -r '.id')
BOOT_VOLUME_ID=$(echo $OUTPUT | /bin/jq -r '.bootVolumeId')
etc, etc, etc
The script should now run ok, and can be automated by adding a cron task which is run by 'user' to /etc/crontab. ie;
0 4 * * 7 opc /home/opc/backup_script/./nodered_weekly.sh >/dev/null 2>&1
NOTE; I have read that there is a way to make it unnecessary to provide the compartment id, but I couldn't get it to work, and the script author has not replied to support requests.
