For the used SSL certificate to be valid, we need to use the externally visible hostname when accessing the RaspberryMatic GUI. Thus, we need to configure this external hostname as the server's hostname, even if the server is only available on our internal network.
Be careful when exposing your actual RaspberryMatic instance to the outside world without further safe-guards. Usually, it should only be accessible on the internal network.
Go to Einstellungen -> Systemsteuerung -> Netzwerkeinstellungen. There, you can create a self-signed certificate. Enter the hostname, your email address, and your country. The latter two values are rather unimportant here.
We need this certificate so that the web server is configured correctly and we have a template file which we can later overwrite with our actual SSL certificate from Let's Encrypt.
Go to Einstellungen -> Systemsteuerung -> Sicherheit. There, you can enable the SSH service and set a password for the root user.
Now, connect to the SSH-server as root with your chosen password.
We need to manually install acme.sh since the root filesystem of our RaspberryMatic installation is mounted readonly (only /usr/local is writable). We want to preserve this basic setup to still allow simple updates of RaspberryMatic.
mkdir /usr/local/.acme.sh
curl https://raw.githubusercontent.com/Neilpang/acme.sh/master/acme.sh > /usr/local/.acme.sh/acme.sh
chmod +x /usr/local/.acme.sh/acme.shNow we install the cronjob to automatically renew our certificates:
crontab -c /usr/local/crontabs -eAdd the following line:
0 0 * * * /usr/local/.acme.sh/acme.sh --cron --home /usr/local/.acme.sh > /dev/null
/usr/local/.acme.sh/acme.sh --issue -d MYHOSTNAME.EXAMPLE.COM --standalone --httpport 8000 --home /usr/local/.acme.sh --fullchain-file /etc/config/server.crt --key-file /etc/config/server.key --reloadcmd "cat /etc/config/server.key /etc/config/server.crt > /etc/config/server.pem && chmod 600 /etc/config/server.pem && /etc/init.d/S50lighttpd reload"Here, we use acme.sh's standalone mode to confirm the domain ownership which uses the builtin HTTP server of acme.sh on port 8000. For that to work, we need to:
- Add the hostname to the external DNS, e.g. as a CNAME to our router
- Configure the router to accept HTTP requests to the hostname (on port 80) and to forward them to port 8000 of our internal RaspberryMatic box. When using pfSense or OPNsense on the router, you could e.g. use the HAProxy package for that.
We leave this configuration as an exercise to the user.
If this is not possible, we could also use the DNS mode of acme.sh to avoid the HTTP negotiation (and accompanying setup of our router). For that, it is necessary that the external domain is hosted on one of the supported providers. See https://github.com/Neilpang/acme.sh/tree/master/dnsapi#how-to-use-dns-api for details on how to use this with acme.sh.
@jens-maus wrote:
It does not though. I suggest to forward HTTP requests to port 8000 (which is otherwise unused) in order to be able to confirm the ACME HTTP challenge. Here, we use the standalone server of acme.sh which is only active for a few seconds during the challenge. The rest of the time, nothing listens on this port which thus does not pose a security issue.
If you read the gist again, you will notice that I do not encourage anything like that. Specifically, please refer to the warning in the second paragraph of the gist which explicitly warns users from exposing their Homematic interface to the internet without further precautions.
In any case, the Homematic software (including RaspberryMatic) supports the setup and use of HTTPS with custom certificates out-of-the-box. The steps documented here (almost 7 years ago) just describe how to automate this existing functionality with Let's Encrypt. This should not change the existing security considerations of this feature at all.
While it's still certainly a good idea NOT to expose the Homematic interface to the entire internet, even with TLS certificates, I at least try to use TLS even in my local networks as much as possible. In today's times (which quickly moves towards HTTPS-by-default), I believe using plain HTTP or even self-signed certificates here rather HTTPS with certificates signed by a trusted CA would result in an overall less secure system.
Additionally, the local network is not an entirely safe haven anymore (?) given the increasing number of "smart" components people use there. Thus, it would certainly be a good idea to improve the security of Homematic / RaspberryMatic and to fix its security issues to improve the overall security.
As explained above, there are valid use-cases for TLS and trusted certificates and I do not share your concerns here. As I believe the approach shown here to be a net-improvement for security, I will continue to use it. I'm quite okay with us agreeing to disagree here though.
In any case, thanks for your work on RaspberryMatic over all those years!