Vivian_Peng_967
Nimbostratus
NimbostratusHelp needed in this iRule to change the behavior of the authentication subroutine in the iRule
Hi,
I need help in the following iRule so it can change the behavior of the authentication subroutine in the iRule which I got from this forum originally:
-------------------------------------------------------
when CLIENTSSL_HANDSHAKE {
log LOCAL0.warn "cert count=[SSL::cert count]"
if { [SSL::cert count] ==0 } {
log LOCAL0.warn "when client handshake,ssl cert count is 0,pass"
}
else {
log LOCAL0.warn "when clent handshake , two way cert founded and the cert count is [SSL::cert count] "
HTTP::release
}
}
when HTTP_REQUEST {
if {[HTTP::uri] contains "/GXSGateway.MSNET" } {
log "Requiring certificate...and tht request uri is :[HTTP::uri]"
if {[SSL::cert count] == 0} {
log local0. "when http request,ssl cert count is 0,now http collect"
HTTP::collect
SSL::authenticate always
SSL::authenticate depth 9
SSL::cert mode require
log local0. "when http request,now renegotiating"
SSL::renegotiate
}
}
else {
log LOCAL0.warn "No cert needed,to server directly.And the uri is [HTTP::uri]"
}
}
---------------------------------------------------------------
I need this iRule in place since only one of my clients from "MSNET" wants to be authenticated. This iRule works with this client's WinXP, Win Vista platform, but its' not working with his real production machine that is in Win2003 and on this machine client was never prompt to present his client certificate. I have the case open with Support. The finding of the issue is that when WinXP makes "GET HTTP::uri" request, the server prompts for a HelloRequest. The ClientHello then comes from the WinXP Device indicating a random value. But when this ClientHello comes back from Win2003 it is always presenting a resume. Essentially the Win2003 connection continues to try and resume the ssl connection that has already been established with the initial SSL Handshake before the GET request. we find that the resume string matches the session_id from the initial ServerHello exactly.
Essentially when the GET Request is performed XP Treats this as a new session, appropriately, where the Windows 2003 does not and treats the session as a resume. At this point this is an issue with the way that the Windows 2003 environment desires to resume the SSL Connection instead of establish a fresh connection.
I have communicated this back to MSNET client they insist that Win2003 does follow RFC standards in terms of SessionResume, so it sould be the server (bigip) to send a new session request in attempt of renegociating the ssl coonection. So my question is there any way I can add a subrutine into above iRule so BigIP can force a new session on Win2003, or any other suggestions what I should do?
I am not a developer or programer,and any help would be really appreciated.
Thanks,
Vivian
