aethercert
Documentation

Replace an SSL Certificate on F5 BIG-IP

Replace an SSL certificate and key on F5 BIG-IP via GUI (Overwrite Existing) or tmsh, update the Client SSL profile, save, sync the device group and verify every virtual server.

BIG-IP stores certificates and private keys as named objects. A Client SSL profile references a certificate, key and chain (its certificate key chain), and a virtual server references the profile. That gives two ways to replace a certificate:

WayWhenWhat changes
Overwrite the existing objectsEvery profile that uses the certificate should switch at onceCertificate and key objects keep their names; profiles are untouched
Import under new namesSwitch profiles one at a time, or keep the old certificate side by sideNew objects; each Client SSL profile is changed to them

Before you begin

  • Record the partition (usually /Common), the certificate, key and chain object names, every Client SSL profile that uses them (including SNI profiles), the virtual servers, and the name and sync status of the device group (Device Management > Overview).
  • Make the change on one device of the device group - normally the one you always manage from - and sync it to the others afterwards.
  • Back up the configuration as a UCS archive (System > Archives > Create, or tmsh save sys ucs /var/local/ucs/before-cert.ucs) and keep a copy of the current certificate and key files - the UCS backup is your rollback.
  • Prepare the new certificate (PEM), its private key and the intermediate chain (PEM). Copy files for tmsh to the BIG-IP, for example with scp to /var/tmp.

Way 1: overwrite the existing objects

The certificate and key objects keep their names, so every profile that uses them switches at once. Certificate and key must always match: a profile rejects a certificate that does not belong to its key. Replace both together.

In tmsh, do it in one transaction so the pair never mismatches:

tmsh
create cli transaction
install sys crypto key www-wildcard from-local-file /var/tmp/www-2026.key
install sys crypto cert www-wildcard from-local-file /var/tmp/www-2026.crt
submit cli transaction
save sys config
quit

www-wildcard is the name of the existing objects. Add passphrase '<passphrase>' to the key command for an encrypted key. If the intermediate changed, install it the same way over the existing chain object.

In the Configuration utility: go to System > Certificate Management > Traffic Certificate Management > SSL Certificate List > Import. Import the key with Import Type Key and Key Name Overwrite Existing (select the existing key), then the certificate with Import Type Certificate and Certificate Name Overwrite Existing (select the existing certificate). Import a changed intermediate the same way.

Way 2: import under new names

  1. Import key, certificate and - if changed - the chain under new names, in the GUI with Create New instead of Overwrite Existing, or in tmsh:

    tmsh install sys crypto key www-2026 from-local-file /var/tmp/www-2026.key
    tmsh install sys crypto cert www-2026 from-local-file /var/tmp/www-2026.crt
    tmsh install sys crypto cert intermediate-2026 from-local-file /var/tmp/intermediate-2026.crt
  2. Point each Client SSL profile at the new objects. In the GUI: Local Traffic > Profiles > SSL > Client > profile > Certificate Key Chain, replace the entry and click Update. In tmsh:

    tmsh modify ltm profile client-ssl www-clientssl cert-key-chain replace-all-with { default { cert www-2026 key www-2026 chain intermediate-2026 } }
    tmsh save sys config

    replace-all-with replaces every entry of the profile. If the profile carries both an RSA and an ECDSA certificate, list both entries, or change the profile in the GUI.

  3. Repeat for each profile. The old objects stay until you delete them.

Then: sync the device group

In a Sync-Failover device group, synchronize from the device you changed to the group: Device Management > Overview, select the device and Sync Device to Group, or:

tmsh run cm config-sync to-group <device-group-name>

Check that every device shows In Sync. A change on one device is not on its peers until the sync succeeds.

Never overwrite the built-in default certificate and key - other configuration relies on them.

Product-specific considerations

A Client SSL profile can carry separate RSA and ECDSA certificate key chains, and SNI can select a different profile than the default one on the virtual server - so test the exact hostnames clients use. New TLS connections use the new certificate; existing connections keep the session they negotiated. The BIG-IP management (Configuration utility) certificate is a separate device certificate and is not replaced by changing traffic certificates.

Verify the new certificate

Check the certificate object (expiry, subject) in the SSL Certificate List and each profile's certificate key chain, then connect to every virtual server hostname:

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

Check subject and SAN, issuer, expiry date and that the intermediate is sent. If a hostname still shows the old certificate, find which Client SSL profile answers for it (SNI server name) and check that profile's certificate key chain. Confirm In Sync on all devices, and test once more after a failover.

Rollback

  • After overwriting: overwrite certificate and key again with the saved old files (in one transaction), save and sync.
  • After new names: select the old certificate key chain in each Client SSL profile again, save and sync.
  • If in doubt: restore the UCS archive (System > Archives); restoring reloads the configuration.

Common problems

  • Certificate and key were overwritten separately and no longer match.
  • A Client SSL profile still references the old objects.
  • The change was made in the wrong partition, or the config sync failed.
  • An SNI profile or a second certificate key chain serves a different certificate than the one you changed.
  • replace-all-with removed the profile's second (ECDSA or RSA) entry.
  • The built-in default certificate was overwritten.

Automating certificate replacement with aethercert

The aethercert F5 BIG-IP target uploads and creates or updates named certificate and key objects through iControl REST. When a Client SSL profile is configured on the target, it updates that profile to reference them.

See Deploy targets for the fields this preset takes, what it needs on the host, and how far it has been verified.

Sources

On this page