How to Install an SSL Certificate on F5 BIG-IP

Why BIG-IP wants three objects instead of one bundle

BIG-IP models a certificate as three independent items in its configuration: a certificate object, a key object, and a second certificate object that carries the issuing chain. Nothing joins them on disk. The join happens in a Client SSL profile, which names all three, and that profile is what a virtual server actually uses. If you arrive from Nginx or HAProxy expecting to concatenate files, this is the thing to unlearn first.

The habit transfers badly. On an Nginx box you paste the leaf and the intermediates into one file and Nginx serves whatever it finds there. Do the same on a BIG-IP and it will import happily, show no error, and serve only the leaf. F5’s own guidance on chain certificates makes the point the other way round: you do not need to merge anything, because the system imports certificate, key and chain as separate objects and assembles them in the profile.

There is a reason to like the model once you stop fighting it. Because the chain is its own object, one imported CA bundle can be referenced by every profile on the box, so when your CA rotates an intermediate you replace one object rather than re-pasting a file into forty places. The same goes for the leaf at renewal, which is the trick in the renewal section below.

Generating the CSR on the BIG-IP itself

Generate the key and the CSR on the appliance that will serve the traffic. The private key is created there and never leaves, which is both the security argument and the reason the CA has no key to send back to you. In the GUI the path is System › Certificate Management › Traffic Certificate Management › SSL Certificate List › Create. From the shell, one tmsh command does key and CSR together:

tmsh create sys crypto key www.example.com_2026 \
  gen-csr \
  key-size 2048 \
  common-name www.example.com \
  organization "Example Ltd" \
  country DE \
  subject-alternative-name "DNS:www.example.com, DNS:example.com"

Two notes on that command. The key-size parameter still accepts 512 and 1024, values a public CA has not been permitted to sign for years, so treat 2048 as the floor rather than a default you can drift below. And put every hostname you intend to serve into subject-alternative-name at this point, including the bare domain if visitors reach you without the www. Names are fixed when the CSR is signed; discovering a missing one later means a reissue.

The CSR then goes to the CA. Domain validation can complete in minutes, but organization and extended validation involve a human checking your company against public records, and that stretches to days. For anything in front of a production virtual server, order before the old certificate is inside its last fortnight. If you are choosing the validation level for a load-balanced service in the first place, our side-by-side comparison of DV, OV, EV and wildcard certificates lays out what each one verifies and how long it takes to issue.

Importing the certificate, the key and the chain

Import three times, once per object. In the GUI, open System › Certificate Management › Traffic Certificate Management › SSL Certificate List, click Import, and set Import Type to Certificate for your signed leaf, to Key for the key if it was generated elsewhere, and to Certificate again for the CA bundle under a separate name. Each import takes either an uploaded file or pasted PEM text.

From the shell the equivalent is three install commands against files you have already placed on the appliance, conventionally under /var/tmp:

tmsh install sys crypto cert www.example.com_2026 from-local-file /var/tmp/example.crt
tmsh install sys crypto key  www.example.com_2026 from-local-file /var/tmp/example.key
tmsh install sys crypto cert CA_Intermediate_2026  from-local-file /var/tmp/ca-bundle.crt

tmsh list sys crypto cert www.example.com_2026

Naming is worth thirty seconds of thought, because these names are what you will read in a profile at 2am eighteen months from now. Put the year in: www.example.com_2026 tells you at a glance which object is current, where wildcard or newcert tells you nothing and makes a second engineer guess. Keep leaf and key names identical to each other so a mismatch is visible rather than inferred.

One import that surprises people: a file holding several PEM blocks becomes one certificate object, not several. That is exactly what you want for the chain object, where the whole CA bundle belongs in a single import. It is not what you want for the leaf. If your CA delivered the leaf and the intermediates together in one .crt, import that file as the chain and import the leaf from a file of its own, so the profile’s Certificate field holds your certificate alone.

Assembling the Client SSL profile and attaching it

A Client SSL profile is where the three objects become one usable certificate, and attaching that profile to a virtual server is what puts it on the wire. Create the profile under Local Traffic › Profiles › SSL › Client, switch the Configuration dropdown from Basic to Advanced, and fill the Certificate Key Chain with your certificate, your key, and your chain. Then add the profile to the virtual server’s SSL Profile (Client) list.

Since BIG-IP 12.0.0 the profile holds a Certificate Key Chain rather than a single trio of fields, and you can add one entry per key type. That is how an RSA and an ECDSA certificate live in the same profile and let the BIG-IP hand each client whichever it negotiated, which is the practical reason to care about the difference between ECC and RSA certificates on a device terminating at volume.

tmsh create ltm profile client-ssl example_clientssl_2026 \
  cert-key-chain replace-all-with {
    rsa_2026 {
      cert www.example.com_2026
      key  www.example.com_2026
      chain CA_Intermediate_2026
    }
  }

tmsh modify ltm virtual vs_example_https profiles add { example_clientssl_2026 }
tmsh save sys config

Do not skip tmsh save sys config. The change is live the moment you make it, and it is also only in memory until you save; a reboot before the save takes your certificate with it. This is the single most common way a BIG-IP install that “worked yesterday” is gone on Monday.

One trap with an ugly signature: changing a profile’s parent profile resets the certificate, key and chain to whatever the parent holds. If you built the profile, attached it, then went back and switched the parent to inherit some cipher setting, check the Certificate Key Chain again before you leave. It will be empty, and the virtual server will be presenting the default certificate.

The chain field, and why curl fails when Chrome does not

An empty Chain field makes the virtual server send your leaf certificate and nothing else. Desktop browsers usually survive that, because they cached your CA’s intermediate the first time they met it on some other site and can rebuild the path without help. Clients that carry only root certificates cannot: curl reports unable to get local issuer certificate, Java throws a PKIX path-building error, Android apps and monitoring probes just fail.

That asymmetry is what makes the bug expensive rather than merely annoying. The engineer who ran the install tests in a browser, sees a padlock, and closes the change ticket. The report arrives four days later from whoever owns the mobile app or the partner integration, by which time nobody is thinking about the load balancer. Anyone who has worked a support queue for certificates recognises the shape of it: a “works for me, broken for them” ticket is an incomplete chain until proven otherwise.

The chain object itself should hold the intermediates only. Root certificates are already in every client’s trust store, and including yours adds bytes to every handshake for no benefit. If the mechanics of path building are new to you, our guide to how the certificate chain is built and where it breaks covers why a client can reject a certificate that is entirely valid.

Several certificates on one virtual server

One virtual server can present a different certificate per hostname. Since BIG-IP 11.1.0 you attach several Client SSL profiles to the same virtual server, one per site, and the system chooses between them per connection using the Server Name Indication value the client sends in its ClientHello. Exactly one of those profiles has to carry the Default SSL Profile for SNI flag, which is the fallback for clients that send no SNI or a name nothing matches.

The matching itself is a ladder, and knowing its order saves an afternoon. According to F5’s profile-selection guidance, on BIG-IP 13.0.0 and later the system first compares the requested hostname against the server-name configured on each profile, then against the subject alternative names in each profile’s certificate, then against the common name, and only if none of those match does it fall back to the profile flagged as the SNI default.

tmsh modify ltm profile client-ssl shop_clientssl_2026 server-name shop.example.com
tmsh modify ltm profile client-ssl www_clientssl_2026  sni-default true

tmsh modify ltm virtual vs_example_https profiles add { shop_clientssl_2026 }

Because the ladder falls back instead of failing, a misconfiguration here shows up as the wrong site answering with a perfectly valid certificate rather than as an outage, and that is harder to notice. F5’s own advice is to give each SNI profile certificates with distinct names, which in practice means being careful with a wildcard that overlaps a specific host.

Worth weighing before you build the ladder at all: if every hostname sits under one domain, one wildcard certificate collapses the whole arrangement into a single profile with one renewal date. Where the names span unrelated domains, a multi-domain certificate does the same job differently. Both trade granularity for far fewer objects to renew, and on a 200-day clock that trade has got more attractive.

Offload, bridge, or pass through

A Client SSL profile handles the client side: the BIG-IP decrypts incoming HTTPS and encrypts the replies. A Server SSL profile handles the other side, where the BIG-IP acts as a TLS client to your pool members and re-encrypts before forwarding. Attach only the first and you have offloading, with plaintext on the internal hop. Attach both and you have bridging, with the crypto work paid twice and nothing readable on the wire.

The useful detail is that bridging usually costs you a profile rather than another certificate. A Server SSL profile does not have to present a certificate of its own; the default profile can simply re-encrypt to the backend. You only need a certificate there if the pool member demands client authentication, which is its own design decision covered in our guide to mutual TLS. Whether the backend certificate needs to be publicly trusted is a separate question again, and for an internal hop it generally does not.

Card and health environments tend to require the bridged form, so if you are installing a certificate to satisfy an auditor rather than a browser, check which of the three lanes the requirement actually describes before you decide the job is finished. Our overview of TLS termination and re-encryption goes through the security trade-off of each.

Renewing without downtime, and what 200 days changed

Import the renewed certificate under the same object name as the one it replaces and it overwrites in place, which means every profile pointing at that name picks up the new certificate with no profile edit and no virtual server change. New connections get the new certificate; sessions already open keep the old one until they close. There is no restart and no maintenance window.

That trick is convenient and it cuts against the other piece of good practice. F5 recommends generating a fresh CSR and private key at renewal rather than reusing the CSR on file, because reusing it keeps the existing key alive for another term. Both things can be true: generate a new key and CSR under a new name for the audit trail, or overwrite the existing names to keep the profile untouched. Pick one deliberately per service rather than discovering which you did last time.

The pressure behind all of this is the CA/Browser Forum schedule in ballot SC-081v3. The maximum lifetime of a public TLS certificate dropped to 200 days on 15 March 2026, falls to 100 days on 15 March 2027, and reaches 47 days on 15 March 2029. A ritual you performed once a year becomes quarterly in 2027 and roughly every six weeks in 2029. Our walkthrough of preparing for 47-day certificates covers the inventory work that has to happen before the automation does.

Two BIG-IP specifics to plan around. Old objects are not cleaned up for you, so an appliance that has been renewed by hand for five years accumulates certificates nobody dares delete; name by year and prune deliberately. And a certificate expiring is not the only clock — an OV or EV certificate also carries organization data that the CA has to re-verify on its own schedule, which our note on organization revalidation explains.

Native ACME from 21.1.0, and what to do before that

BIG-IP 21.1.0 is the first Classic BIG-IP release with native ACMEv2 support, using the HTTP-01 challenge, and it has been generally available since June 2026. Before that release there is no built-in ACME client and no direct Let’s Encrypt integration on the appliance, so on 17.1.x and earlier the certificate is obtained by something outside the BIG-IP and then imported. That is the whole of the difference, and it decides how much work the shrinking lifetimes cost you.

On a pre-21.1.0 box the working pattern is an external client such as certbot or acme.sh that completes the challenge, followed by a scripted import over tmsh or iControl REST. F5’s DevCentral community maintains scripted versions of exactly that loop, and the same shape works with a commercial CA that supports ACME. Whichever you use, the import step is the one to test first, since a renewal that succeeds at the CA and fails at the import is indistinguishable from no renewal at all.

HTTP-01 is also a constraint worth checking before you commit. The challenge needs port 80 reachable on the name being validated, which is awkward on a virtual server that only listens on 443 or sits behind a strict firewall policy. Where that does not fit, DNS-based validation through an external client is the usual answer; our comparison of the ACME challenge types sets out what each one needs. And if an OV or EV certificate is required for the service, automation does not remove the human validation step — it only removes the copying.

Proving it from outside the BIG-IP

Check the install from a client the BIG-IP has never seen, not from the GUI that told you the import succeeded. The one command that answers the chain question directly asks for the certificates the server actually sent, with the hostname passed explicitly so you exercise the same SNI path a real browser would:

openssl s_client -connect www.example.com:443 \
  -servername www.example.com -showcerts </dev/null

# Expect two or more certificates in the output, s:/i: forming a path
# from your hostname up to a CA you recognise. One certificate alone
# means the Chain field is empty.

Count the certificates in that output. One means an empty chain, whatever the browser says. Two or more, with each subject matching the next issuer, means the path is complete and a cold client will build it. Run the same command against every hostname on a multi-profile virtual server, because SNI means each name can be answered by a different profile with its own mistakes.

Then check from outside your own network, where a caching resolver, a corporate proxy and a helpfully-configured laptop cannot flatter the result. Our SSL certificate checker reports the chain, the expiry date and the names on the certificate from a third-party vantage point, which is the last thing worth doing before the change ticket closes.

Add the expiry date to whatever already pages your team. On a 200-day lifetime a missed renewal is a 200-day-cycle mistake you get to make twice a year instead of once, and the outage it causes looks nothing like a certificate problem from the outside: the service is up, the load balancer is healthy, and every client refuses to talk to it. Our guide to monitoring certificates before they expire covers what to watch and how far ahead.

FAQ