Tagged: https ssl-certificate dane TLSA
September 6, 2014 at 09:08 #415
When I go to my opi the https it complains about a untrusted certificate.
How do I get a correctly siged certificate?
September 6, 2014 at 10:00 #417
My personal opinion about how certificates work in browsers is that it is a total mess and that the messages displayed by the browsers are wrong in what they are saying and that it is a way to make more money…
That said, lets get to your question.
First I would like to split the question in two, a correctly signed certificate is not the same as an untrusted certificate.
A certificate needs to be signed by an authority and this can be seen as the signature put on a formal agreement such as a contract that you sign. This authority can be anyone that stands behind that agreement, in the most common cases it is you your self that is the authority signing the paper or contract.
Much in the same way, certificates used in browsers (or much in the same way for any kind of cryptografic systems used on the internet) has to be signed by an authority to be correct and valid. What happens in the case with OPI is that the certificate you have on OPI is generated by your OPI after you select your opi-name, then sent to our servers that validates the origin (that it is indeed sent from an OPI) signs the certificate and sends it back.
So in this case it is OpenProudcts that has signed the certificate (OpenProducts is then called CA, or Certificate Authority).
Now we come to the issue with the untrusted part of the certificate and this is where I believe that the warnings shown are completely misleading. The reason for it not to be trusted is that we as CA have not paid the ridiculously amount of money that would be required to put a “trusted” certificate on each OPI. For us to do this, the price on each OPI would have to be considerably higher, so for a business perspective that would not be feasable. So what that warning is saying is simply “The CA that singned this certificate is not in the database of CA’s that is available”. In my opinion it has nothing to do with trust, only money. If you would look at the amount of trusted CAs’ that are in the database, you would probably not trust this at all anymore. Take a look at this trusted certificate for instance:
CNNIC it is trusted by chrome but there is no information on the issuer. By looking at the ceritficate the only thing that I can find is that organization behind it is CNNIC. No clue on where they are located or any other information. But you would get a green bar in chrome visiting a site that has a certificate signed by them. And it is only a matter of money to get into that list.
Now to get to the part on how to get rid of the warning shown in your browser.
If using Firefox, you can choose to make an exception for the site. This is the default behavior when you select to proceed despite the warning shown.
On chrome this is a bit more complicated, Google has not allowed for uses to make exceptions easy. In order make this work you need to install our root Certificate, so that is available in the same list at the CNNIC mentioned above.
Download our root CA here: http://media.openproducts.com/opi-ca/opi-ca.crt
Go to “Settings”->”Advanced Setting”->”Manage Certificates” and then choose to import the file downloaded from the above link.
I have on my todo list a note to write a guide on this, but there are lots of things on that list… So if anyone feels like it or has some relevant and up-to-date links, feel free to post it here. 🙂
October 1, 2014 at 18:22 #548
You should add TLSA records (i.e. DANE records RFC6698) for the opi names. I.e. while adding the opiname.op-i.me name to the DNS, you should add TLSA 3 1 1 records for it too. It seems you do generate unique private key for each device, and sign that by your internal CA, so that would allow making the TLSA records too.
The DANE is meant to be used in cases where the normal web CA trust roots are not usable, i.e. for self-signed certificates or other setups which are not connected to the web CA roots. Currently the support in the browsers and other places are not yet there, but there are for example firefox plugin checking DANE records.
Adding those records with hash-slinger is quite easy, i.e. when you have the certificate and the domain name just run:
tlsa --create --certificate opi-cert.pem --usage 3 --selector 1 --mtype 1 opiname.op-i.me
and that will print out the entries suitable to be stored in the DNS.
October 1, 2014 at 21:59 #557
Nice suggestion kivinen!
We will definetly investigate this! Is this in any way related to the Public key Pining?
Anything remedying the crazy state of https/x509 would be deeply appreciated by us. It should come as no surprise to anyone that the central authority of https/x509 system sucks big time.
October 2, 2014 at 12:18 #560
It is related to the public key pinning, but this is not specific to the browser or the site. I.e. public key pinning means that the information which CA has signed which site is stored in the browser. In this case the same information is available but it is stored in the DNS (hopefully protected with DNSSEC).
I.e when TLS connection is made to the host opiname.op-i.me the application would first fetch the
entry from the dns and then when it gets back reply saying
‘_443._tcp.opiname.op-i.me. IN TLSA 3 1 1 c5bcc434…’
This hash in the entry matches the SubjectPublicKeyInfo block of the end certificate used to authenticate the connection to the server. The first 3 means that this is end entity certificate, which is not signed by normal web CA trust root. If it would be 2 that would mean that this hash is not for the end entity certificate, but for the CA certificate signing the certificate used in the TLS connection (i.e. in this case the “ROOT CA” or the “OpenProducts OPI CA”). Values 0 and 1 would mean that it is extra checks for the certificates which are already part of the web CA trust hierarchy, i.e. value 0 can be used to do public key pinning, making sure that only that CA can sign the certificate and value 1 would mean that only that public key can be used.
The next “1 1” specifies that the hash is calculated over the SubjectPublicKeyInfo blob, not full certificate, and that the hash is SHA-256 hash.
BTW, it would be better to switch from SHA-1 to SHA-256 when generating those certificates to be used for opi-devices. For example google has decided to get rid of the support for SHA-1, and will treat those as “affirmatively insecure” starting early next year (http://googleonlinesecurity.blogspot.fi/2014/09/gradually-sunsetting-sha-1.html).
Most of the CA vendors have already been asking customers to get new certificates using SHA-256 just because of this (for example https://www.digicert.com/sha1-sunset/).
You must be logged in to reply to this topic.