Forum Discussion
tub91
Cirrus
CirrusClient 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 we...
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
MVPI 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
}
}
}
tub91Hi 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
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).
iaineNacreous
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
- tub91
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