SSL Error in Docker or Java

[andreasmaks]

I'm getting this error when launching hue-scheduler through docker or java:

The input:
java -jar /Users/USER/Docker/Hue-Scheduler/hue-scheduler.jar 192.168.1.xx FYDk3f14prvOlepXXXXXXqLpZOLYzKArfkDNCZa --lat=48.XXX --long=9.XXX --elevation=XXX /Users/USER/Docker/Hue-Scheduler/input.txt

The error:
jSLF4J(I): Connected with provider of type [ch.qos.logback.classic.spi.LogbackServiceProvider] 2024-12-18 16:45:49,176 [events] - An error occurred during event stream processing: javax.net.ssl.SSLHandshakeException: (certificate_unknown) PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target 2024-12-18 16:45:49,225 [init] - Failed 'Request{method=GET, url=https://192.168.1.XX/clip/v2/resource/light}' javax.net.ssl.SSLHandshakeException: (certificate_unknown) PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

and then this error:
Api not reachable: '(certificate_unknown) PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target'. Retrying in 5s.

Please help

[stefanvictora]

Hi! This error seems to indicate that Hue Scheduler could reach the given IP address but failed to create a secure connection.

Just to make sure the bridge is running an up-to-date firmware version, can you open the following address in your browser: http://192.168.1.xx/api/config?

You should get something like this as a response:

Please note that Hue Scheduler only supports the Hue Bridge v2 (the square one).

Furthermore, you could also open https://192.168.1.xx and ignore the certificate warning in the browser and then open the certificate details of the page (depends on your browser on how to do this). You should see something similar to this:

[andreasmaks]

Hi,

everything with my bridge seems valid:
{"name":"Hue Bridge","datastoreversion":"172","swversion":"1968096020","apiversion":"1.68.0","mac":"00:17:XXXXX","bridgeid":"001788FFXXXX","factorynew":false,"replacesbridgeid":null,"modelid":"BSB002","starterkitid":""}

This is the certificate:

Don't know what to do.

[stefanvictora]

This is strange. You're running the same bridge firmware and API version, so I'm not sure why the connection is failing.

Just to make sure Hue Scheduler is attempting to connect to the correct device, you could try using the last version that didn't use HTTPS: https://github.com/stefanvictora/hue-scheduler/releases/tag/v0.7.1.1

If this version works correctly, it confirms that the issue is related to certificates.

[andreasmaks]

0.7.1.1 Seems to "work"!

An error is now on the config side:
[main] - Connected to bridge at 192.168.1.12. Failed to parse configuration line 'Wohnzimmer - Strip unten, Wohnzimmer - Strip oben sunrise bri:10% ct:6000 tr:10min': InvalidPropertyValue: Invalid integer '10%' for property 'bri'.

[cswrd]

Now the InvalidPropertyValue issue is due to the usage of %, which has been added in v0.9.0. Try bri:26 (which is roughly 10% of 254 (max value)).

[andreasmaks]

Now the InvalidPropertyValue issue is due to the usage of %, which has been added in v0.9.0. Try bri:26 (which is roughly 10% of 254 (max value)).

Thanks! Now it works with 0.7.1.1

I really don't know where the problem with the certificate comes from.
I'm on a normal network here, without any proxies, firewalls, vlans or anything else.

[stefanvictora]

That is good to hear that the connection should work in theory with the new version!

I had a closer look at your certificate screenshot again and noticed that your bridge seems to have a self-signed root certificate and not one issued by Philips Hue. Which, according to the Hue developer documentation (requires login), can be identified by the CN of the issuer:

Self-signed certificates
Older Hue Bridges currently still use self-signed certificates (instead of signed by Signify’s Hue Bridge CA). Handling those requires different logic, but we intend to update all bridges to receive Signify signed certificates so that no differentiation has to be made. To check if your bridge still has a self-signed certificate, you can run the following openssl command to inspect the certificate subject and issuer:

openssl s_client -showcerts -connect :443

You should see that the Common Name (CN) of the Subject always matches the bridge id as expected, however in case of self-signed certificates you would see that the Common Name of the Issuer also equals the bridge id.

This is exactly the case for your bridge:

Normally this should be "root-bridge" if the certificate is signed by Signify.

I added a new --insecure command line flag (and INSECURE environment variable for docker usage) in 0.12.2 to add support for these older bridges.

Let me know if this fixes your issue!