Today I’m starting a new series, which has the working title of “Fixing SSL Labs Grade on F5 Big-IP Load Balancers” which is a series on fixing the most common SSLLabs.com grade issues (We all want that A+, am I right?) when using F5 Big-IP devices as a reverse proxy and/or load balancer. Today we’ll have a look at how-to fix a common error, missing certificates in the certificate chain.
Let’s have a look at the test score below.
As you can see, it states “This server’s certificate chain is incomplete. Grade capped to B.” The screenshot is taken from an Big-IP v.13 running a stock configuration, so we’re doing quite alright already (IIS 7 for example scores an F out-of-the-box). But we want at least an A, so we have some stuff to fix.
The error is quite hard to understand if you’re not intimately familiar with how SSL certificates work. Certificates, in their most basic form, work by having two parts, a private and a public key. When you connect to a server, it sends you it’s public key, and you encrypt traffic with that key, which the server can then decrypt using it’s private key. This secure channel is then used to set up session keys for any further communication and to do all sorts of magic behind the scenes. So this is quite easy, right?
But how do we know that the server sending us the certificate is who it says it is? This problem is then solved by adding a Certificate Authority into the mix (henceforth referred to as a CA). The CA signs the certificate when it’s issued (in contrast to an untrusted self-signed certificate signed by the server itself) with the private key of it’s own root certificate, and every browser out there has the public keys of all root CAs bundled into them “from the factory”, so they can decrypt the signature using the public key and verify that the CA is who it says it is.
But, since there are a limited amount of trusted root CAs around, certificates from them can get quite expensive, so root CAs routinely sign other, second tier, CA’s root certificates. This is what the error refers to, we’re using a certificate from a secondary tier CA, but our server isn’t sending the intermediate CA with our server certificate. This usually doesn’t give you a browser error, so I suspect browsers have a mechanism for fetching these missing intermediate CA certificates.
So, when you get a certificate from an intermediate CA, they include the intermediate certificate in the certificate bundle as they are sent to you. So what we need to do is import the intermediate certificate into the F5, and assign it to the SSL policy we’re using.
Importing the Intermediate CA Certificate
First, we’ll import the intermediate CA certificate
Go under System -> Certificate Management -> Traffic Certificate Management -> SSL Certificate List -> Import
Here, select Certificate under Import Type, give it a name, and upload the file or paste the certificate as a text blob.
Applying the Intermediate Certificate to the Certificate Chain under an SSL Profile
Next, we need to add this certificate to the SSL profile that needs it.
Go under Local Traffic -> Profiles -> SSL -> Client and select the Profile you’d like to edit.
Under Certificate Key Chain, select the certificate you’d like to edit, and click Edit
Under Chain, select the intermediate CA certificate you imported earlier.
Checking Your Work
Now, if everything worked out as planned, check your work by redoing the SSL Labs test, your result should look similar as to the one below.
This section only covers issues where you have only one intermediate CA. You could theoretically have more, and F5 has a guide on how to bundle all those intermediate CA certificates into one, but it’s a bit more advanced, so I’ll not cover it here further.
Also check out the other instalments of this series: