Modifying 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.

Primary Use Case: Create Self-Signed Certificate¶

Use this workflow when you need to quickly provision a fresh certificate with explicit subject and SAN values.

Before You Start¶

Run these commands from the F5 Insight host console or over 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, check:

f5insight-device-cert --help

Verify The Change¶

Confirm the secret exists in Kubernetes:

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

Confirm 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 Certificate And Key¶

sudo f5insight-device-cert generate-cert-and-key \
  --cn "f5insight-api.example.com" \
  --type server \
  --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"

Generate CSR¶

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

Import Signed Certificate¶

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

Import Certificate Chain (Leaf + Intermediates)¶

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

Device/leaf certificate first
Intermediate CA certificate(s) 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/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/controller reload timing.
If SAN validation fails, make sure SAN values match the hostname and management IP clients use.
If import-cert fails, verify the certificate is PEM format and compatible with the existing private key.
If import-cert fails with key mismatch, confirm the first certificate in the chain matches the private key (leaf cert must be first).

Previous Next