How Certificates work General Information
This section covers general information on certificates. This is mainly if you want to understand the background of how it all hangs together. It is not specifically related to LiquidFiles and you don't need to read this if you only want to install a certificate and get going.
With all certificates, regardless of if they are used on the LiquidFiles appliance or in any other application that uses certificates, they all work in the same way.
The first thing we have to understand is the relationship between the private key, the certificate signing request (CSR) and the Certificate. The relationship between them works like this:
We begin by generating a key. From the key we generate a CSR, and from the CSR we generate the certificate. Also, please note that the arrows are one way from the key through to the certificate. It's not possible, and the security of the entire Internet would fall to pieces if it was possible, to calculate or derive or by any means get hold of the key from the certificate. This also mean that if you loose the key, you will need to generate a new certificate. There is no way around that.
Key: The key is the first things that needs to be generated. The key is what has the key length. Often we refer to a certificate having a key length like 2048 bits. In reality it's actually the key that has the key length. In the LiquidFiles appliance, 2048 bit keys are used as default, but you can install a key and certificate of other lengths if required.
CSR: CSR, or Certificate Signing Request, is what gets sent to the Certificate Authority (CA). We generate the CSR from the key, and we add attributes to the CSR. The most important attribute is the CN or Common Name. The CN needs to match the hostname of the appliance. If the hostname is liquidfiles.company.com, the CSR needs to have a CN=liquidfiles.company.com. It's also possible to use a wildcard certificate. A wildcard certificate will have a CN=*.company.com. The most important thing is that that the CN matches the hostname in the URL or you will get a certificate warning.
Certificate: From the CSR we generate a Certificate by signing the CSR with a private key. If we sign the CSR with it's own key, we call the Certificate a self-signed certificate. For production systems, it's recommended to send the CSR to a public CA and have them sign the CSR. Wikipedia has a list of common Certificate Authorities.
Understanding the Certificate Chain / Intermediate Certificates
It's very common that CA's require intermediate certificates, sometimes also called subordinate certificates or the certificate chain. In order to validate the certificate, the browser needs to verify the server certificate by matching it's signature against one of the known public CA's that exist in your browser. For instance, in Internet Explorer, you can go to Internet Options → Content → Publishers, and you will see the list of trusted Certificates:
With intermediate certificates, what's happened is that the CA's certificate is not known and trusted, but they have in turn got their certificate signed by one of the known and trusted CA's. If we look at https://www.google.com as an example, by clicking on the security info section when browsing there, you will see something like this:
Or to get another, more detailed view, we can use OpenSSL to connect from the command line, like this:
% openssl s_client -connect www.google.com:443
depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
verify error:num=20:unable to get local issuer certificate
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
In this case the certificate for www.google.com has been signed by Thawte SGC CA, which is not trusted (it is not listed in the browsers list of certificates like in the screenshot above). But the Thawte SGC CA has in turn been signed by "Class 3 Public Primary Certificate Authority" which is actually the second certificate listed in the screenshot from Internet Explorer above. And since we trust "Class 3 Public Primary Certificate Authority" we will also trust "Thawte SGC CA", and since we now trust "Thawte SGC CA" we will also trust that "www.google.com" is secured by the certificate signed by "Thawte SGC CA".
Example Key (so that you can see the format, this is not actually useable):
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
Example CSR (so that you can see the format, this is not actually useable):
-----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST-----
Example Certificate (so that you can see the format, this is not actually useable):