LE R3 Rootcert EOL bricked IOS 9.3.* devices and Tileboard

[CJA85]

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.

[CJA85]

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.

[CJA85]

https://letsencrypt.org/docs/certificate-compatibility/

[CJA85]

Solved by working around SSL for now, but not optimal.

[rchl]

I don't think Tileboard itself can do anything about it. It just uses the SSL configuration that you have configured in your HA.

[Romkabouter]

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

[alphasixtyfive]

I would personally never expose TileBoard to the outside world and sticking to http:// within your home would solve it.

[Romkabouter]

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

[rchl]

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?

[Romkabouter]

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?

[Romkabouter]

When checking the IFRAME source in the addon, those settings are filled:

[Romkabouter]

I have uninstalled the addon and reinstalled. I do not have issues anymore. Strange, but it seems to work fine again

[alphasixtyfive]

Strangely enough I am expiriencing the same thing now.

[alphasixtyfive]

Part of the issue is probably

https://github.com/resoai/TileBoard-addon/blob/a8fc15d8e3de43c82a6f0b5ca9b30dcf1797cff4/addon/rootfs/etc/nginx/templates/direct.gtpl#L22

While the filter is looking for SERVER_URL_OVERRIDE = null the actual HTML is window.SERVER_URL_OVERRIDE = "";

[rchl]

That seems like a post-filter value already. See https://github.com/resoai/TileBoard/blob/3d53d168e9be0a6fc1036d0caea2a2fd33b1acb8/index.html.ejs#L35

[rchl]

Re-installing the addon doesn't help? Or maybe just restarting would be enough?

[alphasixtyfive]

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.

https://github.com/resoai/TileBoard-addon/blob/a8fc15d8e3de43c82a6f0b5ca9b30dcf1797cff4/addon/rootfs/etc/nginx/templates/direct.gtpl

[rchl]

Needs to be debugged but here is where the variables are initialized.

https://github.com/resoai/TileBoard-addon/blob/a8fc15d8e3de43c82a6f0b5ca9b30dcf1797cff4/addon/rootfs/etc/cont-init.d/nginx.sh#L7-L15

[alphasixtyfive]

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": ""}#  

[rchl]

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.

[rchl]

Breaking change. Seemingly with no alternative API:

Also, this doesn't seem to be related to this issue with Let's encrypt certificate.

[alphasixtyfive]

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.

[rchl]

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).

[rchl]

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.

https://github.com/resoai/TileBoard/blob/3d53d168e9be0a6fc1036d0caea2a2fd33b1acb8/scripts/globals/utils.js#L86-L86

[alphasixtyfive]

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.

https://github.com/resoai/TileBoard/blob/3d53d168e9be0a6fc1036d0caea2a2fd33b1acb8/scripts/globals/utils.js#L86-L86

The issue here is that {{ .websocket_url }}/api/websocket becomes /api/websocket

[rchl]

Released new version that should fix compatibility with new HA release - https://github.com/resoai/TileBoard-addon/releases

[alphasixtyfive]

Thanks so much, it is working now. Also, useExternalUrl is really nice touch!

[rchl]

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.