Forum Discussion
Stefan_Klotz
Cumulonimbus
CumulonimbusClient-Certificate and IP-Whitelisting via Policy or iRule?
We have a requirement to verify for a valid client-certificate (not expired and issued from a trusted CA), but also accept a bypass if the source-IP is trusted. I have the following questions for the...
I would approach this by having two separate client SSL profiles - one without client authentication (bypass) and one with client authentication (require). And then use an iRule to switch between them based on the source IP.
create ltm profile client-ssl CLIENTSSL-NO-CLIENT-AUTH defaults-from <PARENT CLIENT SSL PROFILE> cert-key-chain add { <CERT KEY CHAIN NAME> { cert <CERT NAME>.crt key <KEY NAME>.key chain <CA BUNDLE NAME>.crt } } create ltm profile client-ssl CLIENTSSL-CLIENT-AUTH defaults-from <PARENT CLIENT SSL PROFILE> cert-key-chain add { <CERT KEY CHAIN NAME> { cert <CERT NAME>.crt key <KEY NAME>.key chain <CA BUNDLE NAME>.crt } } peer-cert-mode require ca-file <ROOT CA NAME>.crt create ltm data-group internal DG-SSL-CLIENT-AUTH-BYPASS type ip records add { <WHITELISTED IP 1> <WHITELISTED IP 2> ... } when CLIENT_ACCEPTED { set DEBUG 0 set CLIENT_IP [IP::client_addr] if { [class match $CLIENT_IP equals DG-SSL-CLIENT-AUTH-BYPASS] } { # Skip SSL client authentication for whitelisted source IPs SSL::profile CLIENTSSL-NO-CLIENT-AUTH if { $DEBUG } { log local0. "$CLIENT_IP - SSL client authentication bypassed" } } else { # Enforce SSL client authentication for all other source IPs SSL::profile CLIENTSSL-CLIENT-AUTH if { $DEBUG } { log local0. "$CLIENT_IP - SSL client authentication enforced" } } }
I would approach this by having two separate client SSL profiles - one without client authentication (bypass) and one with client authentication (require). And then use an iRule to switch between them based on the source IP.
create ltm profile client-ssl CLIENTSSL-NO-CLIENT-AUTH defaults-from <PARENT CLIENT SSL PROFILE> cert-key-chain add { <CERT KEY CHAIN NAME> { cert <CERT NAME>.crt key <KEY NAME>.key chain <CA BUNDLE NAME>.crt } }
create ltm profile client-ssl CLIENTSSL-CLIENT-AUTH defaults-from <PARENT CLIENT SSL PROFILE> cert-key-chain add { <CERT KEY CHAIN NAME> { cert <CERT NAME>.crt key <KEY NAME>.key chain <CA BUNDLE NAME>.crt } } peer-cert-mode require ca-file <ROOT CA NAME>.crt
create ltm data-group internal DG-SSL-CLIENT-AUTH-BYPASS type ip records add { <WHITELISTED IP 1> <WHITELISTED IP 2> ... }
when CLIENT_ACCEPTED {
set DEBUG 0
set CLIENT_IP [IP::client_addr]
if { [class match $CLIENT_IP equals DG-SSL-CLIENT-AUTH-BYPASS] } {
# Skip SSL client authentication for whitelisted source IPs
SSL::profile CLIENTSSL-NO-CLIENT-AUTH
if { $DEBUG } { log local0. "$CLIENT_IP - SSL client authentication bypassed" }
}
else {
# Enforce SSL client authentication for all other source IPs
SSL::profile CLIENTSSL-CLIENT-AUTH
if { $DEBUG } { log local0. "$CLIENT_IP - SSL client authentication enforced" }
}
}- Stefan_Klotz
Dear Michael,
thank you for your quick and useful response. This sounds indeed for an easy solution, at least for the iRule-option. But besides this, I'm still interested for an answer for the policy option. I mean which technical options do I have in regards to client-certificate verification? Is it really only the CN, which can be checked or other values like within iRules as well?Regards Stefan 🙂
Hi Stefan,
I have checked this on TMOS v16 and it looks like you are correct. In a local traffic policy, you can only check the common name with the option of using 'index' to exactly specify which certificate you would like to check (e.g. the identity certificate or intermediate certificate that the client sends)
root@(bigip-1)(cfg-sync In Sync)(Active)(/Common)(tmos)# create ltm policy Drafts/foo strategy first-match rules add { bar { ordinal 0 conditions add { 0 { ssl-cert ? Selectors common-name Organization common-name specified in certificate Params index Numeric index to match- Stefan_Klotz
Thanks again for confirmation!
Final question, am I right that checking the CN via Policy (or iRule) is just a string comparison and therefor less secure than using the "Trusted Certificate Authorities" from the clientSSL-profile? Or the other way round, what's the technical mechanism behind the "Trusted Certificate Authorities"? I mean which value from the configured certificate bundle will be used for verification? Is it the serial number, the hash-value or something else?
Regards Stefan 🙂
