Hey everyone. Just switched over to Hass.io from hassbian and had some thoughts on the Let’s Encrypt Addon, which seems to work very well in most cases but will not work for me without reconfiguring my router every few months.
As described in this section of the home assistant documentation, some users run into the problem of port 80 being unusable for certbot certificate issuing and renewal (for various reasons, most commonly ISP restrictions?). Since the user is likely forwarding port 8123 on the HassIO machine to port 443 externally for https access (the whole purpose of this in the first place), it’s now impossible to run certbot with either 80 or the blocked port 443 without reconfiguring the port mapping, as was originally described in that documentation. I submitted a (now merged) pull request to that documentation to suggest a workaround using certbot’s pre-hook and post-hook flags to temporarily shut down home assistant, allowing certbot to do its thing without having to change port mappings every time.
Now, with the Let’s Encrypt Addon in HassIO, this is again a problem. So I had a few thoughts:
After looking a the source, it seems like the Let’s Encrypt add on could expose a configuration option for the user to “opt-in” to this functionality, and that these certbot flags could be added on easily. But the problem is that I’m not sure how to stop and start homeassistant from a hassio add on. I can see that there is restart functionality exposed in the HassIO server API, but what about just start and stop?
Out of curiosity, is this a problem that many people run into? It seems like it was significant enough to be mentioned in previous documentation, but I never hear much about it.
I’d be happy to work on something like this myself, and was about to start when I remembered the command line options with HassIO are more limited. Just looking for some guidance on this from smarter/more experienced people to see if it’s possible.
Hass.io is desined to run home-assistant with a minimun downtime. Also on a update go home-assistant only for ~30sec down for the restart. That is the reason why you only have a restart function on API itself.
Home-Assistant run on port 8123 and that should not be changed on config, since other things that can based on it look also default to this port. The old way to map the port internal and external (like 443 -> 8123) will be a current method but with IPv6 and other movements it make troubles. I don’t prefere this. For my personal, I use also 8123 external for access to home-assistant. But yes, some user don’t want do that and for that we have a core add-on “nginx proxy”. That proxy all reqeusts on 443 internal to 8123 and support also http2. So you need only forward 443 to you home-assistant without port maping.
With this add-on, you can stop the add-on for recreate (run) the let’s encrypt addon. So you home-assistant goes never done and run 24/7. That need only 2-3 clicks every 3 month.
If that not practicable for you, @bestlibre write a addon that allow do that without any downtimes or some things with his nginx add-on and the certbot add-on they work togheter: https://github.com/bestlibre/hassio-addons
I like the add-on from @bestlibre but I think that is to complex for a normal default stuff. But I’m open for any PRs that can handle that better.
Thanks for the suggestion, and I think this would be an acceptable solution, but it’s unclear how this is supposed to work to me after reviewing your comment and the documentation.
I installed the nginx add on and started it, remapped port 443 external to port 443 internal @ the my homeassistant’s IP, but now can’t connect to home assistant. Am I missing a step?
Edit: @pvizeli in fact, now I can’t access home assistant at all as it hangs at the connecting page, even after reverting my port mappings. As for local connection, attempting to connect to hassio.local:80 and hassio.local:443 both give nginx 502 Bad Gateway errors. hassio.local:8123 sends no data. I have the hass configurator add on installed, am able to access it locally at hassio.local:3218, and was able to check the home-assistant.log which shows no errors, so it seems this is a problem with my nginx add on / set up.
I’m sure my problems are stemming from not understanding the nginx add on / nginx in general well enough.
Any help would be appreciated as I’d rather not reinstall hass.io, but can’t seem to figure out another way to go from here.
I have made a new addon for caddy proxy with automatic ssl renewal. It should be a shoot and forget solution since server restart is done by caddy itself. The addon is here
I tried this addon to move to hass.io but I have some doubt.
I copied the content of my caddyfile withing the “Option” field (a caddyfile that is currently working allowing me to use my pi3 as reverse proxy) but I’m unable to save it.
You cannot directly use a caddyfile. You have to follow the option schema, as explained in the doc.
It is not possible to serve a directory. You will need either to configure homeassistant to serve it or add a new addon with a server. Perhaps I could think of something with caddy proxy if you really need it.
For the other subdomains, the configuration will look like :
Forgive my ignorance, but could you give me an example of how I would configure the caddy addon? I’m currently using the DuckDNS addon and forwarding external port 443 to internal port 8123 on my raspberry pi that’s running hassio. Would I use my DuckDNS domain as “vhost”? And what changes would need to be made to my port mappings?
Thanks again for all your help, you’ve clearly been an awesome asset to the community.
@bestlibre Thanks, you’re exactly right about my setup.
Unfortunately, the reason for my post that began this whole discussion is that forwarding port 80 just isn’t an option for me. Is there an alternative setup?
There is an option in caddy to disable http chalenge. I do not know if it will work with https only. I can add the option to the addon and let you do some tests ?
I’d be happy to test it out. Seems like it will be easier with caddy than homeassistant alone, as it will not require port remapping and manual triggering for each cert update (I assume)
