Mar 27, 2026 - For details about updated CVE-2025-53521 (BIG-IP APM vulnerability), refer to K000156741.

F5 BIG-IP Access Policy Manager (APM) Machine Tunnels for Windows

Table of Contents Introduction Machine Tunnels vs. other Access Policies Machine Tunnel Authentication Access control is critical An example configuration Step 1 Start the Device Wizard ...
Updated Apr 03, 2023
Version 2.0
application delivery
security
Saravanan_M_K's avatar
Saravanan_M_K
Icon for Employee rankEmployee
Feb 25, 2025

Note: If you try to do ondemand client cert authentication with the above method, you cannot use TLSv1.3. So you have to downgrade to TLSv1.2.  The reason is F5 currently do not support TLSv1.3 way of doing clent cert authN on BIGIP.

Fine details:

To understand why we do not support old way of client cert authN in TLS 1.3, you need to understand what is changed in TLS1.3 and how client cert authN is done in 1.3.

 

Theory:

old way of doing client cert authN in 1.2:

 

Moral of the story: In TLSv1.2, Client Cert AuthN usually happens as a part of initial TLS1.2 handshake

If we want On-Demand Client Cert AuthN like in APM use case after the initial tunnel is established, (that is post-handshake) the only way we can achieve this in TLSv1.2 is using TLS 1.2 renegotiation feature. 

 

 

Steps involved in On Demand Client Cert authN in TLS1.2 using TLS Renegotiation feature:

 
Moral of the story: Here On-Demand Client Cert authN happens using TLS Renegotiation feature which has been entirely removed in TLS1.3 (TLS1.3 instead uses post-handshake client cert authN in a new format without using renegotiation).

 

On Demand Client Cert AuthN in TLSv1.3 (new format without using renegotiation):

===============

Here if you notice it is happening after the initial TLS handshake and TLS tunnel is established and application data can start flowing.  Then suddenly because of on-demand cliet cert authN invoked, inside the existing tunnel, it is sending a new CertificateRequest message as TLSv1.3 encrypted extensions, for which the client is sending response with encrypted extensions {Cert, CertificateVerify, Finished}. Thus it is happening afer the initial handshake. Hence the CR, C, CV message are all encrypted adding more safety whereas in TLSv.2 they are sent as plain text.

Moral of the story: In TLSv1.3, ondemand client cert authN happens post initial-handshake without using TLS renegotiation feature in a new format.

Basically when using TLSv1.3 we need to do OnDemand Client Cert AuthN using this above method.  For which we have an existing RFE ID#846401.  As of today (25 Feb 2025) it is not implemented yet.