If you're exposing an API to a partner or connecting services across environments, you may want more than an encrypted connection. You also need a dependable way to identify the caller. Mutual TLS, or mTLS, lets the client present a certificate as part of that connection. F5 Distributed Cloud (XC) can validate it at the application edge and pass selected certificate details to your backend.
Let's walk through the setup and the choices that matter along the way.
With certificate-based HTTPS, the client verifies the server. Mutual TLS adds authentication in the other direction: the server requests a client certificate, and the client proves possession of the corresponding private key during the handshake. Sending a certificate alone is insufficient. [3]
That gives your application an authenticated client identity. Deciding what that identity may do is a separate application policy. For example, two partners might hold certificates from the same trusted authority but have access to different API operations. Treat that distinction as part of your design.
For the first deployment, gather the client certificate and its private key from the certificate authority chain you intend to trust for clients. Keep the two trust directions clear: your caller verifies the server certificate, while XC verifies the client certificate. They may use different authorities.
A backend that shows received headers makes the first test easier to understand. Use a test identity and avoid exposing certificate details in a public debugging service.
In the XC namespace where your LB belongs to create or edit a load balancer. Choose automatic certificate management or a custom certificate for its HTTPS endpoint. Attach your origin pool and confirm the domain and traffic advertisement are correct (IPv6 supported!).
In the advanced HTTPS settings, enable mutual TLS and supply the trusted client CA certificate using a supported encoding. Leave the client certificate optional setting unchecked when every connection must present a certificate. Optional mode accepts clients without a certificate but rejects a supplied certificate that fails verification.
In case if the application needs certificate information you can enable XFCC forwarding. The available fields are the following:
Select only what your application needs, then save the configuration.
Optional mode can help with a staged rollout. It also leaves you with two kinds of callers, so decide explicitly which operations a caller without a certificate can reach. For an API reserved for certificate-authenticated partners, start with mandatory certificates.
The X-Forwarded-Client-Cert header carries certificate information through a proxy. Subject describes the certificate subject; URI and DNS carry those subject alternative names. Cert carries the leaf certificate, while Chain carries the client-provided chain. That chain should not be assumed to be the validated trust path.
The backend receives an assertion from the proxy about the client. A practical design is to allow backend access only through your trusted ingress and check how incoming XFCC values are handled. Verify the behavior of your XC deployment rather than assuming a default.
As an implementation check, send a request containing a fabricated XFCC value and inspect what reaches the origin. An application that uses certificate identity for authorization should consume only information established by its trusted proxy path.
Keep identity rules explicit. A client certificate containing a DNS name does not, by itself, prove that the request originated from that domain's web server. Define which certificate identities are allowed and how the application maps them to permissions.
Client mTLS at the edge and transport security to the origin require separate configuration. In the origin pool, F5 provides TLS settings for SNI and origin server verification, along with a client authentication certificate option for mTLS to the origin. Configure these to match your backend.
When XC establishes a new mTLS connection to the backend, the certificate on that connection identifies XC. The original caller can be represented by the forwarded identity information. This is a proxy design with separate TLS sessions, so document which identity each component authenticates.
Start with a valid test client and a diagnostic endpoint behind your load balancer. The following examples assume a curl build supporting PEM certificate and key files. Replace the hostname and filenames with your own.
curl --verbose --cert client-cert.pem --key client-key.pem \ https://api.example.com/headers
If the endpoint uses a private server CA, add --cacert server-ca.pem. That file establishes curl's trust in the server; it does not configure XC's trust in your client certificate. Keep server verification enabled during testing.
curl --verbose https://api.example.com/headers
The second command sends no client certificate. Compare its result with your mandatory or optional policy, then run the checks on the next page.
Expiration is only part of certificate lifecycle management. If a key is compromised or a partner loses access, you need a way to reject its certificate before it expires. F5's CRL configuration provides a periodically downloaded certificate revocation list.
Create a CRL object in the application namespace under the load balancer management area. Configure its server address and port, access method, refresh interval in hours, and download timeout in seconds. Save the object, then select it in the HTTPS load balancer settings for client certificate revocation verification.
Choose the refresh interval around your required response time to revocation. Publishing a new list and having XC retrieve it are separate events. Test the complete process, including what happens when the CRL server is unavailable, before depending on it for access removal.
