In my case deleting previous cert files helped … But I was switching from different add-on 
Hars, I really appreciate your attempt to help me, but I’m afraid that didn’t help. I can refresh the log area as many times as I want, but it remains blank no matter how long I wait. If I navigate away and come back I can see that the addon isn’t actually running. Others have suggested deleting old certs. They’re not present on my device because I haven’t gotten as far as generating any.
I wish I knew some way to get logs that would explain why the addon immediately halts, but I am very new to home assistant and dmesg is about the extent of my abilities to investigate this. Once again, I’m all set with shell access if anyone has some suggestions as to how to further troubleshoot this.
EDIT: I have resolved this by adding an A record to my cloudflare account. I added homeassistant.example.com whereas before I was attempting to change the A record on example.com
I have been using duckdns without issue but decided to move over to letsdnsocloud as I wanted to use a subdomain off my main domain. I think I have set everything up correct, at first forgot to forward UDP was just doing TCP that that’s now fixed. When starting letsdnsocloud I can see it is connecting to Cloudflare and updating my A record with the correct IP, but seems to be failing at the generation of the ssl certs, or at least none are being generated.
No errors in main HA logs that I can see, but add-on log is showing:
Updated (domain name) with IP: (IP Address)
/usr/bin/dehydrated: line 1: 404:: command not found
When using duckdns the certs were being created in /hass.io/ssl is that still the correct location? In addition I am currently forwarding 80 and 443, I know 80 shouldn’t be required but did it just in case…
If I go to http://home.mydomain.net:8123 I do get through to ha, when trying https://home.mydomain.net:8123 I get
ERR_SSL_PROTOCOL_ERROR.
Thx in advance.
Are you trying to connect from inside or outside your local network?
If inside your local network you’ll need a router that supports multicast to connect to https.
If you forwarded port 443 you don’t need to specify the port when connecting, just use: https://home.mydomain.net
Hi @hars, I’ve tried both internal and external. Same result. Fairly sure the issue is with the generation of the ssl rather than routing. Could however be wrong!
I think there may have been an issue with the underlying script the add-on calls (Dehydrated).
I updated the config to use the latest version of that script. Try deleting the add-on and adding it again and it should work.
I updated my hassio to the latest version, deleted the certs and add-on and reinstalled and everything worked fine.
What you should see in the log:
Updated your.domain.name with IP: **.**.**.**
# INFO: Using main config file /data/workdir/config
+ Generating account key...
+ Registering account key with ACME server...
+ Fetching account ID...
+ Done!
# INFO: Using main config file /data/workdir/config
+ Creating chain cache directory /data/workdir/chains
Processing your.domain.name
+ Creating new directory /data/letsencrypt/your.domain.name ...
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting new certificate order from CA...
+ Received 1 authorizations URLs from the CA
+ Handling authorization for your.domain.name
+ 1 pending challenge(s)
+ Deploying challenge tokens...
Waiting 30 seconds before deleting for LE
+ Responding to challenge for your.domain.name authorization...
+ Challenge is valid!
+ Cleaning challenge tokens...
+ Requesting certificate...
+ Checking certificate...
+ Done!
+ Creating fullchain.pem...
+ Done!
@hars, still the same unfortunate. I:
Uninstalled the add-on
Restarted Hass just to be safe
Re-installed add-on
Set/Saved config options
Started add-on
Same error:
Updated sub.domain.net with IP: myipaddress
/usr/bin/dehydrated: line 1: 404:: command not found
fyi as might be relevant, I’m running hass (170) on a synology disk-station, letsdnsocloud is showing version 1.1. Not sure if this is as expected, my /data/workdir/config is empty.
The Cloudflare component is working as expected with the A record being updated.
Eoin
Ah, most likely yes.
Does /bin/bash exist?
What is the output of “echo $SHELL” ?
My knowledge of Synology is next to nothing but it looks like perhaps it doesn’t use bash if you’re getting a commend not found error.
Sorry I really don’t have the chops to try and help you fix this. I’m pretty new to Hassio and have no experience with Synology.
Have you read through this thread?
It looks like the Synology install is pretty tricky and takes some fiddling around to get it working.
Hassio under Synology should behave the same as under other environments. It is “virtualized” via docker so addons should not be affected of underlying system.
Hey @hars, I’m trying to get this installed on hassio supervisor 181, but when I try and run the install, I get the below stack trace
19-08-21 02:09:30 INFO (SyncWorker_6) [hassio.docker.addon] Start build 3983e8d8/amd64-addon-letsdnsocloud:1.1
19-08-21 02:09:30 ERROR (MainThread) [aiohttp.server] Error handling request
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/aiohttp/web_protocol.py", line 418, in start
resp = await task
File "/usr/local/lib/python3.7/site-packages/aiohttp/web_app.py", line 458, in _handle
resp = await handler(request)
File "/usr/local/lib/python3.7/site-packages/aiohttp/web_middlewares.py", line 119, in impl
return await handler(request)
File "/usr/src/hassio/hassio/api/security.py", line 145, in token_validation
return await handler(request)
File "/usr/src/hassio/hassio/api/utils.py", line 38, in wrap_api
answer = await method(api, *args, **kwargs)
File "/usr/src/hassio/hassio/addons/__init__.py", line 132, in install
await addon.instance.install(store.version, store.image)
File "/usr/src/hassio/hassio/utils/__init__.py", line 29, in wrap_api
return await method(api, *args, **kwargs)
File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/src/hassio/hassio/docker/addon.py", line 364, in _install
self._build(tag)
File "/usr/src/hassio/hassio/docker/addon.py", line 378, in _build
use_config_proxy=False, **build_env.get_docker_args(tag)
File "/usr/local/lib/python3.7/site-packages/docker/models/images.py", line 279, in build
resp = self.client.api.build(**kwargs)
File "/usr/local/lib/python3.7/site-packages/docker/api/build.py", line 160, in build
path, exclude=exclude, dockerfile=dockerfile, gzip=gzip
File "/usr/local/lib/python3.7/site-packages/docker/utils/build.py", line 31, in tar
root=root, fileobj=fileobj, gzip=gzip, extra_files=extra_files
File "/usr/local/lib/python3.7/site-packages/docker/utils/build.py", line 68, in create_archive
fileobj = tempfile.NamedTemporaryFile()
File "/usr/local/lib/python3.7/tempfile.py", line 538, in NamedTemporaryFile
prefix, suffix, dir, output_type = _sanitize_params(prefix, suffix, dir)
File "/usr/local/lib/python3.7/tempfile.py", line 126, in _sanitize_params
dir = gettempdir()
File "/usr/local/lib/python3.7/tempfile.py", line 294, in gettempdir
tempdir = _get_default_tempdir()
File "/usr/local/lib/python3.7/tempfile.py", line 229, in _get_default_tempdir
dirlist)
FileNotFoundError: [Errno 2] No usable temporary directory found in ['/tmp', '/var/tmp', '/usr/tmp', '/']
Similar issue below - do you have enough space on whatever drive you’re using? Another common issue to hassio installs that could cause that problem would be a corrupt sd card.
Thanks for the quick response… I’m running on an SSD w/ Gbs free… BUT what is super odd is this morning when I checked, it was suddenly installed… I’m wondering if maybe there was some issue w/ hass.io caching the response… I tried with a few different browsers, so I doubt it was a browser cache issue. 
Thanks for this addon! Exactly what I needed. However, I followed the instructions and get the following error:
2019-08-25 19:21:51 ERROR (MainThread) [homeassistant.core] Error doing job: SSL handshake failed
Traceback (most recent call last):
File "uvloop/sslproto.pyx", line 500, in uvloop.loop.SSLProtocol._on_handshake_complete
File "uvloop/sslproto.pyx", line 484, in uvloop.loop.SSLProtocol._do_handshake
File "/usr/local/lib/python3.7/ssl.py", line 774, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: HTTP_REQUEST] http request (_ssl.c:1076)
My configuration.yaml looks like this (certain bits redacted):
http:
base_url: https://home.example.info
ssl_certificate: /ssl/fullchain.pem
ssl_key: /ssl/privkey.pem
ip_ban_enabled: true
login_attempts_threshold: 5
I guess the only thing I could think of is that the ssl directory is created at the same level as the config directory i.e. hass.io -> config and also hass.io -> ssl. Is that correct? (I’m running Virtualbox)
This error is in multiple add-ons and super common, check it out:
Give this a shot and see how you go:
Thanks, well in fact it was working all along! I didn’t realise that my internal IP would not resolve after this addon was enabled, so I thought my hass instance just wasn’t working, as it wasn’t connecting to my local internal IP (http://192.168.1.x:8123) - switching to the new URL (https://subdomain.domain.info) works just fine (both internally and externally). Still getting that error, but I can live with that until a fix is found.
My only question I guess is, should the internal local IP still work? Not a big deal, but would be nice to know if I’ve configured it correctly.
Oh, yeah - it’ll still work just not on the internal IP.
Internal IP won’t work if you enable https so you’re all good.
1 Like
fantastic work thank you!
I can’t get it working. I only can enter in the same LAN, only via IP if I try to enter remotely.