Certificate Authentication Problem

We worked with F5 support on this and were pointed back to DevCentral as it is thought to be an iRule issue. This was the relevant response...

 

 

The problem that is occurring is that the client cert and the server cert exchange is all occurring during the SSL handshake, before anything is passed to your iRule. I've actually enlisted some aid in this case and this is the suggestion that was made. This would be to see if a rule could be created that would somehow have a variable set when using the "request" option ["request" in the client SSL profile]. That variable would check to see if a client certificate was correctly received, if not redirect. If the client correctly identifies themselves with a certificate, then allow access through.

 

 

 

Can anyone help us out here?

Still trying to work this issue....

 

 

It seems that v9.2.0 introduced this function:

 

 

SSL::session invalidate

 

 

...which could solve the problem and let us delete sessions. We are still running 9.1.1, however, for some important reasons.

 

 

Does anyone know of any trickery I could use to mimic this function in v9.1.1?

 

 

Thanks.

 

 

-Bill

Any insights thus far?

 

 

Thanks.

 

 

-Bill

It sounds almost as though the initial authentication check is inserting some form of data (cert?) that it sees the second time the user hits that address, and therefore isn't prompting them to re-auth.

 

 

To get much more specific than that I'd need you to post the rule so I could take a look.

 

 

Colin

Colin, Thanks.

This is the iRule that we have attached to our authentication configuration. The Auth Config talks to LDAP and searches it for the entire binary contents of the passed-in certificate.

when CLIENT_ACCEPTED {        
        set tmm_auth_ssl_cc_ldap_sid [AUTH::start pam default_ssl_cc_ldap]
     
    }
    when CLIENTSSL_CLIENTCERT {
        set cur [SSL::sessionid]
        set ask [session lookup ssl $cur] 
        if { $ask eq "" } { 
          session add ssl $cur [SSL::cert 0] 3601
          log local0. "added session id $cur"
         }
        AUTH::cert_credential $tmm_auth_ssl_cc_ldap_sid [SSL::cert 0]
        AUTH::authenticate $tmm_auth_ssl_cc_ldap_sid
        SSL::handshake hold
    }
    when AUTH_SUCCESS {
        if {$tmm_auth_ssl_cc_ldap_sid eq [AUTH::last_event_session_id]} {
            session add uie "cert_auth_failed" "false"
            SSL::handshake resume
        }
    }
        when AUTH_WANTCREDENTIAL {
        if {$tmm_auth_ssl_cc_ldap_sid eq [AUTH::last_event_session_id]} {
            reject
        }
    }
    when AUTH_ERROR {
        if {$tmm_auth_ssl_cc_ldap_sid eq [AUTH::last_event_session_id]} {
            reject
        }
    }

Note that we also have a Main iRule attached to the virtual servers that does other stuff. The AUTH_FAILURE event is in that iRule because we need to be able to use it to process redirects in the event of auth failures. It looks like this:

when AUTH_FAILURE
{
  if {$tmm_auth_ssl_cc_ldap_sid eq [AUTH::last_event_session_id]}
    { 
      set auth_code 1
      log local0. "auth_failure - reject, auth_code is $auth_code"  
     }
    SSL::handshake resume
    session add uie "cert_auth_failed" "true"
 }

Now, you will notice that we do save the client certificate to the session table in the CLIENTSSL_CLIENTCERT event. We have tried to delete it from the table on an auth failure, but the problem I've described still persists. This is why I was thinking that the function in v9.2 (SSL::session invalidate) would help in that it might blow everything away and make the BIGIP think you never visited the first virtual server. But we still wonder if there is a way to accomplish this in the version we run (9.1.1)

Thanks - let me know if you would like to see more info.

-Bill

Ok, so last night we upgraded our development BIGIP box to v9.2.3 in order to be able to use the SSL::session invalidate function.

In the iRule, just before the redirect to the second virtual server, I pasted it in like so:

session delete ssl $id
SSL::session invalidate
HTTP::redirect "https://$login_vs/registration/auto_reg.aspx?location_request=[session lookup uie "location_request"]"

Unfortunately we are still seeing the same behavior, that after the redirect to the second virtual server, if you manually type the URL to the first virtual server, you are no longer prompted for a client certificate. The way I understand the Wiki entry for the function, this should not be happening. It says:

SSL::session invalidate

Invalidates the current session. Specifically, this command drops the session from the session cache to prevent reuse of the session.

So - by calling this right before the redirect, shouldn't it delete all traces of the SSL handshakes with the first virtual server, including client certificates?

Thanks.

-Bill