Forum Discussion
hooleylist
Feb 22, 2010Cirrostratus
Hi Scot,
That iRule would request a client cert any time the URI checks are true, even if the client has already presented a cert on the same TCP connection or on another TCP connection trying to re-use the same SSL session ID. Also note that you're checking the cert validity against the client SSL trusted cert bundle using SSL::verify_result, but you're not doing anything if the cert is invalid. I assume the application is checking the headers and handling invalid certs?
You could make this more efficient by storing the cert details in the session table and then checking when a restricted URI is requested to see if the SSL session ID has a corresponding session table entry. If so, you could insert the cert details in the headers without invalidating the session and requesting a client cert again.
You can add/retrieve key-value pairs to the session table using the session command:
http://devcentral.f5.com/wiki/default.aspx/iRules/session
If you're inserting the verification string, subject and issuer into the HTTP headers, it would make sense to parse these values once per SSL session and then insert them into the session table using the SSL session ID as the key. You'd also want to check that the SSL session isn't 64 zeroes (Click here as this is what SSL::sessionid will return if the client's SSL session ID isn't in LTM's SSL cache.
I'll try to give an example later this week if I have time to test one. Can you confirm which LTM version you're running? You could also try updating your rule to use the session table and reply here if you get stuck.
Also, your iRule isn't doing anything with pool selection or persistence. So it would be up to the VIP's persistence profile to handle persistence and the persistence timeout.
Aaron