Passing SSL Client Cert data - more info needed

Colin,

 

 

1. Do you have some concerns with this method?

 

 

I am only asking if this is the best method, as it looks like several lines of code to step through for each client connection, so I was just trying to make sure there wasn't a more automated, or low-level process which could do the same thing.

 

 

2. Thank you, we're new at this, and have to ask the simple questions.

 

 

3. I'll try to dig deeper into this as soon as I get another problem with a NAT figured out (C248803 if you'd like to peek at it). I'll post any results I come up with.

 

 

 

4. What would be the optimum value for these timeouts? As the history shows in C246030, we found to have the data available at all times at the web server, the cache timeout has to be 1 second less than this timeout value for the session in the iRule. Any good lessons learned from others that have used this?

 

 

Thanks,

 

Tom

 

Hi,, I'm baaaack.

Well, we had other problems to correct, and now I'm back to try and resolve this client SSL cert issue. At this point, I can get everything to work fine until I request the client cert and run it through the rule.

when CLIENTSSL_CLIENTCERT {
  set ssl_cert [SSL::cert 0]
  set ssl_errstr [X509::verify_cert_error_string [SSL::verify_result]]
  set ssl_stuff [list $ssl_cert $ssl_errstr]
  session add ssl [SSL::sessionid] $ssl_stuff 61
}
when HTTP_REQUEST {
  set ssl_stuff2 [session lookup ssl [SSL::sessionid]]
  set ssl_cert2 [lindex $ssl_stuff2 0]
  set ssl_errstr2 [lindex $ssl_stuff2 1]
  if { $ssl_errstr2 eq "ok" } {
    HTTP::header insert SSLClientCertStatus $ssl_errstr2
    HTTP::header insert SSLClientCertValidFrom [X509::not_valid_before $ssl_cert2]
    HTTP::header insert SSLClientCertValidUtil [X509::not_valid_after $ssl_cert2]
    HTTP::header insert SSLClientCertSubject [X509::subject $ssl_cert2]
    HTTP::header insert SSLClientCertIssuer [X509::issuer $ssl_cert2]
  } else {
    HTTP::header insert SSLClientCertStatus $ssl_errstr2
  }
}

It chokes. and by that I mean the BigIP pair actually stop responding to all requests, and the Active unit goes to Standby and the Standby unit goes to Active. Once I close all browsers trying to use the client cert, normal traffic flow resumes.

Where do I start troubleshooting this one?

For info, using BIG-IP 9.1.1 Build 54.6.

Tom

What messages, if any, are logged to /var/log/ltm following the choke?

That's a pretty nasty choke, it sounds like. I'd recommend checking the logs, like citizen_elah said, and then I'd probably start removing a line from the rule at a time until the rule begins working again. If you can narrow it down to a particular line or a couple lines, it'd be far easier to identify the actual problem.

 

 

On another note, since your rule looks correct, I did a little digging to see if there are any known issues with this sort of thing, and found that other folks have had similar problems on 9.1 and 9.1.1.

 

Click here

 

 

You might want to contact support to get the hotfix in question, or look at upgrading to a newer version if you continue to have trouble after your debugging attempts.

 

 

-Colin

 

 

A whole lot of stuff, most of which I can't post due to security restrictions. One thing that stands out is:

 

Error 'illegal attempt to update using time 1140030199 when last update time is 1140030199 (minimum o

 

ne second step)' during rrd_update for rrd file '/var/rrd/connections'

 

 

Feb 15 14:03:19 sccp bcm56xxd[2143]: 00010001:3: Switchboard Failsafe take action is set by lacpd ... Exiting bsx_mcpmsg.c(293)

 

Feb 15 14:03:19 sccp bcm56xxd[2143]: 00010014:6: Exiting...

 

Feb 15 14:03:19 BIGIP2 statsd: 011b0600:3: Error 'illegal attempt to update using time 1140030199 when last update time is 1140030199 (minimum o

 

ne second step)' during rrd_update for rrd file '/var/rrd/connections'

 

Feb 15 14:03:20 tmm tmm[6036]: 01010001:3: default TMM Version 9.1.1.54.6.5 starting

 

 

It hangs, then goes to standby, restarts, and goes active again. In doing a TCPDUMP I see it hangs for a minute, then says "Re-starting tmm" then "Re-starting bcm56xxd", continues on and re-activates.

 

 

Tom

 

 

Depending on whether or not you have a hotfix for 9.1.1, there were issues with the session command that have been fixed. You should definitely contact support.

I have same issue (tmm & bcm56xxd restars) on 9.1.1. But i'm not using sessions. Case is opened and waiting for hotfix.

Once you get the hotfix applied, just as another method, we are passing the entire cert to the webserver in PEM format via something like this:

HTTP::header replace SSLClientCert [X509::whole $the_cert]

Then our .NET application on the web server can work with the certificate as needed.

I have submitted a case with tech support, and will post the results as soon as I get them.

 

 

Tom

I wonder if anyone can help me with a similar issue.

 

 

We have iRules attached to authentication profiles, and then one main iRule for the virtual server. The iRule in the auth profile saves the client certificate to the session, and then the main iRule can examine it within the session.

 

 

We are also experiencing timeout issues with the data whereby the client certificate gets lost. Users will experience this in terms of being re-prompted for the client certificate in mid session.

 

 

The other aspect of the problem is that when the user is re-prompted for the client certificate and selects one, the main iRule still cannot see it and sends the user to our custom page that indicates a missing client certificate. Our logging shows that when this happens, the user enters the HTTP_REQUEST, and the BIGIP sees no client cert and then executes the iRules attached to the auth profiles. After this, even though it does execute these iRules and resaves the cert to the session, the user still sees the No Cert Provided error page....perhaps because it was already in the HTTP_REQUEST?

 

 

We tried to follow the advice above about session/cache timeouts. The default Cache timeout in the client profile is 3600, so we made our session timeout be 3601 - but this seemed to cause the client cert to be lost immediately.

 

 

So I guess my question is two-fold: 1. How do I make the client cert last in the session indefinitely, and 2. If that is not possible, is there a way to fix it so after the re-prompt it will recognize the certificate within that transaction?

 

 

As is usual with me, this may be unclear or more appropriate for a support ticket. If either is the case, please let me know.

 

 

Thanks.

 

 

-Bill