LE R3 Rootcert EOL bricked IOS 9.3.* devices and Tileboard
CJA85 opened this issue · comments
Since GMT 14:00 on 2021-09-30, Older IOS devices cannot resolve LE certs, hence using WSS in Tileboard is no longer possible.
Anyone found a workaround? I have a few Ipad mini's as dashboards that are now bricked.
Do you run websites that are signed via Let’s Encrypt certificates? Then there could possibly be problems on September 30, 2021. This is because the root certificate used by Let’s Encrypt to sign client certificates will lose its validity on this day (expiry of Intermediate R3 on 2021/09/29 at 19:21:40 GMT – the DST Root CA X3 expires on 2021/09/30 14:01:15 GMT). Clients that only know the old root certificates will not be able to verify Let’s Encrypt server certificates after that.
Solved by working around SSL for now, but not optimal.
I don't think Tileboard itself can do anything about it. It just uses the SSL configuration that you have configured in your HA.
Same issue here and I also use let's encrypt.
I do not use SSL on the tileboard however, so that is a bit strange
The regular HA instances shows a page in safari, but Tileboard does not
I would personally never expose TileBoard to the outside world and sticking to http:// within your home would solve it.
I would personally never expose TileBoard to the outside world and sticking to http:// within your home would solve it.
Hmm does not seems so because I am only using http and ws (unsecure) and have not exposed tileboard to the outside.
I have stipped everything down to 1 page with 1 light.
The Home Assistant Addon works (ingress), but when I try to connect from the ipadress/port is gives an error in the console:
My partial config and 1 page with 1 entity
Nowhere I have used any secure protocol
When using the addon the wsUrl
and serverUrl
are overridden by the addon.
If there is an issue with overrides not working as expected then we should look into it.
Can you right click the page, choose "view source" and check what the window.WS_URL_OVERRIDE
and window.SERVER_URL_OVERRIDE
are set to?
Hmm, those are empty. That is strange.
I just double checked and those are in the config for sure. Might it be a breaking change on the latest HA release? This in combination with the root cert obviously, but that should not be a problem for me because I am not using ssl in any way locally
It might be a separate issue maybe?
I have uninstalled the addon and reinstalled. I do not have issues anymore. Strange, but it seems to work fine again
Strangely enough I am expiriencing the same thing now.
Part of the issue is probably
While the filter is looking for SERVER_URL_OVERRIDE = null
the actual HTML is window.SERVER_URL_OVERRIDE = "";
That seems like a post-filter value already. See
Line 35 in 3d53d16
Re-installing the addon doesn't help? Or maybe just restarting would be enough?
Unfortunately reinstalling does not help. I was wrong in my last comment, it would appear that {{ .base_url }}
and {{ .websocket_url }}
are empty but I'm not sure where those are coming from.
Needs to be debugged but here is where the variables are initialized.
While I'm presently stuck only with remote access, running following within the terminal add-on shows all blank values:
~ curl -X GET -H "Authorization: Bearer ${SUPERVISOR_TOKEN}" -H "Content-Type: application/json" http://supervisor/core/api/discovery_info
{"uuid": "", "base_url": "", "external_url": "", "internal_url": "", "location_name": "", "installation_type": "", "requires_api_password": true, "version": ""}#
Something seemed to have changed/broke in HA. I don't have time to research right now but that's a great find and starting point for figuring it out.
Probably the easiest fix might be to either put base_url into config or actually use it from JS config if window.X
is null.
Looks like it's fixable after all. The logic of base_url
was : data["external_url"] or data["internal_url"]
and there is still an API that returns those two (http://supervisor/core/api/config
).
We are already using the serverUrl
if the SERVER_URL_OVERRIDE
is falsey so it should have worked with either null
or empty string already.
TileBoard/scripts/globals/utils.js
Line 86 in 3d53d16
We are already using the
serverUrl
if theSERVER_URL_OVERRIDE
is falsey so it should have worked with eithernull
or empty string already.TileBoard/scripts/globals/utils.js
Line 86 in 3d53d16
The issue here is that {{ .websocket_url }}/api/websocket
becomes /api/websocket
Released new version that should fix compatibility with new HA release - https://github.com/resoai/TileBoard-addon/releases
Thanks so much, it is working now. Also, useExternalUrl
is really nice touch!
So this issue got a bit messy due to mixing two separate issues.
The compatibility issue with the new HA version is fixed.
The issue with the LE certificate on old devices is not something that can be fixed by this addon. The solution could be to switch to another certificate provider whose root certificate has not expired in old devices. But that's something that is controlled by each user and withing the HA itself.