If you want to access OPI from anything else than the apps provided by us, a security warning will be shown, and in many cases access to OPI will be denied by the device.
In order to work around this issue, the certificate that will allow OPI to be trusted can be installed on your device quite easy.
From the device in question, navigate to http://download.openproducts.com/opi/ROOTCA.crt
This will open a dialog box asking you to name the certificate. This name can be anything as it is only used for you to identify the certificate in human writing.
The certificate is now installed and can be viewed in "Settings->Security->Trusted credentials" in the tab "User"
How to install OpenProducts RootCA
Installing new root CAs is always dangerous things, as after this the owner of this CA can sign a web site claiming to be your bank, and act as man in the middle between your device and the bank. Even worse the certificates signed by that root are all marked as being CAs, meaning they can sign new certificates without any path length constraints, or without name constraints. This is very dangerous. I.e. I could take my private key from my opi device and as that key is signed by the OpenProducts OPI CA certificate, which is then signed by that ROOT CA, I can now create new certificates which are part of that hierarchy. So I can create new private/public key pair, create certificate signed by my opi private/public key pair and names like amazon.com in there and if I can then trick you to connect to my machine instead of amazon.com, you will accept my machine as being amazon.com.
There are few ways to get around this issue. Normally CAs never give you out certificates which allows you to sign other certificates, i.e., all certificates they give out do NOT have BasicConstraints extension. This means the cA flag in there defaults to false, thus they cannot sign new certificates. As all OPI devices already have certificates with this extension this is not really possible anymore, i.e., the cat is out in the box already.
Another way to fix this is to recreate the ROOT CA and the OpenProducts OPI CA certificate so that they limit the length of the path. The ROOT CA do not have path length constrain, but the OpenProducts OPI CA do have pathlen of 1. Unfortunately this means that there can be one intermediate CA between this cert and end cert, thus I can still use my own OPI cert to sign new certs. This pathlen should be set to 0, so the OpenProducts OPI CA can only be used to sign end certs, i.e. the certs given to users.
In addition to that there is feature called name constraints, which limits the names that CA can sign for. In this case as this certificate is only used to sign op-i.me names, the CA could contain name constrains which limits that it can only be used for those names under op-i.me. Unfortunately there are still several browsers which do not support name constraints, so you cannot set this extension to be critical, as then those browsers would not be able to use that CA at all. You could provide two root CA certificates, one with name constraints and another without, so user could pick the name constraint version if it works for his browser, and have better security. And if his application do not support name constraints he can use the other one. This would require to have another version of ROOT CA which has NameConstraints to permit only op-i.me names. This would be easier if the certificates for the OPI devices would use SubjectAltName DNS format instead of CN in the certificate Subject.
Also it seems the certificates generated are still using SHA-1 which will be deprecated in the browsers soon, and this means you will get red errors saying connections are insecure regardless whether you install the root ca or not.
There are few ways to get around this issue. Normally CAs never give you out certificates which allows you to sign other certificates, i.e., all certificates they give out do NOT have BasicConstraints extension. This means the cA flag in there defaults to false, thus they cannot sign new certificates. As all OPI devices already have certificates with this extension this is not really possible anymore, i.e., the cat is out in the box already.
Another way to fix this is to recreate the ROOT CA and the OpenProducts OPI CA certificate so that they limit the length of the path. The ROOT CA do not have path length constrain, but the OpenProducts OPI CA do have pathlen of 1. Unfortunately this means that there can be one intermediate CA between this cert and end cert, thus I can still use my own OPI cert to sign new certs. This pathlen should be set to 0, so the OpenProducts OPI CA can only be used to sign end certs, i.e. the certs given to users.
In addition to that there is feature called name constraints, which limits the names that CA can sign for. In this case as this certificate is only used to sign op-i.me names, the CA could contain name constrains which limits that it can only be used for those names under op-i.me. Unfortunately there are still several browsers which do not support name constraints, so you cannot set this extension to be critical, as then those browsers would not be able to use that CA at all. You could provide two root CA certificates, one with name constraints and another without, so user could pick the name constraint version if it works for his browser, and have better security. And if his application do not support name constraints he can use the other one. This would require to have another version of ROOT CA which has NameConstraints to permit only op-i.me names. This would be easier if the certificates for the OPI devices would use SubjectAltName DNS format instead of CN in the certificate Subject.
Also it seems the certificates generated are still using SHA-1 which will be deprecated in the browsers soon, and this means you will get red errors saying connections are insecure regardless whether you install the root ca or not.
Hi kivinen,
Sorry for the late reply and a big thank you for this heads up and review of our certificate chain. Yes you are right, we goofed this up. I actually thought that we had this double reviewed, obviously I where wrong.
We are in the works on update the Certificates since they are SHA1-signed. (Note however that new OPI-certs are SHA-256) We will of course adress this as soon as possible.
In the mean time, our biggest apologies!
/Tor
Sorry for the late reply and a big thank you for this heads up and review of our certificate chain. Yes you are right, we goofed this up. I actually thought that we had this double reviewed, obviously I where wrong.
We are in the works on update the Certificates since they are SHA1-signed. (Note however that new OPI-certs are SHA-256) We will of course adress this as soon as possible.
In the mean time, our biggest apologies!
/Tor
While you are switching certificates, it would be nice to have instructions how we can replace the OPI-generated certificates with your own certificates. It does not need to be gui based, it can also be just instructions to ssh into the box, and replace /etc/opi/opi.cert with whatever certificate you want (replacing also dnspub.pem and dnspriv.pem files too if you regenerated the key) or similar.
For example are any of the files in the /etc/opi needed for anything else than httpd? Does the update mechanism or cloud backups use those things? If so then which files needs to be kept intact, and which can be changed.
Providing this information would allow me to change the OPI root ca, to my own private CA, which is already trusted by my devices, and it would also allow storing multiple names in the certificate, so I could use same certificate with different names, so I could have one name for internal access and one name for external access, etc.
For example are any of the files in the /etc/opi needed for anything else than httpd? Does the update mechanism or cloud backups use those things? If so then which files needs to be kept intact, and which can be changed.
Providing this information would allow me to change the OPI root ca, to my own private CA, which is already trusted by my devices, and it would also allow storing multiple names in the certificate, so I could use same certificate with different names, so I could have one name for internal access and one name for external access, etc.