So info re. securing my stuff

Continuing the discussion from Persist strategy "everyChange" incl. the last known value before change:

Re. security: I do not run only openHAB on my head-less RPi B but also other stuff. Having nginx in place is usefull - for some apps as a reverse proxy, for the other as a web-server. I can access the services through multiple subdomains directed to a single IP address.

Originally, I had a chroot for each service, later on I played a bit with docker, but then decided to have it all in a single environment. Easier to update and backup, less space occupied, no need to remember the extra stuff I do not use otherwise. A bit weaker from security stand point, so I at least update regularly (Arch Linux).

There is a lot of info re. security hardening on the internet for each service, so I do not do anything special.
My approach is close as many ports possible, allow only LAN clients, manage entry point (Mikrotik: NAT and FW rules), force SSL, and run the services under unprivileged user. Even that OpenVPN runs on RPi too, I do not use it much, because it is inconvenient for mobile devices.

Let’s Encrypt does what it promises: it is fully automatic and also supports multiple domains in a single certificate.
I used to use StartCom Ltd. for free certificates, but that required a manual action once a year, which meant: read, learn, create new certificates and forget again over time :disappointed:.
Self signed certificates are also troublesome, since they trigger warnings in many remote clients or cannot be even used.

I use the “webroot” plugin and letsencrypt does not touch my nginx configuration at all. There is a nice guide for openHAB.

Although I do put my certificate into java keystore used by openHAB’s web server, it is actually more transparent for me to use nginx’s reverse proxy with forced SSL for https.

Later on, I want to look at

  • securing the MQTT messaging (from sensors to openHAB), although I am not sure if the clients on ESP8266, Arduino and alike support SSL.

  • running openHAB as a user w/o privileges and login shell (the packager for Arch Linux AUR repository lets it run with root privileges…).

  • creating users & passwords for external access

Given that Apache supports reverse proxy and such I was just curious if there was some reason (familiarity, security, ease of configuration, etc) that you chose nginx over Apache or other similar options.

Do you know if letsencrypt works with dyn dns type domains? I spent a lot of time playing with self signed certs awhile back (I wanted to limit communication to only those clients that had a known cert) but I could never get one of our phones to load the cert :-|. We have new phones now so I was considering going back and playing.

Have you looked into segregating your HA network from your user network? I know that is an approach some have taken.

Familiarity. I have already been using it in chroot for other stuff. It could have been Apache, too.

It surely should. The only “requirement” is that letsencrypt web (the issuer) is able to access certain file on domain, for which the certificate is to be issued. I.e. that it can verify that you can manage the server on the domain.

I do not have experience with client-side certificate authentication. It is possible that many phone OS’s refuse self-signed certificates.

A possibility could be to setup own certificate authority and have its root certificate imported into the phone (Android may be capable of that). Then, any client certificate issued/signed by your CA should be accepted.

I do not think Let’s Encrypt fits this use case.

The problem wasn’t that I was not allowed to do it. It simply would pretend to import it but not actually import it. I think it was a bug in the OS or something. I eventually gave up and pursued other approaches (VPN, standard username and password, my.oipenhab, etc).

Agreed, I didn’t mean to imply that I thought it would.

I’m glad it works so easily. I suppose my only long term fear is that a bunch of bad actors start using letsencrypt and the browsers and devices stop trusting them as a CA. I know a lot of bad actors have already been reported using it.