Welcome to the first article in a comprehensive series dedicated to administrating F5 BIG-IP systems through the power of the iControl REST API. This series is designed for both beginners and experienced network administrators who want to streamline their F5 management workflows and embrace infrastructure-as-code principles.
Throughout this series, we will explore practical, real-world scenarios for managing F5 BIG-IP appliances programmatically. Rather than relying solely on the F5 web interface, we’ll leverage the iControl REST API.
To make this journey accessible and efficient, I’ll be using Restsh, my open-source command-line interface tool. Restsh is purpose-built to simplify interactions with the iControl REST API, abstracting away complexity while maintaining full flexibility. Whether you’re new to F5 REST API or looking to enhance your automation skills, these tutorials will provide clear, step-by-step guidance with practical examples you can implement immediately.
In this workflow, you’ll create the certificate materials on the F5, have them signed by a trusted Certificate Authority (in this case, HashiCorp Vault), and then deploy the signed certificate back to the F5. This process ensures that the private key never leaves the F5.
Initial configuration of Restsh
See First Steps for the initial configuration of Restsh.
Connect
Connect to the F5 with Restsh:
- restsh
- Select your F5
1. Create a key pair and signing request (CSR) on the F5
The first step is to create a key pair and a Certificate Signing Request (CSR) on the F5. A key pair consists of a private key (which stays secret on the F5) and a public key. The CSR contains the public key and certificate details that will be sent to a Certificate Authority (CA) for signing.
Below are the certificate parameters we’ll use for this example:
- Name on the F5: test.lab.lan
- Partition: Common
- CN: test.lab.lan
- Subject Alternative Names: test.lab.lan, test2.lab.lan
- Keytype: EC with SECP384R1
f5.cert.csr.create --cn=test.lab.lan --keytype=ec-private --curvename=secp384r1 -a test.lab.lan -a test2.lab.lan -n test.lab.lan
2. Download the signing request
The next step is to download the Certificate Signing Request from the F5 to your local machine. This file contains the public key and certificate information that needs to be signed by the Certificate Authority. We’ll save it to a temporary directory for processing.
f5.cert.csr.get /Common/test.lab.lan > "$RESTSH_TMP/test.lab.lan.csr"
You can inspect the details of the CSR to verify it contains the correct information (domain names, key type, etc.). The cert.* commands are convenient wrapper scripts for the OpenSSL command-line tool, making certificate operations easier.
cert.csr.show "$RESTSH_TMP/test.lab.lan.csr"
You can also view the public key contained in the CSR:
cert.csr.pubkey "$RESTSH_TMP/test.lab.lan.csr"
3. Sign the CSR with HashiCorp Vault
Now we use HashiCorp Vault to sign the CSR. Vault acts as your Certificate Authority (CA) and will create a signed certificate based on your CSR. First, you authenticate with Vault using vault login, then you submit the CSR for signing.
The vault write command sends your CSR to the Vault PKI backend, which signs it and returns a complete certificate. In this example, we’re using the signing backend/role pki/sign/lab-ca (adjust this to match your Vault configuration).
vault login
vault write -field=certificate pki/sign/lab-ca csr=@"$RESTSH_TMP/test.lab.lan.csr" > "$RESTSH_TMP/test.lab.lan.crt"
After signing, you can verify the certificate details to ensure it was signed correctly and contains the expected information (domain names, validity period, key type, etc.):
cert.x509.show "$RESTSH_TMP/test.lab.lan.crt"
You can also view the public key in the signed certificate to confirm it matches the public key from the CSR:
cert.x509.pubkey "$RESTSH_TMP/test.lab.lan.crt"
4. Upload the signed certificate to the F5
Finally, we upload the signed certificate back to the F5. This makes the certificate available for use in SSL profiles. We use the same certificate name that we used when creating the CSR, so the F5 knows to pair it with the private key we created in step 1.
f5.cert.import /Common/test.lab.lan "$RESTSH_TMP/test.lab.lan.crt"
You can view the imported certificate with following command:
f5.cert.get /Common/test.lab.lan
5. Cleanup
Cleanup is optional the files in the temporary directory will be automatically removed after Restsh finishes. However, if you want to manually remove the CSR and certificate files from your local machine, you can do so with the following command:
rm "$RESTSH_TMP/test.lab.lan.csr" "$RESTSH_TMP/test.lab.lan.crt"
Optionally sync the F5 cluster to ensure the new certificate is available on all cluster members. “failover” is here the name of the Sync-Failover device group.
f5.cluster.config-sync failover
Summary
In this tutorial, we walked through the process of deploying a new certificate on an F5 device using Restsh and HashiCorp Vault. We created a key pair and CSR on the F5, signed the CSR with Vault, and then imported the signed certificate back to the F5. This workflow allows you to securely manage certificates without exposing private keys, while leveraging the power of Restsh for automation and integration with your existing infrastructure.