How to monitor F5 BIG-IP SSL certificate expiry with API

For many organizations, the F5 BIG-IP platform is the cornerstone of application delivery, handling everything from load balancing to advanced security. Critical to its operation are the SSL/TLS certificates that secure your applications and services. When these certificates expire unexpectedly, the consequences can range from service disruptions and angry customers to significant security vulnerabilities.

While the F5 BIG-IP offers robust capabilities, monitoring the expiry dates of its numerous SSL/TLS certificates across various configurations isn't always straightforward. Relying on manual checks or hoping for the best is a recipe for disaster. This article will dive into how you can leverage the F5 iControl REST API to programmatically monitor your BIG-IP SSL certificates, ensuring you're alerted well before an expiry causes an outage.

Why F5 BIG-IP Certificates Are Tricky to Monitor

F5 BIG-IP devices can house certificates in several locations and contexts, making comprehensive monitoring a challenge:

  • Client SSL Profiles: These are the most common and often most critical. They terminate client-side SSL connections and decrypt traffic before passing it to backend servers. Each profile can have its own certificate and key.
  • Server SSL Profiles: Used for re-encrypting traffic to backend servers. These profiles might use internal CAs or publicly trusted certificates.
  • BIG-IP System Certificates: Certificates used for the BIG-IP's own management interface, inter-device communication (e.g., device trust in a HA pair), or for signing internal components.
  • Data Group Lists: Sometimes certificates or certificate hashes are stored within data group lists for specific security policies or validations.
  • File System: Certificates can also exist as standalone files within the F5's file system, potentially used by iRules, custom scripts, or other services.
  • Partitioning: Certificates can reside in different administrative partitions (e.g., Common, Production, Development), requiring specific access and traversal.
  • Dynamic Nature: Certificates are often updated by different teams, through various processes (manual uploads, API calls, config syncs), making a centralized inventory difficult to maintain without automation.

The F5 GUI provides some visibility, but manually navigating through dozens or hundreds of profiles across multiple F5 devices to check expiry dates is tedious, error-prone, and not scalable. This is where the iControl REST API becomes indispensable.

Leveraging the F5 iControl REST API

The F5 iControl REST API provides a powerful, programmatic interface to manage and monitor almost every aspect of your BIG-IP device. It's the modern way to interact with F5, offering significant advantages over older methods like iControl SOAP or tmsh scripting for automation and integration.

To use the API, you'll need:

  • Network Access: Your monitoring system needs network reachability to the F5 BIG-IP's management IP address on port 443 (or your configured iControl REST port).
  • Authentication: You'll typically use HTTP Basic Authentication with a local F5 user account. For production systems, it's best practice to create a dedicated service account with the minimum necessary permissions (e.g., auditor role might be sufficient for read-only access, but guest or a custom role might be more appropriate depending on the exact API calls). You can also use authentication tokens for more secure, session-based access.

The base URL for most iControl REST API calls is /mgmt/tm/.

Practical Steps: Monitoring Client SSL Profile Certificates

Client SSL profiles are often the most critical certificates to monitor, as their expiry directly impacts your public-facing applications. These profiles typically contain both a certificate and its corresponding private key.

Here's how you can fetch this information using curl:

  1. List all Client SSL Profiles: First, you need to get a list of all client SSL profiles configured on your BIG-IP.

    bash curl -sku 'admin:your_password' \ https://your_f5_management_ip/mgmt/tm/ltm/profile/client-ssl \ | jq '.items[] | {name: .name, partition: .partition, fullPath: .fullPath}'

    • your_f5_management_ip: Replace with the actual IP address or hostname of your F5 BIG-IP.
    • admin:your_password: Replace with your F5 username and password. Consider using an authentication token for production environments.
    • jq: A powerful command-line JSON processor. It helps make the output readable.

    The output will give you a list of profiles, for example: json { "name": "my_app_ssl_profile", "partition": "Common", "fullPath": "/Common/my_app_ssl_profile" } { "name": "another_app_profile", "partition": "Apps", "fullPath": "/Apps/another_app_profile" }

  2. Retrieve Certificate Details for a Specific Profile: Once you have the fullPath of a profile (e.g., /Common/my_app_ssl_profile), you can query its details. We're particularly interested in the serverCertificate field, which holds the certificate content in PEM format.

    bash curl -sku 'admin:your_password' \ https://your_f5_management_ip/mgmt/tm/ltm/profile/client-ssl/~Common~my_app_ssl_profile \ | jq -r '.serverCertificate'

    Pitfall: Not every client SSL profile directly stores the certificate content in serverCertificate. Some profiles might reference a certificate that's stored separately in the F5's file system (e.g., cert and key fields pointing to /Common/mycert.crt and /Common/mykey.key). In such cases, serverCertificate might be empty, or contain a relative path. You'll need to adapt your logic to fetch those referenced files from the /mgmt/tm/sys/file/ssl-cert and /mgmt/tm/sys/file/ssl-key endpoints respectively. This complexity highlights why a robust monitoring system needs to account for different configuration patterns.

    If the serverCertificate field does contain the certificate content, it will be a base64-encoded PEM string.

  3. Decode and Extract Expiry Date: Assuming you've retrieved the base64-encoded PEM string, you'll need to decode it and then use OpenSSL to get the expiry date.

    ```bash

    Example: Store the base64 output from jq into a variable

    CERT_B64="-----BEGIN CERTIFICATE-----\nMIIGizCCBfOgAwIBAgIQD...=\n-----END CERTIFICATE-----"

    Decode the base64 and pipe to openssl

    echo -e "$CERT_B64" | openssl x509 -noout -enddate ```

    The output will be something like: notAfter=Dec 31 23:59:59 2024 GMT. You can then parse this date in your script to determine how many days are left until expiry.

Practical Steps: Monitoring Certificates in the F5 File System

Beyond client SSL profiles, F5 BIG-IP also stores certificates in its internal file system. These might be used for various purposes, including server SSL profiles, internal services, or even certificates uploaded