How to Configure & Renew SSL Certificate on F5 BIG-IP
SSL certificates are a key part of any modern web traffic. They play a big role in establishing secure communication channels between clients and the F5 BIG-IP load balancer. When clients connect to the load balancer over HTTPS, SSL certificates ensure that the data exchanged between them remains encrypted and secure during transit.
SSL certificate basics
An SSL certificate has a couple of components, which are vital for any secure communication. Let’s break down these components.
- SSL certificate: this is a single object, with various details (Common Name, Subject Alternative Name, Company Name, Location, expiry date, etc.), which has been digitally signed by a trusted party, so anyone can be sure that the certificate is valid.
- Intermediate and/or Root certificate: these are certificates from trusted 3rd party companies, which prove that the main SSL certificate has been signed by them, and it is a valid certificate. The list of the certificates, from the root to the end-user certificate is called the certificate chain.
- Private Key: this is a key generated during the SSL certificate creation, and it should stay protected all the time. If it gets out to the world, the certificate is not considered safe anymore. The private key is being used during the encryption process. Every traffic that is encrypted by the load balancer can be unencrypted with the public key, which is part of the SSL certificate.
These components are super important for us, in the next section you will see how they are tied together in the BIG-IP load balancer.
Related: How to Write F5 iRules with Examples
SSL setup on F5 BIG-IP without existing certificates
If you don’t have any SSL certificates to use, that means you have to obtain one. There are two ways to do that. In this article, I’m focusing on certificates that are signed by some certificate authority (CA). You could generate self-signed certificates as well, but they won’t be trusted by other parties, so those can only be used internally.
Get a certificate and private key from external sources
It is possible to get valid certificates and private keys from clients or other teams in your company, who can generate and sign certificates. However you should know, this is not the most secure way to do this, since someone else generated the private key and handed it over to you, and you can’t be sure that no one else has it.
I’m only talking about this because, in my professional career, I’ve seen many cases where this happened. Maybe you are a managed service provider for your clients, and your client’s security department needs to have their private key in their system, so they would just hand it over to you.
In this case, you should receive the certificate file, the chain file with intermediate and root certs, and the private key. You need to upload these into the BIG-IP, so later on you can use it for your HTTPS virtual server.
From the dropdown menu, select Certificate, give it a meaningful name, and either upload the file you received or paste the certificate, if you received it in a text format. The easiest way is that if you received the certificate and the whole chain in text format, then you can just paste all of them here in the same window. Just make sure you paste in the right order: SSL certificate — intermediate certificate — root certificate
Do the same steps for the private key as well. Probably the easiest way is if you name the private key the same as the certificate in the previous step. Again, either you upload the file or paste the private key in text format.
Now you have successfully added a certificate, a chain, and a key to the BIG-IP. Later in this tutorial, you can see how to add it to an SSL profile, so your website would be able to use the certificate.
Generate a certificate signing request on the BIG-IP
Compared to the previous section, there is a more secure way to get a certificate into a BIG-IP load balancer. It is called creating a Certificate Signing Request (CSR). With this method, the load balancer will generate a private key and a CSR with the details you provide (Common Name, Subject Alternative Name, Company, etc.), and then you send this CSR to the Certificate Authority (either internal one in the company, or an external one, like DigiCert) to sign it.
This is the safest way to do this since the private key is generated on the load balancer, no one else can access it. Let’s see this in action. Go to System / Certificate Management / Traffic Certificate Management / SSL Certificates List, then click on Create.
You will see a form, where you need to fill in the details. Give it some meaningful name. Then you need to pick an issuer. It can be Self (the load balancer will generate a self-signed certificate), or Certificate Authority, for external CAs. Since this is usually the way in production environments, you will choose CA.
Fill in the other details, like Common Name, Organization, and whichever applies to your environment. Make sure you fill in the Subject Alternative Name (SAN) section, if you would like to use the same certificate for other websites as well. Also, you can change the Key Size, if you want. Then click on Finish.
After that, you will see the CSR is ready to copy as a text or to download as a file. Your next step is to send this CSR to your Certificate Authority (DigiCert, VeriSign, etc). You can notice, at this point, the load balancer only has the private key and the CSR in the configuration.
Once you get the signed certificate from the Certificate Authority, you can upload it to the load balancer. Select the certificate object from the main SSL Certificate List, then click on Import.
Upload the certificate file you got from the CA, or paste it if you received it in text format. Usually, CAs provide the certificate, the intermediate, and root certs in text format as well, so feel free to paste all of these three in the same window.
After successful upload, you can notice the load balancer now shows it has an RSA Certificate, and an Expiry Date as well.
Now you have the signed certificate on the load balancer. Let’s explore the further steps of how to operate with these certificates.
Related: How to Upgrade F5 BIG-IP Software
SSL changes on F5 BIG-IP with existing certificates
Create a new SSL profile for a new certificate
To use a certificate in our load balancer virtual server, you need an SSL profile. Most of the time this would mean a Client SSL Profile since you would like to provide the certificate to your visitors, your clients.
Click on Local Traffic / Profiles / SSL / Client / Create. On the next page, give it some meaningful name (I would recommend somehow adding the “ssl” and “client” keywords into the name as well since it would be useful once you have hundreds of objects in your load balancer. Click on Add to specify our certificate, chain, and key details.
Now you have to specify your certificate, key, and chain. Since you have all of these under the same certificate object, you can find the same name in all three dropdown lists. There was no passphrase specified during the CSR creation, so you can leave the Passphrase section empty.
Once you are done with that, you can see these details in our new SSL profile. Go to the bottom and click on Finished to save this new Client SSL Profile.
Now you can go to Local Traffic / Virtual Servers / Virtual Server List to find our specific Virtual Server, so you can set up the new Client SSL profile, so the load balancer can start using the certificate for the HTTPS traffic. Scroll down to the SSL Profile (Client) section, and select our newly created SSL profile.
Replace an expiring SSL certificate
Replacing an expiring or expired certificate is very easy in BIG-IP load balancers, due to the system setup. It is a no-impact procedure, since during the replacement activity, the BIG-IP will keep every existing connection as it is with the old certificate until they are torn down, and it will establish new connections with the new certificate. So end clients won’t notice any outage during this process.
There are a couple of ways to renew a certificate.
If it is from external sources, and if you have the new certification and key, you can upload them to the BIG-IP as separate certificate objects (old object name, for example, wildcard-example.com-2023, then you can upload the new with new name wildcard-example-2023-v2). Then you just change the certificate, key, and chain under the Client SSL profile.
If it is signed by the Certificate Authority, then you need to create a new CSR. Here you have two options:
- Create CSR with existing key
- Create CSR with a new key
Some CAs allow certificate renewal/CSR with existing keys, some don’t. Eventually, CSRs with existing keys are the less secure way, and most CAs recommend generating new private keys during the renewal process.
If you want to renew with an existing key, then visit the certificate object under System / Certificate Management / Traffic Certificate Management, then click on Renew button.
That will create a CSR with the same data (Common Name, Organization, etc.), so you can just follow the same procedure from earlier in this article. Send the CSR to the Certificate Authority, and once you get back the new signed certificate, you can open the old certificate object, and just click on Import. This will overwrite the old certificate with the new one but without any traffic drop or outage.
If you want to do the more secure way, you can generate a completely new CSR and private key by following the procedure in this article – Generate a certificate signing request on the BIG-IP
Then you will need to replace the old certificate, key, and chain under the Client SSL profile as described earlier, which is again a no-impact procedure.
Related: F5 BIG-IP CLI Commands Cheat Sheet
