I would like to have my Google Home Mini interact with my Home Assistant setup on my diet pi on a raspberry pi 3b. In order to achieve that, https with letsencrypt needs to be enabled.
I took a clean image of dietpi, installed home assistant and certbot from the optimized software. Afterwards, I run dietpi-letsencypt. However, after the first window asking for domain, email, etc… when I press on “Apply”, I get the following error:
[FAILURE] No compatible and/or active webserver was found. Aborting...
Do you know how to fix this? I was hoping to use the nice tool provided by dietpi to install letsencrypt but for the moment I have not had any luck.
dietpi-letsencrypt uses the CertBot install to apply SSL certificates to one of the available webservers (Apache2, Nginx and Lighttpd), the Minio S3 object server and coturn TURN server, e.g. if Nextcloud Talk WebRTC chat is installed. But it does not apply certificates to other web applications that run on their own standalone webserver, which is the case for Home Assistant.
To apply HTTPS there, you need to run the CertBot binary manually, using it’s internal standalone webserver:
To apply HTTPS + the LetsEncrypt certificates, you need to add them to the Home Assistant config file: /mnt/dietpi_userdata/homeassistant/configuration.yaml
Read: https://www.home-assistant.io/components/http/
In the file on fresh install you will fine the following commented lines:
# http:
# base_url: example.duckdns.org:8123
Uncomment them, add https:// and your domain + port as base_url.
Add the two other settings (see link above), linking to your certificate and key files, which are placed in /etc/letsencrypt/live/<your.domain.org>/
My plan for dietpi-letsencrypt future is indeed to allow applying the HTTPS certificates for more web applications. It would on initial run just retrieve the certificate and then allow via separate list menu, based on installed software, to enable/disable HTTPS with those certificate files for each individual web application/server. For this it helps to have the required steps for each documented and tested somewhere.
The tutorial worked great but there are some very small mistakes and I would also like to add more info for other users.
First I opened port 80 and 443 on my router pointing to my raspberry pi.
I run the cerbot command as MichaIng wrote.
This is how the configuration.yaml should be modified:
# Uncomment this if you are using SSL/TLS, running in Docker container, etc.
http:
base_url: https://xxx.duckdns.org:8123
ssl_certificate: /etc/letsencrypt/live/xxx.duckdns.org/fullchain.pem
ssl_key: /etc/letsencrypt/live/xxx.duckdns.org/privkey.pem
(MichanIng: you forgot the “:” affter the ssl_ and the certificate should be “fullchain.pem”)
Then it is very important to change permissions to the cert files otherwise when you check the config with home assistant you always receive an error:
sudo chmod -R 777 /etc/letsencrypt
Finally on your router change that port 443 points to 8123 on the raspberry pi local ip.
Check the config and apply modifications on home assistant. After restarting, connect to https://xxx.duckdns.org (no “:8123” in the end!)
Thank you very much MichaIng. You are always great. Marked the the topic as SOLVED.
You are on a Stratch system, right?
In this case there is already a systemd timer in place that checks for required cert renewal two times a day.
Check /var/log/letsencrypt/ for related log entries (it is very verbose).
Thanks for correcting my syntax above. Ah okay the fullchain is used by HA, some use this, some use cert only.
I will correct my commands above as well.
And jep I forgot the permissions that are required. But note that chmod -R 777 /etc/letsencrypt from security point of view is veeeeery bad! Every user has full R/W access to your very private SSL key now, can manipulate or steal it, which renders the whole “you-are-really-you” check of SSL useless. And even worse, since browsers/clients still think that it’s a secure connection, that gives wrong impression to everyone who users the web application, feeling secure but actually could have been easily tricked. Then better disable SSL, so every knows that it is not encrypted and no identity validation is done.
I know most likely it’s only yourself using HA here, but I am a bid drastic above to make the point clear and prevent everyone from learning bad habits.
Re-assures that key+cert is only/fully owned by root.
Grant only read (and execute to read directory content) access to the root group.
Adds the homeassistant user to the root group to grant him cert+key read access.
However adding a user to the root group is as well not ideal. Better again is to create a new group for this, e.g. named ssl and then add all users that require SSL read access to this new group instead.
The most secure way is to create a copy of the privkey+fullchain and chown homeassistant:homeassistant those. But this practically a bid annoying, since you need to redo this after every certificate renewal. At best a systemd unit timer hook would do that.
Yes, I am still on a stratch system. Have not been having time to play with beta version of DietPi yet if that is what you mean
I can see this on my installation:
root@transmission:~# ls -a /var/log/letsencrypt/
. letsencrypt.log .letsencrypt.log.1.swp .letsencrypt.log.2.swp
.. letsencrypt.log.1 letsencrypt.log.2
root@transmission:~#
However, when I try to open the not hidden files with nano, they are empty. So you say I do not have to worry to renew the cert files because DietPi will do that automatically, right?
Jep, the multiple log files show that certbot is doing the renewal check already. It is not DietPi, but the Debian repo certbot package, that implements the systemd unit for renewal .
And jep the files are most likely empty because you use DietPi-RAMlog. Hmm I think the cleaner should remove all but letsencrypt.log or we should set max-log-backups = 0 in /etc/letsencrypt/cli.ini to prevent a new log file two times a day.
Hmm do you use vim/vi to watch the files? ..swp usually are temporary vi/vim files that should be removed after closing the editor. So they should only remain, if the editor or system crashed .
I use nano but I also opened them on windows->winscp->local editor. I do not know which one caused the issue. Is it safe to remove the hidden files .letsencrypt.log.1.swp and .letsencrypt.log.2.swp?
Anyone still having trouble with this?
HTTPS is not working for me locally or externally but HTTP is locally.
The setting in HomeAssistant is set to the duckdns and HA says external access is enabled.
I feel like I missed a step but I did check over this thread a few times.
.
.