Mutual TLS (mTLS) Configuration on F5

This article guides you through the process of configuring Mutual TLS (mTLS) on your F5 BIG-IP system. mTLS enhances security by requiring both the client and the server to authenticate each other before a connection can be established, ensuring that traffic is secured in both directions.

Before delving into the steps, let’s understand some of the terms used:
MTLS (Mutual Transport Layer Security): Mutual TLS (mTLS) is a method for mutual authentication in which both parties in a network connection validate the SSL certificates presented by each other against a trusted root Certificate Authority (CA) certificate.

Client Certificate: In cryptography, a client certificate is a type of digital certificate that is used by client systems to make authenticated requests to a remote server.

Prerequisites

• A configured and operational F5 BIG-IP environment.
• Access to a valid CA (Certificate Authority) certificate.
• An SSL profile and virtual server.

Configure Mutual TLS

1. Go to Local Traffic -> Profiles -> SSL -> Client

2. Select your profile
3. Under Client Certificate, select Require
4. Under Trusted Certificate Authorities, select the CA certificate of your choice.

The following iRule code snippet provides a method for validating an SSL certificate’s fingerprint during a client handshake on an F5 BIG-IP server. It extracts and checks the peer’s certificate’s SHA256 fingerprint against a predefined expected value. If the fingerprints match, the connection is allowed; if not, it is rejected, ensuring only authorized access.

 # Initialization block executed when the rule is loaded.
when RULE_INIT {
    # The expected certificate fingerprint
    set expected_fingerprint "123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0"
    set expected_fingerprint_binary [binary format H* $expected_fingerprint]

    set expected_fingerprint2 "123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0"
    set expected_fingerprint_binary2 [binary format H* $expected_fingerprint2]
}
when CLIENTSSL_HANDSHAKE {
    global logs_on log_level log_levels expected_fingerprint_binary expected_fingerprint_binary2
    # Retrieve the peer certificate presented during the handshake
    set peer_cert [SSL::cert 0]
    # extract the public key from an mTLS p12 cert by using:
    # > openssl pkcs12 -in client-cert.p12 -clcerts -nokeys -out client-cert.pem
    # Use the command > openssl x509 -noout -fingerprint -sha256 -inform pem -in client-cert.pem
    # on the public key of the mTLS cert to extract the certificate fingerprint.
    # Extract the fingerprint (SHA256 in this case) of the peer certificate
    set sha256_hash [sha256 $peer_cert]
    # use if you wish to reject based on the fingerprint instead of based on the rootCA signed the cert you can enable this piece of code
    # you should also change the Client Certificate in the SSL client profile into a "Request" mode.
    # if {[string length $peer_cert] == 0} {
    #     log local0. "no client cert, rejecting"
    #     reject
    #     return
    # }  

    # Compare the certificate's fingerprint to the expected fingerprint
    if { $sha256_hash eq $expected_fingerprint_binary || $sha256_hash eq $expected_fingerprint_binary2 } {
        if { $logs_on == 1 && $log_levels($log_level) <= $log_levels(DEBUG) } {
            log local0. "Certificate fingerprint matches"
        }
        # Allow connection
    } else {
        if { $logs_on == 1 && $log_levels($log_level) <= $log_levels(INFO) } {
            log local0. "Certificate fingerprint mismatch Dropping connection."
        }
        reject
    }
}

Run the following command to extract your SHA256 fingerprint.

openssl x509 -noout -fingerprint -sha256 -inform pem -in your_certificate.pem

The output should look like this:

SHA256 Fingerprint="123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0"

Related Articles

• How to Enforce mTLS Pre-Authentication in MobileBOT™ Defense
• Creating a Virtual Server on F5
• Configuring iRules for Custom Traffic Management on F5 (Session Headers)

How Do I Learn More?

If you have any questions, please send them our way at support.appdome.com or via the chat window on the Appdome platform.

Thank you!

Thanks for visiting Appdome! Our mission is to secure every app on the planet by making mobile app defense easy. We hope we’re living up to the mission with your project. If you don’t already have an account, you can sign up for free.