Modify the device certificate¶

This page documents the f5insight-device-cert utility and common workflows for managing the device certificate used by F5 Insight.

Overview¶

Use f5insight-device-cert when you need to create, replace, or recover the certificate presented by the platform. The utility supports both RSA and ECDSA key algorithms.

Primary use case: Create a self-signed certificate¶

Use this workflow when you need to quickly provision a fresh certificate with explicit subject and Subject Alternative Name (SAN) values.

Before you start¶

Run these commands from the F5 Insight host console or over Secure Shell (SSH).
Confirm the certificate names and SAN entries you need.
The utility updates Kubernetes secrets directly:
- Primary secret: kube-system/default-ingress-cert
- Backup secret: kube-system/default-ingress-cert-backup

Example command¶

sudo f5insight-device-cert create-self-signed \
  --cn "f5insight-api.example.com" \
  --type server \
  --days 365 \
  --san "DNS:f5insight-api.example.com,IP:192.0.2.54"

If your build uses different flags, run:

f5insight-device-cert --help

Verify the change¶

Confirm the secret exists in Kubernetes:

kubectl -n kube-system get secret default-ingress-cert

Confirm the backup secret was created or updated:

kubectl -n kube-system get secret default-ingress-cert-backup

Validate certificate details from the secret:

kubectl -n kube-system get secret default-ingress-cert -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Common additional use cases¶

Generate a certificate and key¶

sudo f5insight-device-cert generate-cert-and-key \
  --cn "f5insight-api.example.com" \
  --type server \
  --key-algorithm rsa \
  --key-size 4096 \
  --days 730 \
  --org "F5 Networks" \
  --ou "F5 Insight Services" \
  --country US \
  --state "Washington" \
  --locality "Seattle" \
  --san "DNS:f5insight-api.example.com,DNS:api.f5insight.local"

Create an ECDSA certificate¶

Use --key-algorithm ecdsa with --key-curve to generate a certificate that uses an ECDSA key instead of RSA. Valid curves are P-256 (default), P-384, and P-521.

sudo f5insight-device-cert create-self-signed \
  --cn "device.example.com" \
  --key-algorithm ecdsa \
  --key-curve P-256

For a certificate authority (CA) certificate, use a stronger curve:

sudo f5insight-device-cert create-self-signed \
  --cn "F5 Insight Root CA" \
  --type ca \
  --key-algorithm ecdsa \
  --key-curve P-521 \
  --days 3650

Generate a CSR¶

sudo f5insight-device-cert generate-csr \
  --cn "f5insight-api.example.com" \
  --csr-out /tmp/f5insight-device.csr

Import a signed certificate¶

sudo f5insight-device-cert import-cert \
  --cert-file /tmp/f5insight-device.crt

Import a certificate chain (leaf and intermediates)¶

When importing a certificate authority (CA)-issued certificate, provide a PEM bundle in this order:

Device or leaf certificate first.
Intermediate CA certificates next (closest signer first).
Root CA last only if your environment explicitly requires it (commonly omitted).

The script validates only the first certificate in the file against the private key. This means the leaf certificate must be the first PEM block in --cert-file.

Build a chain bundle (example):

cat device.crt intermediate1.crt intermediate2.crt > /tmp/f5insight-device-chain.pem

Import the chain while preserving the existing key in Kubernetes:

sudo f5insight-device-cert import-cert \
  --cert-file /tmp/f5insight-device-chain.pem

If you also need to replace the private key, pass --cert-key:

sudo f5insight-device-cert import-cert \
  --cert-file /tmp/f5insight-device-chain.pem \
  --cert-key /tmp/f5insight-device.key

Validate bundle order before import¶

awk 'BEGIN{c=0} /BEGIN CERTIFICATE/{c++} {print > ("/tmp/cert-" c ".pem")}' /tmp/f5insight-device-chain.pem
openssl x509 -in /tmp/cert-1.pem -noout -subject -issuer

Confirm the first certificate is your device certificate (CN or SAN for your endpoint), not an intermediate CA.

Manual rollback¶

sudo f5insight-device-cert rollback

Troubleshooting¶

If the command fails, rerun with sudo and verify Kubernetes access from the host.
If clients still see the old certificate, verify ingress and controller reload timing.
If SAN validation fails, confirm SAN values match the hostname and management IP clients use.
If import-cert fails, verify the certificate is in PEM format and compatible with the existing private key.

Previous Next