Technical Forum
Ask questions. Discover Answers.
cancel
Showing results for 
Search instead for 
Did you mean: 

Client Authentication with certificate on one URI only

tub91
Cirrus
Cirrus

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

1 ACCEPTED SOLUTION

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).

View solution in original post

5 REPLIES 5

mihaic
MVP
MVP

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
    }
  }
}  

 

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?

Do your clients support SNI? If so, you could have two SSL profiles attached to your VIP. The default one would for your 4 websites and the SNI one would be for your site that requires Client Cert auth and so would have this option set to require. The default SSL profile would have Client Cert set to Ignore

You could do this via APM I guess - if the requested HTTP Host equals the 5th site then you could enable APM and insert an On Demand Client Cert object

SNI - https://support.f5.com/csp/article/K13452

Hi @iaine 

Using the "Request" in the Client Authentication section of the SSL Client profile and entering the CA that issued the certificate, we were able to obtain the expected result.

Obviously we then set up an iRule that verifies and allows access to the single URI on which the authentication with certificate must be.

I have explained the implemented flow in more detail here. Thank you for your interest

https://community.f5.com/t5/technical-forum/client-certificate-authentication-clarifications/m-p/303...

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).