Hier het stuk van de Philips Hue Developers site:
The Hue API can currently be accessed over HTTP on port 80 and HTTP over TLS (HTTPS) on port 443. For security reasons HTTP access to the API will be disabled in a future firmware release. This section explains the differences and how to upgrade to HTTPS.
Hue Bridge Root CA
To use HTTPS properly, the client has to validate the Hue Bridge certificate against the Signify private CA Certificate for Hue Bridges. This is typically done by adding the CA cert into the key store trusted by the HTTP client, or for some HTTP clients by adding it as an input parameter when setting up the HTTPS connection. The CA certificate is shown below in PEM format.
-----BEGIN CERTIFICATE-----MIICMjCCAdigAwIBAgIUO7FSLbaxikuXAljzVaurLXWmFw4wCgYIKoZIzj0EAwIwOTELMAkGA1UEBhMCTkwxFDASBgNVBAoMC1BoaWxpcHMgSHVlMRQwEgYDVQQDDAtyb290LWJyaWRnZTAiGA8yMDE3MDEwMTAwMDAwMFoYDzIwMzgwMTE5MDMxNDA3WjA5MQswCQYDVQQGEwJOTDEUMBIGA1UECgwLUGhpbGlwcyBIdWUxFDASBgNVBAMMC3Jvb3QtYnJpZGdlMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEjNw2tx2AplOf9x86aTdvEcL1FU65QDxziKvBpW9XXSIcibAeQiKxegpq8Exbr9v6LBnYbna2VcaK0G22jOKkTqOBuTCBtjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUZ2ONTFrDT6o8ItRnKfqWKnHFGmQwdAYDVR0jBG0wa4AUZ2ONTFrDT6o8ItRnKfqWKnHFGmShPaQ7MDkxCzAJBgNVBAYTAk5MMRQwEgYDVQQKDAtQaGlsaXBzIEh1ZTEUMBIGA1UEAwwLcm9vdC1icmlkZ2WCFDuxUi22sYpLlwJY81Wrqy11phcOMAoGCCqGSM49BAMCA0gAMEUCIEBYYEOsa07TH7E5MJnGw557lVkORgit2Rm1h3B2sFgDAiEA1Fj/C3AN5psFMjo0//mrQebo0eKd3aWRx+pQY08mk48=-----END CERTIFICATE-----
Common name validation
The other part of the certificate validation is checking that the common name on the certificate matches the bridge id of the bridge you are trying to connect to. This is typically done by using the bridge id as hostname and adding a custom resolver that resolves it to the IP address, or by injecting a custom hostname verifier into the HTTPS client which checks that the server principal name matches the bridge id.
In this example it is assumed that the CA certificate above is stored in a file called huebridge_cacert.pem. Furthermore the , and should be replaced by the actual values for the respective bridge.
First, this is an example curl command line request to retrieve the list of lights using plain HTTP:
The equivalent request on HTTPS would then be:
curl --cacert huebridge_cacert.pem --resolve "<bridgeid>:443:<ipaddress>" https://<bridgeid>/api/<username>/lights
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 <ipaddress>: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.
Until these bridges are updated, you need to handle the logic of trusting self-signed certificates at first connection. In other words you need to pin (with the bridge-id) the certificate on first connection with the bridge (“trust on first use”) and check upon later contacts with the same bridge. For development/testing purposes, you can disable certificate validation (e.g. using the curl –insecure command line argument).
Web browsers do not have access to the root certificate of the Hue Bridges. This means that in case you would access the bridge using a browser (e.g. going to https://) the browser will complain that the connection is not secure due to the fact that the certificate has not been certified by a trusted third party, and will ask you whether you want to continue and trust the certificate.