on - edited on by
LiefZimmerman
This is part 3 in a series of articles covering the BIG-IP LTM SSL profiles.
- SSL Overview and Handshake
- SSL Certificates
- Certificate Chain Implementation
- Cipher Suites
- SSL Options
- SSL Renegotiation
- Server Name Indication
- Client Authentication
- Server Authentication
- All the "Little" Options
Introduction
Now that we have some foundational information in place, we’ll put some of the certificate knowledge into practice as we build our first SSL profile. Recall from part 2 the certificate chain and the layers of trust involved. For our configuration (see Figure 1), I’ve built a root CA with two layers of subordinate CAs prior to actually signing a certificate for test site devcentral.f5test.com.
So after much openssl cli typing (or if you are lazy like me, using TinyCA2), I end up with four files that will assist in building out our first profile:
- Root Certificate (dcrootCA-cacert.pem)
- Sub CA 1 (dcsubCA1-cacert.pem)
- Sub CA 2 (dcsubCA2-cacert.pem)
- Server Certificate (dctest.p12)
Importing Certificates & Constructing the Certificate Chain
The goal here is to install the root certificate on the client, and then chain the two subordinate CA certificates with the root CA for use on the profile with the server certificate. First, we’ll import the server certificate as shown in Figures 2 and 3. Beginning in version 10.1, you can import a PKCS package that includes server/key so I exported from TinyCA2 that way to save me a step. Prior to 10.1, you’ll need PEM.
Now that the server certificate is in place, I can upload the CA certificates and concatenate them into a certificate chain.
[root@golgotha:Active] ssl.crt # cat dcsubCA1-cacert.pem dcsubCA2-cacert.pem dcrootCA-cacert.pem > /config/ssl/ssl.crt/dctestchain.crt
Next, verify that the certificate chain establishes the trust relationships for the server certificate:
[root@golgotha:Active] ssl.crt # openssl verify -CAfile dctestchain.crt devcentral.f5test.com.crt
devcentral.f5test.com.crt: OK
On the client side, my windows 7 pc doesn’t recognize pem format, so I convert from pem to crt and scp it from the LTM and install it into my trusted root certificate authorities store:
[root@golgotha:Active] tmp # openssl x509 -in dcrootCA-cacert.pem -outform DER -out dcrootCA.crt
A Beginning ClientSSL Profile
There are plenty of settings in the profile that we’ll get to eventually, but for our first profile, we’re going to simply reference our certificate, key, and chain. This is shown in Figure 4.
Built from the clientssl default profile, we’ll name it the common name of our server, devcentral.f5test.com, then match the appropriate certificate and key we imported, and finally, we’ll need to switch to the advanced configuration to get to the chain option, where we’ll select the dctestchain certificate. After saving the profile, apply it against a virtual server and create a host entry in your hosts file to test everything out. If the trust is correct, there will be no certificate warning, as is the case shown in Figure 5 below.
If we make one change to the clientssl profile and disable the certificate chain, you can see that it breaks the trust relationship (Figure 6)
Gotchas
There are a couple solutions on MyF5 that might impact your use of certificate chains
- Solution 7788 – SSL certificate chains and COMPAT ciphers do not include the chain certificates specified in the SSL profile
- Solution 8653 – A large number of certificates in a certificate chain may cause the SSL connection to close
Conclusion
Whether you are using a CA-provided chain or creating your own, we’ve taken the theory of certificate chains and configured a practical example of the trust relationships in building our first clientssl profile. In the next article in this series, we’ll take a look at ciphers.
