https://otau.meethue.com started using a self-signed certificate
#420
Comments
|
FWIW, the SHA512 sum still matches. So file integrity seems unaffected. |
|
If this is, in fact a persistent change on Signify's end we'd need to implement passing of a custom If we need to manage custom CA certs it would probably be sensible to add some metadata to this repository for hosts that require custom certs. That way the certs can be tracked in the Git history of this repo for transparency. |
|
I would propose to:
|
|
I started dabbling a bit with it yesterday: kaechele@643f00b What this basically proposes is that this repository would store all custom CA certs and create a bundle that zigbee-herdsman-converters can use. This proposal would require the manual effort of pushing any new certificates to this repo and creating the bundle. The fetching of the certificate could be automated as well, but I believe it's not too bad of an idea to do it by hand. The benefit of this would be an actual increase in security. Manually vetted custom CAs and pinning downloads from the respective hosts would probably implement what Signify is intending with this change: They control the entire signature path for firmware image delivery. Your proposal would certainly work as well. But I can think of a few questions I'd have:
I think a combined approach could be feasible as well. Mirror the CA certs in this repo for transparency and change tracking, link to the raw files on GitHub for zigbee-herdsman-converters to use in the fashion that you suggested (link in |
|
What about adding a {
"host": "otau.meethue.com",
"ca": "...."
} |
|
I thought of that as well, but wasn't sure if this would be an acceptable approach for you, since it adds a custom approach compared to the simple CA cert bundle approach. The benefits of doing it with a The CA cert bundle version is a bit simpler. It just expands the list of CAs we trust during download. But it wouldn't bail if suddenly instead of Signify's CA we'd be presented with a download coming from a host presenting a LetsEncrypt certificate, because LetsEncrypt is a trusted CA as well. |
|
Do we need to add certs for all hosts when going for the CA bundle approach? |
|
Only if they are not already trusted by the system's CA cert bundle. If you look at Line 58 of the
So I first need to add the default CAs back (from So in zigbee-herdsman-converters it could be implemented in the very same way, we'd just need to add a way to first get the additional CA certs we need (i.e. for now, just the Signify CA). And for that it'd probably make sense to host them in this repo. |
|
Does this mean we also need to keep updating |
|
Yes, that file would always need to be updated (i.e. regenerated) when we add another CA cert. Concatenating all CA certs into one single Ultimately, this could be made part of Another side note: Also, as my mind tends to get carried away, I was also thinking we could add GitHub actions to regularly (maybe weekly?) run I'm certainly happy to support with implementing any of this. Just let me know where I can help. |
|
So 'cacert.pem' currently only has to be updated when the Hue certificate changes or when we add a new certificate? I like the automation part, we can run it daily even. Would you mind making a pr for both this repo and zigbee-herdsman-converters? |
|
Correct. I'm happy to provide a PR. |
|
Working on it as we speak. I am hitting a few complexities I'm hoping to have worked out soon. Stay tuned :) |
|
just to add to it are you really sure signify is doing that on purpose ? |
Can't be entirely sure.
Try using the |
I've never used it but I assume the official Hue hub hits this same server, correct? Have we confirmed that Signify's own app isn't running into the same cert problem? If it works we can't can't say it was definitely on purpose but if it does break in the official app it would be a strong sign that this is unintended on Signify's part. FWIW my output from OpenSSL: (appears to match the chain in the OP) |
|
Perhaps it's possible to check the iOS or Android apps for a copy of one of the certificates. If they are intentionally self-signing, I can't believe that they wouldn't also pin the root or an intermediate certificate in the app. |
|
Implementation is done in principle:
Will be doing some more testing tomorrow and then prepare the PRs. But is seems to be working fine for me locally. There are a few things I'd like to work out that would require a bit deeper refactoring of things, but that can happen over time:
|
I'm pretty confident the pinning would be happening in the Hue bridge, not in the App. |
|
Kaechele amazing work :) Hope it works so I can update my single old Philips Hue bulb I found in a drawer ;-) |
Part of the fixes for Koenkk/zigbee-OTA#420 Signed-off-by: Felix Kaechele <[email protected]>
Part of the fixes for Koenkk/zigbee-OTA#420 Signed-off-by: Felix Kaechele <[email protected]>
- Adds custom CA certificate for Philips Hue OTA updates - Adds support to use these certificates to `scripts/add.js` - Adds concatenation of CA certs to `scripts/updateall.js` Part of the fixes for Koenkk#420 Signed-off-by: Felix Kaechele <[email protected]>
- Adds custom CA certificate for Philips Hue OTA updates - Adds support to use these certificates to `scripts/add.js` - Adds concatenation of CA certs to `scripts/updateall.js` Part of the fixes for #420 Signed-off-by: Felix Kaechele <[email protected]>
|
My current work around until the fix is implemented is this (btw: I'm not running z2m in a container):
content of extra_ca.pem: -----BEGIN CERTIFICATE----- |
Great workaround. Thanks! Now I just need to find out how to add an environment variable to z2m... |
Part of the fixes for Koenkk/zigbee-OTA#420 Signed-off-by: Felix Kaechele <[email protected]>
|
@oscfor It's an environment variable on Operating System level, not specific for z2m or nodeJS. Here is a link how to set an environment variable permanently on different operating systems: https://www3.ntu.edu.sg/home/ehchua/programming/howto/Environment_Variables.html |
I took a different approach and downloaded the firmware manually, and then applied them using a local OTA index: https://www.zigbee2mqtt.io/guide/usage/ota_updates.html#local-ota-index-and-firmware-files However, your method doesn't require finding the right JSON definition for the firmware file, which would be a pain if you had many different devices to update. Nice! 👏 |
|
I've just tried with haos but it doesn't work, probably something I'm doing wrong. https://github.com/Athozs/hass-environment-variable unfortunately it doesn't work. if you have an idea :) |
|
@adrienneo19 that custom component sets environment variables for Home Assistant itself, not its addons. I don't think there's a way to set environment variables for addons - you're probably best waiting until the issue is fixed in Z2M. |
…TA updates) (#6831) * feat: support custom CA certs for OTA firmware downloads Part of the fixes for Koenkk/zigbee-OTA#420 Signed-off-by: Felix Kaechele <[email protected]> * feat: custom CAs: limit scope to zigbeeOTA image downloads Signed-off-by: Felix Kaechele <[email protected]> --------- Signed-off-by: Felix Kaechele <[email protected]>
|
This is solved now, many thanks @kaechele ❤️ Changes will be available in the dev branch in a few hours from now. |
Is it possible to switch to the dev branch if using Z2M as an add-on in HA? |
I'm on stable branch - updated now and it's working away upgrading the firmware on a hue bulb I have. |
Oh, you're right, I looked before and didn't see that available. But sure enough, there it is. THANK YOU! |
|
How does it actually work? I'm on version 1.35.1 with zigbee2mqtt LXC on proxmox. At the moment the firmware upgrade on my two phillips lightstrips still failed. |
|
That looks more like #400 than anything to do with this particular bug, which is fixed in recent versions. |
|
Fun fact: the certificate was changed back to a proper DigiCert signed one recently (certificate issued January 9). So it seems the change was likely unintentional. |
|
Hi, I'm trying to update some hue bulbs and get this message:
it does look like the same problem that was fixed, but still does not work here. I'm using Zigbee2MQTT Edge if that matters.
|
Signify seems to have started using self-signed certificates for
https://otau.meethue.com.Unsure if this is a bug on their end or a new configuration they have adopted going forward.
Either way, currently OTA updates using images hosted on that URL will fail:
Certificate Chain
Related: Koenkk/zigbee2mqtt#20429
The text was updated successfully, but these errors were encountered: