Forum Discussion

Cirrus

Oct 18, 2022

Client Authentication with certificate on one URI only

Hello,

I need your help figuring out how to troubleshoot a new implementation. We have a VIP exhibiting our service. The VIP has its own SSL client profile.

Behind this VIP is an IIS which has 5 websites configured.

We would need that only when one of these 5 websites is contacted the client is asked for a certificate to authenticate. If the authentication is successful then F5 performs the reverse proxy, otherwise it resets the connection.

For the other 4 websites, however, the client certificate must not be requested.

We tried to create an iRule to verify that the certificate is correct but our problem is that we don't want to change the VIP's SSL client profile by changing the client authentication setting. This setting must remain in "ignore" otherwise the certificate is required to access the other 4 websites.

How can we proceed? Is there a way to differentiate the scenarios and manage the certificate request through iRule?

From some research we have seen that perhaps it would be possible through an SSL Renegotiation in the iRule. Is there any other way? If not, how should iRule be done?

Thank you

application delivery

Kevin_Stewart
Oct 27, 2022
Just to quickly follow up on this question, the answer depends on when. From an OSI perspective, by the time you've reached the HTTP uri, the TLS handshake is already done, so you really don't have any other option but to perform renegotiation. Since the client and BIG-IP have already established a TLS session (without cert auth), you basically have to tell the client to start a new TLS handshake, while you flip on the cert auth option. Even APM does this for things like On-Demand Cert Auth, that happen after initial TLS handshake and after the access policy has started.

If you can get to the data you're looking for before the TLS handshake finishes, like looking at the SNI in the layer 4 TCP payload, then it would be possible to switch client SSL profiles (between auth and non-auth SSL profiles).

mihaic
MVP
Oct 19, 2022
I think this problem was already on the forums:
https://community.f5.com/t5/technical-articles/selective-client-cert-authentication/ta-p/275555

when CLIENTSSL_CLIENTCERT { HTTP::release if { [SSL::cert count] < 1 } { reject } } when HTTP_REQUEST { if { [matchclass [HTTP::uri] starts_with $::requires_client_cert] } { if { [SSL::cert count] <= 0 } { HTTP::collect SSL::authenticate always SSL::authenticate depth 9 SSL::cert mode require SSL::renegotiate } } }
- tub91
  Cirrus
  Oct 21, 2022
  Hi mihaic
  Thank you for your answer. However, we would like to avoid using SSL Renegotiation.
  Is there any way to do this through the APM?
  - Kevin_Stewart
    Employee
    Oct 27, 2022
    Just to quickly follow up on this question, the answer depends on when. From an OSI perspective, by the time you've reached the HTTP uri, the TLS handshake is already done, so you really don't have any other option but to perform renegotiation. Since the client and BIG-IP have already established a TLS session (without cert auth), you basically have to tell the client to start a new TLS handshake, while you flip on the cert auth option. Even APM does this for things like On-Demand Cert Auth, that happen after initial TLS handshake and after the access policy has started.
    
    If you can get to the data you're looking for before the TLS handshake finishes, like looking at the SNI in the layer 4 TCP payload, then it would be possible to switch client SSL profiles (between auth and non-auth SSL profiles).