(Client) SSL profiles config from iRules

From the configuration guide under the writing irules section:

 

 

 

Working with profiles

 

 

When you are writing an iRule, you might want that iRule to know the value

 

of a particular profile setting so that it can make a more-informed traffic

 

management decision. Fortunately, the iRules feature includes a command

 

that is specifically designed to read the value of profile settings that you

 

specify within the iRule. Not only can iRules read the values of profile settings, but they can also override values for certain settings. This means that you can apply

 

configuration values to individual connections that differ from the values the

 

LTM system applies to most connections passing through a virtual server.

 

 

Reading profile settings

 

 

The iRules feature includes a command called PROFILE. When you

 

specify the PROFILE command in an iRule and name a profile type and

 

setting, the iRule reads the value of that particular profile setting. To do this,

 

the iRule finds the named profile type that is assigned to the virtual server

 

and reads the value of the setting that you specified in the PROFILE

 

command sequence. The iRule can then use this information to manage

 

traffic. For example, you can specify the command PROFILE::tcp idle_timeout

 

within your iRule. The LTM system then finds the TCP profile that is

 

assigned to the virtual server (for example, my_tcp) and queries for the

 

value that you assigned to the Idle Timeout setting.

 

 

Overriding profile settings

 

 

You can use certain iRule commands to override specific profile settings.

 

For example, you can use commands to override settings in an SSL or HTTP

 

profile. When you specify these iRule commands, with setting values, then for the

 

specific connection to which the iRule applies, the LTM system uses the

 

setting values you specify in the iRule, rather than the values in the

 

corresponding profile. iRule commands that override profile settings are:

 

 

• SSL::renegotiate

 

• SSL::cert mode

 

• SSL::authenticate

 

• SSL::authenticate depth

 

• SSL::unclean shutdown

 

 

Good point. I suppose you will need to do your suggested work around after all but just be careful that using the TMUI afterwards doesn't remove your changes.

 

 

We did already file a CR for the TMUI removing the related fields if you change the cert mode to ignore (CR53737).

 

Oh, BTW - you could try switching down in the CLIENT_ACCEPTED event. That event occurs at the completion of the 3-way TCP handshake before the SSL has even seen any packets.

 

I have to admit that I already tried that one too... but I got the following error message:

[command is not valid in current event context (CLIENT_ACCEPTED)] [SSL::cert mode ignore]

... thank you for the CR: I'll follow that closely.

How about the CR going. I also has customer need this function.

Can we using SSL::profile to solve this issue?

 

the code may like this:

 

when HTTP_REQUEST {

 

if { [HTTP::uri] eq "/manual/" } {

 

SSL::profile cert_require_profile

 

SSL::renegotiate

 

} else {

 

SSL::cert mode ignore

 

log LOCAL0. "Other Pages"

 

}

 

}

 

 

with cert_require_profile, we can add CRL setting in it. so we can start with profile cert_ignor_profile that without CRL setting. if user access the "/menual/", then SSL::renegotiate will happen, when user submit client certificate, it will go through the CRL list.

 

 

I will test it later. any good idea?

The only issue with that approach is that the SSL::profile command isn't going to work under the HTTP_REQUEST event. The SSL::renegotiate command will, but you'll need to select which profile to use ahead of time.

 

 

Colin

At last, I got this rules running:

when CLIENT_ACCEPTED {
  set session_flag 0
 }
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
  }
  log "Session flag is $session_flag"
}
when HTTP_REQUEST {
  if {[HTTP::uri] starts_with "/manual/" } {
    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"
    set session_flag 1
         SSL::renegotiate
    }
  }
  else {
    
    log LOCAL0.warn "No cert needed,to server directly.And the uri is [HTTP::uri]"
  }
  log "Session_flag at end of http_request is $session_flag"
}

with this rule, I can change the authenticate mode from ignore to require depends on the URI customer requie. But it can only running on BIGIP 9.1.2 and can't running on BIGIP 9.4.0 beta one build 211. BIGIP 9.4 seems can't caputure the client cert after renegotiate.

sure, Code share will save our time on it. and it's unique feature for BIGIP.

 

 

I have informed that the CR for keep the Client certificate setting in client ssl profile will continue and you will see it in 9.4.

 

 

Also, in 9.4, we can support CRLDP feature, so it's possible to add more CRLDP server in authentication profile.

 

 

All these are good news, so waiting for 9.4 beta 2... The best is 9.4 final release.