To prevent an F5 BIG-IP device from stripping client certificates from requests, you typically need to ensure that:
⸻
- SSL Termination Settings
If your F5 is terminating SSL (which it usually does by default), the client certificate is only visible to the F5 and won’t be passed to the backend server unless you explicitly forward it. • Check if SSL Profile (Client) has “Client Certificate” set to request or require. • Use an iRule or HTTP header injection to pass client cert info to the backend.
⸻
- Preserve Client Certificate
You have a few strategies:
Option A: Insert client cert as a header
Add an iRule like:
when CLIENTSSL_HANDSHAKE {
set cert [SSL::cert 0]
set cert_b64 [b64encode $cert]
HTTP::header insert "X-Client-Cert" $cert_b64
}
Make sure X-Client-Cert is accepted by your backend (and sanitized/logged appropriately).
Note: HTTP::header can’t be used in CLIENTSSL_HANDSHAKE. To inject the header properly, you’ll need to extract the cert in CLIENTSSL_HANDSHAKE and inject it during HTTP_REQUEST.
Option B: Use SSL passthrough
If the backend needs to directly verify the client cert, don’t terminate SSL on the F5: • Use a TCP profile instead of HTTP. • Use a forwarding virtual server or re-encrypt with SSL Bridging. • The backend server then sees the full TLS handshake including client certs.
⸻
- Disable SSL offload (Passthrough instead of Termination)
If you don’t need F5 to inspect traffic or apply L7 policies: • Disable the client SSL profile entirely. • Let the backend handle the TLS session directly.
⸻
- Advanced: TLS Proxy with cert forwarding
Use SSL bridging where the F5 terminates SSL, inspects, and re-initiates a TLS session to the backend: • Use an SSL Profile (Server) to re-encrypt. • Pass cert information in custom headers (as in Option A), or configure mutual TLS between F5 and backend.